For a long time the writer lived in two worlds that never quite connected: the design file and the code file. Design stayed on the canvas, code stayed in the editor, and between them sat manual translation. Open a screenshot, hold the numbers in your head, retype them in code. With every iteration something shifted a little, and the shift only showed up once everything was built. This article is about how the writer connected those two worlds: pen.dev as the design canvas, VS Code as the editor, and MCP as the bridge, with Kilo Code doing the reading.
Two Worlds Translated by Hand
The problem was never the design tool; it was how the work moved. Handoffs came as images: screenshots, exported PNGs, or a design file open on one screen while code was written on the other. The image is still, while the code keeps moving. Specifications that once felt clear in the head slowly unravel during translation: spacing a few pixels off, fonts that were not quite right, a component rebuilt from scratch even though the codebase already had one.
The writer noticed this after rereading old plans: the most accurate specifications were always the ones written from a direct reading, not from the memory of looking at a picture. So the question changed. Not "how do we design more neatly", but "how can the design that already exists be read by whoever writes the code, without being translated by hand".
The Bridge Called MCP
The writer's answer is MCP, short for Model Context Protocol. The idea is simple: a standard that lets applications open themselves up to AI agents in the editor. Pen, the application where the writer designs, ships its own MCP server. That server runs inside VS Code and is accessed by Kilo Code, so the agent sitting in the editor can reach the design canvas open in another application.
From the writer's side there are only four capabilities, and all of them only read: checking the state of the application (which document is open, which frames are available), reading its usage documentation, fetching the style of a node, and executing commands to read structure, export, or take a screenshot. None of them write. Design stays the writer's; the agent is simply given eyes.
There is one condition: Pen.app must be running and the document must be open. If the application is closed, the bridge does not exist.
Reading the Design, Not Guessing
This is where the writer enforced the hardest rule: the .pen file must never be read directly. Not with a file read command, not by searching for text inside it. The format is not meaningful text for whoever reads it that way, and the result is always wrong. Every access goes through MCP, without exception.
The order matters too. Before touching code, the agent checks the state of the application first, then reads the usage documentation the MCP itself provides: its data schema, how to execute commands, the guide for code. Only after that is the design structure read piece by piece, with variables and instances already resolved, so what is read is the final value, not the template.
The principle is one: nodes are operated through the identity MCP returns, never guessed. A frame name visible on screen is not used as an assumption. When the agent is unsure, it checks again instead of guessing. This small habit is what prevents silent misreadings, the most expensive kind of mistake because they never raise an error.
Translating to Code Without Losing Meaning
Once the design is read, its translation into code follows two rules the writer has set as permanent decisions.
First, layout, copy, and sizing: the design wins. Spacing between elements, header height, font sizes, content order, all of it follows what is on the canvas. Code adapts to the design, not the other way around.
Second, colors and type: the project's tokens win. Every variable in pen.dev has a counterpart in the project's CSS variables; the design's accent color, for example, is equated with the accent token the whole site already uses. The rendered design still looks like the canvas, but it does not introduce new colors or fonts into the codebase. Existing design consistency is not sacrificed for fidelity to one screen.
Together these rules stop translation from being a matter of taste. There is a reference to check against, and that reference is not the writer's memory of a picture but a direct reading of the canvas.
A Flow That Runs Both Ways
After using it a few times, the writer realized the flow does not run one way.
Toward code, the order is: read the design, implement one part, validate it, then move on to the next. Each section doubles as a unit of verification, so a mismatch is caught while it is still small.
Toward the design, it runs in reverse: what flows is the brief. The writer writes visual needs as text, feeds it into pen.dev as direction for creating a frame, and judges the result on the canvas before a single line of code is written. Bad design is cheaper to fix on the canvas than in code, and not every decision needs to pass through code first to know how it turns out.
Validation uses the same method in both directions: a screenshot from the canvas is compared with the result in the browser, section by section, until they match.
Traps the Writer Hit Personally
This flow did not go smoothly from the start. A few things that cost time:
- A closed Pen.app makes every call fail quietly, and the symptom is easily mistaken for a code problem.
- The MCP configuration contains paths specific to one machine. Sent to a repository, it breaks things for everyone else; configuration like that belongs in global settings.
- The editor session has to be reloaded before the MCP tools appear. Without this, it looks as if the tools do not exist.
- Guessing node names or ids. Once a guess happens to fit, the habit carries into the next reading, which may not fit at all.
Closing
Since adopting this flow, the writer's designs stopped being pictures to interpret and became something readable. The canvas stays alive, the code follows, and in between there is no longer memory holding the specification. That, for the writer, is the point of combining pen.dev with VS Code through MCP: not writing code faster, but deleting the translation that was never perfect.