The Mindset Shift
When Code Becomes the Canvas: How AI Collapsed the Design-to-Development Handoff
The Figma Illusion
I was at a design leadership meetup last week. AI was, of course, the main topic for everyone. I found myself spending a lot of time describing our new design to production workflow and explaining that our design system is in code only. Furthermore, discussing whether to use Figma or skip it in the workflow.
No Figma?
For years, designers have treated Figma component libraries like sacred texts. The source of truth. The canonical reference. We organize our work around them, govern them carefully, and become frustrated when the shipped product doesn’t align with the design file.
But here’s the uncomfortable reality: Figma was never the source of truth. Code is. Always has been.
What’s running in production, in front of customers, that’s the truth. Everything else is documentation at best, or fiction at worst. We’ve spent significant effort managing “drift,” the gap between design files and the shipped product. We treated it as a technical problem to solve by improving handoffs, tightening processes, and adding more detailed specifications. Figma addressed this by introducing the Dev Model.
Instead of treating it as a technical problem, now we can address it as a workflow challenge.
The Translation Chain
A year ago, our design workflow looked like most companies:
Design & Prototype (Figma) → Handoff to Engineering → Implementation
Parallel Track
Design system design (Figma) → Design System Engineering → Code base
Standard. Logical. But is fundamentally broken.
In both tracks, the arrow from the Figma design file to the engineering handoff represents a translation. This translation introduces errors. The final product results from a combination of technical constraints and a game of telephone from the original vision. Designers hand off their work and hope for the best. Engineers do their best to interpret. Product managers mediate. The gap between intent and reality is baked into the process.
In some cases, designers will be invited to participate in the review process. However, by then it can be too late. Designers feel they’ve lost control of what ships. And they’re right. The moment work leaves Figma, it enters a different world with different constraints, different tools, and different logic. The handoff isn’t just a meeting. It’s a border crossing.
The invitation to contribute to code has always existed. Smaller companies do this. Design engineers live in code. But for most UX designers, the code felt out of reach. A different domain.
Not anymore.
The New Workflow
Today, our workflow looks different:
Design Exploration → Clone Design System Repository → Code/Vibe Code → Merge Request - - → (Eng Implementation)
Here’s how it works:
Designers still explore direction. That creative phase doesn’t change. Wireframes, concepts, user flows. This step is tool-agnostic, Miro, Figma, Mermaid Diagram, etc. But after a direction is selected, they move directly into our design system. In code. Using AI to vibe code prototypes. They push a merge request.
If the experience is good and the code is solid, it can merge to production.
For now, many prototypes stay as prototypes. They’re conversation starters. Engineers inspect them as they used to inspect Figma files. The difference is that these coded prototypes are built appropriately. The file already references the actual components in code. No translation needed. No drift to manage.
Code as Source of Truth
Our design system now originates in code. Not initiated in Figma, then translated to code. The code is the source of truth because it’s the originator.
This is a fundamental inversion. And most likely concerns many designers.
When designers work, they’re working in the actual system that will ship. What you see is what you get. There’s no drift because there’s nothing to drift from. The gap we spent years trying to bridge just stopped existing.
This workflow gives individual designers enormous leverage. They can independently prototype and build internal tools. Design experiments can be integrated directly into production when done correctly.
The new workflow does come with challenges, as it requires designers work in a code environment, which is not familiar to all designers. But with on-the-job training and the aid of vibe coding, this workflow became more accessible.
The Benefits
Designers in code. What you see is what you want, and what you’ll get. No translation layer destroying your intent.
One source of truth. The actual one. Not the aspirational Figma file, but the code that ships.
Everyone can contribute. Designers can now propose changes, test the system, report bugs, and suggest improvements. The design system improves faster as more people have access to it. (We recently open-sourced the design system.)
The development process is healthier. The boundary between design and engineering didn’t disappear, but it became more permeable in the right ways.
The Reality Check
But. And this is critical.
Just because designers can ship to code doesn’t mean they should always do so. Not every merge request should merge. Some MRs are just conversations. A place to show thinking, get feedback, and explore direction.
AI-produced code is getting better every day. But it doesn’t have institutional knowledge. It might work perfectly for a single page. It might also break three other pages upstream, downstream, or in completely different parts of the system.
This is the crucial distinction designers and engineers need to understand together: there’s a difference between a UI fix and a system-level change. Not all code is equal in risk or impact. To put some guardrails in place for non-engineers shipping code. Our engineers have been improving testing, including testing agents and human code reviews. At the same time, they helped the design team create some guidelines so that no code touches the API or impacts the system.
What This Means for DesignOps
This is the shift.
DesignOps is no longer just managing Figma libraries and the process of “code translations”. Ops now can architect workflows that enable designers to work more closely with production. Working with engineers to set intelligent constraints that give people autonomy without chaos. Bridging disciplines without forcing everyone to become engineers.
This is service design. Understanding what people need to do their work, then building the systems that enable it.
The invitation for designers to contribute to code was always there. Smaller companies did this. Design engineers did this. What changed is AI made the invitation visible to everyone. It’s no longer the domain of specialists. DesignOps made the invitation safe. The guidelines, the partnerships with engineering, the training on when to push to production, and when to keep it as a conversation. Turning possibility into practice.
Helping Designers and Engineers Narrow the Gap
That drift we used to talk about? The gap between design intent and shipped product? It’s narrowing.
Not because we improved our management of it. Because we eliminated the condition that created it.
When designers work in code and code is the design system, there’s nothing to drift from. The translation layer that introduced drift is no longer present. What you design is what ships because you’re designing in the same medium that ships.
This is what AI made possible. Not just better tools. A different workflow entirely, which requires a mindset shift.
Tools come and go. Figma disrupted Sketch. Currently, Vibe coding IDEs created a workflow that challenges Figma. But the underlying need remains constant: designers need to work as close to the truth as possible. For the longest time, that truth lived in code, and designers worked in something else.
Not anymore.