At Figma Config 2026, Figma announced code layers: interactive code that lives directly on the design canvas, alongside your design files.
The take you'll read everywhere:
"Design tool threatens engineers!"
"Engineers defensive!"
"AI replaces another job!"
That's not what I'm worried about, said as someone who spends a decent amount of time writing and reviewing AI-generated code.
I'm not arguing against AI in the dev workflow.
I'm worried that Figma is solving the right problem with the wrong answer.
The design-to-dev handoff is genuinely broken. It has been for years.
Designer works in a flat file, in a silo. Ships it over the fence. Engineer implements. Something about the interactivity is off. Designer goes back. Adjusts. Ships again. Engineer adjusts. Repeat.
It's a structural problem. Two people who need each other's expertise are working in separate rooms and passing notes back and forth.
Leadership wanting to change this is correct. The push to be more "in code", vague as the phrasing is, points at something real: design and dev should be working closer together than they often are. Less silo, more overlap.
Figma looked at the problem and concluded the bottleneck was the handoff itself.
Code layers are their answer: convert any design frame to a working code layer with one click, or generate one from scratch with the Figma agent. Compare options side by side on the canvas. Comment, iterate, extract back to design layers, push to a repo.
In his recap of Figma Config 2026 on the Figma blog, Dylan Field wrote that "code is material, just like images, vectors and design layers."
Both designers and engineers, in the same file, on the same canvas.
Engineers don't want to live in Figma.
They work in editors, terminals, and tools that have full context of what they're building. Asking an engineer to collaborate inside the canvas is asking them to leave the environment where they can actually see what the code does. Most won't. And when they don't, the loop Figma describes collapses.
What's left is design-generated code that gets pushed to a repo and becomes someone else's problem. Not a handoff eliminated, but a new kind of handoff created.
Then there's the structural issue that runs underneath all of it: Figma is a design tool.
Its entire business model is design seats. Every product decision they make gets filtered through what keeps designers happy and renewing subscriptions. Unless something changes drastically, their code layer will always be optimized for what makes sense for designers, because that's where their revenue lives.
This isn't a criticism of Figma as a company. It's what it means for a design tool to own code. The thing that matters to the people paying Figma is the design output.
For Figma, code is a design feature. A better GitHub integration doesn't change that.
The problem isn't that Figma uses AI to generate code. I use AI to generate code. But there's a difference in how that generation gets used. When I work with Claude, I'm providing the context: the standards, the component library, the patterns, the constraints we've established. I'm also reviewing what comes out with full knowledge of the system it needs to fit into.
The judgment isn't in the tool. It's still with me. The tool extends my capacity, but it doesn't replace my understanding.
Figma would say that's the problem. That working with Claude is isolated, happening in a separate chat, disconnected from the rest of the team. They're not wrong about that, but moving that work into a design-optimized canvas isn't the answer either.
Figma's code layer is designed for people who don't have that system context and, in many cases, aren't expected to.
A designer generating a prototype.
A junior engineer under deadline pressure.
A small team without dedicated front-end.
The generated code goes through fewer hands that know what to look for. The gap between what got generated and what belongs in the codebase doesn't get caught because the person in the loop wasn't positioned to see it.
That's the distinction.
It's not inherently AI-generated code vs. real code.
It's context-aware generation reviewed by someone with system knowledge vs. context-free generation reviewed by someone who may not have it.
One produces artifacts your team owns.
The other produces things someone has to reverse-engineer into your system before they're usable.
Imagine the reverse. Leadership proposes letting engineers use one of the many AI tools that generates designs from a component description. You describe the behavior and the tool produces the layout. The type hierarchy. The interaction states.
Designers would push back immediately. They'd be right to. That tool isn't doing the research. It isn't running the user tests. It isn't making the hundred small decisions that make something actually work for the people using it.
It's producing an output from a description, and calling it a design.
A generated design isn't a designed thing.
Production implementation isn't just code that renders. It's accessibility decisions. Edge case handling. Performance tradeoffs. Integration with the actual system. Test coverage.
A Figma-generated component that looks finished will get shipped by someone who thinks it is, and the team that inherits it finds out what's missing the hard way.
Designers have spent years making that argument about their own work. They understand what "production-ready" means in their domain and won't let someone blur that line.
That's the argument we need to get better at making about ours.
The right answer to the collaboration problem isn't a faster handoff. It's less of a handoff.
On our team, we've been pushing for working sessions: designer talks through intent, engineer works through the code in real time, both people in the room instead of a relay race across a feedback loop. The output is something both people understand because both people were together when decisions got made.
Nobody inherits a component that looks done and isn't.
When both people are making decisions collaboratively, both are more invested in the outcome. That changes what gets built and how carefully it gets built.
Yes, it's scheduling-dependent. It's slower to set up. It requires both disciplines to treat each other's constraints as real.
Even so, that's the workflow I'm building toward. The back-and-forth it eliminates shows up faster than you'd expect. So does the cost of the alternative.
The canvas doesn't close the context gap. The conversation does.
Top comments (0)