Guzman Iglesias, Senior designer, challenges that assumption. Tools like pencil.dev don’t just improve the bridge between design and engineering. They raise a more direct question: should that gap exist at all?
Introduction
AI-generated design is no longer impressive. It's expected. What matters now is everything around it: how responsibilities shift, how craft gets redefined, and how tools like pencil.dev change the way digital products get built.
Closing the Design-Code Gap
This convergence didn't happen overnight. It's the result of a steady realignment between design and engineering. Figma signaled the shift early, adopting vocabulary long familiar almost exclusively to developers: design tokens, component systems, variables with conditionals, props, auto-layout, branches. The innovation was to adopt the devs’ language. The vocabulary changed first. The workflow followed.
Handoff improved next. Figma absorbed Zeplin's core use case by letting developers inspect designs, copy CSS values, and export assets without ever leaving the file. Dev Mode pushed it further, turning the design file into a live technical specification. The implication was clear: the Figma file shouldn't just describe the product. It should define it.
The Translation Problem
Even so, handoff is still a symptom. It reveals that design and code remain separate systems, connected through conventions and manual effort. The entire workflow rests on an unquestioned assumption: the design lives in an independent document that is eventually translated into code. That separation comes at a cost. Translation has always been expensive, lossy, and a consistent source of friction.
Recent updates pushed further. Figma's MCP allows AI agents to read design files and generate code directly. But automating a broken process doesn't fix the underlying model: there's still a separate document that needs to be interpreted and converted.
Figma Canvas has since gone even further: a new `use_figma` write tool lets agents create components, define variables, and modify the canvas directly. `generate_figma_design` can convert a live UI into editable design layers. The loop is now genuinely bidirectional. But the model hasn’t changed. The Figma file still lives outside the repository. Every sync, in either direction, is still an explicit, manual, or agentic operation. Design and code can talk to each other. They just don't live together.
So the real question is: why maintain design in a separate platform when the product itself lives in the repository?
.pen
A `.pen` file, the core format behind pencil.dev, is just JSON. It lives alongside the code, versioned with Git. It doesn't require export, sync, or a subscription to an external platform to stay current. The design stops being a parallel artifact that someone has to maintain separately and becomes just another file in the project, with the same history, branches, and review process.
That's the real difference from Figma. A Figma file is still a vector document that needs to be translated. A `.pen` file is closer to code than it is to a mockup. Handoff doesn’t disappear. It becomes unnecessary. The AI has simultaneous access to both the design and the codebase in the same repository, making inconsistencies visible and fixable in the same place without context switching.
Collaboration: Pencil's Weak Spot
Figma's real strength wasn't just the design tools. It was also the collaboration layer. Live cursors, contextual comments, multiple people in the same file at the same time. The Google Docs model applied to design. For mixed teams that include non-technical stakeholders, that's not a nice-to-have. It's the whole workflow.
pencil.dev takes a different approach. Its collaboration model is Git's: branches, commits, pull requests. Asynchronous, structured, and built for developers.
For some teams, this works. A two-person startup with one technical designer and one engineer can move faster without Figma's overhead. No client in the loop, no stakeholder reviews. A design-engineering team already used to reviewing UI in pull requests loses almost nothing.
For others, it’s a blocker. An agency presenting work to clients who need to comment on a mockup without touching code has no viable path here. A product team where the PM reviews flows in Figma before anything reaches engineering loses a critical checkpoint. A large org where design is a separate function with its own review cadence would need to renegotiate how decisions get made before switching tools.
This isn't a question of which model is better. It's whether a team can absorb the collaboration tradeoff without disrupting how they already work.
Governance: Who Owns the Design?
When design and code become the same artifact, ownership gets blurry.
A developer fixes a bug, tweaks some padding, and merges. A week later, a designer notices the spacing is off. In Figma, that would have been a comment before merge. In a Git-based model, it's a regression discovered after the fact because no one was looking at the `.pen` diff with a designer's eye.
This is where the Design Engineer gets critical. Someone who understands both domains. Not a new role —pencil.dev doesn't create it— but a more central one. The Design Engineer stops being a specialty hire and becomes the natural reference point for how the team builds.
The practical answer is structural: require one as a reviewer on any PR that touches `.pen` files. Not optional. Required. Merge rights on visual changes shouldn't default to whoever approves the code. Teams that skip this step don't eliminate the design review; they just move it downstream.
Merging design and code removes the implicit agreements that tools used to enforce. Teams now need to define them explicitly:
- Who has a final say over the design?
- Who approves a visual change in a pull request?
- Who's responsible when design and implementation diverge?
The tool used to answer these questions by default. Now the team does.
Conclusion
The Design Engineer has always been the workaround for a fragmented model. pencil.dev doesn't improve that bridge. It removes the river. It won’t fit every team yet. But it reframes the problem in a way that’s hard to ignore: If the product lives in the repository, why are we still maintaining the design somewhere else?
