In Figma Make, a designer can describe a checkout flow in plain English and watch working code appear next to the canvas. There is no handoff. No pull request waiting on an engineer who has never seen the layout. Just a prompt, a preview, and a publish button.
This is not hypothetical. Figma made Figma Make a core part of its platform in 2026, and its own research says most designers who lean into it believe it improves the quality of their work, not just the speed. The debate over whether designers should learn to code has run for a decade. That debate just became irrelevant. Not because anyone won it, but because the tooling made the question moot.
Somebody is now responsible for code that a designer typed one sentence to generate. Almost nobody has decided who that is.
The Old Debate Was About Syntax
The classic version of "should designers code" is a literacy argument: can a designer read a component tree, write a media query, contribute a small pull request. It stayed a literacy argument because the tools kept design and code in separate systems, with an engineer standing at the border between them.
Figma Make and the wave of tools chasing the same wedge, from v0 to Lovable to Rocket.new, didn't resolve that argument. They removed the border. A designer no longer needs to read code to produce it. The prompt is the interface. What ships isn't "a designer who learned React." It's functional code with no author who fully understands it, published by someone whose job was never system architecture.
That's a different problem than the one the old debate was having. It's the one the industry actually walked into, one release at a time, without anyone signing off on the tradeoff.
Closing the Distance Doesn't Close the Gap
The distance between having an idea and having running code has collapsed. The gap between code that runs and code that's sound hasn't moved at all.
LogRocket's independent review of Figma Make in 2026 put it plainly. The tool is genuinely useful for iteration and user testing, but the code it outputs is not production-ready, and it isn't accessible, semantic, or clean. Set that next to Figma's own survey finding that most designers who increased their AI usage believe it improved their output quality. Both can be true at once. A designer without an engineering background often can't tell finished-looking code from finished code, because the failure modes, a missing aria label, an unhandled edge case, a race condition in a state update, don't show up in the preview. The preview always looks done. That's the entire design goal of a prototyping tool.
When output that a tool markets as a prototyping aid gets promoted straight into production without anyone deciding to promote it, the organization has quietly redefined what counts as ready.
The Data on What Ships
This isn't a hypothetical risk. It's been measured, and the number isn't small.
A large-scale study of AI-authored commits in the wild tracked over 300,000 commits across more than 6,000 repositories. It found that roughly 15 percent of AI commits introduced at least one issue, and close to 23 percent of the catalogued issues were still unresolved at the latest snapshot of the repository. Separately, security vendor Apiiro reported a sharp jump in privilege escalation paths and architectural design flaws in AI-generated code. That figure is vendor research, not an independently replicated finding, and should be read that way until someone outside Apiiro reproduces it. Directionally, both point the same way.
That commit-level data came mostly from professional engineers using AI copilots inside teams that still had a review process. Tools like Figma Make are built for people publishing without that layer at all. If issue rates run this high with a reviewer in the loop, removing the reviewer doesn't make the code better. It just makes the defects someone else's problem to discover later, in production.
Where the Review Step Used to Be
The diagram above makes the shape of the problem visible. The traditional path from design to production had a built-in checkpoint: a second, technically trained person reviewing the code before it reached users. The AI-native path removes that step, not through a policy decision by anyone, but because the tool made the shortcut the default. Responsibility didn't disappear when the checkpoint did. It moved to whoever hit publish, and in a growing number of organizations, that person is a designer who was never asked to carry it.
The PM Who Signs Off Anyway
This isn't really a story about designers. It's a story about organizations approving a production pathway before deciding who owns its failures. A PM greenlights a Figma Make prototype for a real feature because it worked in the demo and the quarter needs velocity. A founder tells the design team to just build it because engineering is backlogged three sprints deep. Neither decision is unreasonable in isolation. Together, they quietly hand implementation risk to the person in the room who was never asked to carry it, without giving them the review process that used to catch what they'd miss.
The framing where designers who don't understand system architecture are "becoming obsolete" gets this backwards. The people actually at risk aren't designers shipping with AI tools. It's organizations that let a tool's shipping speed outrun their own process for deciding what's safe to ship. A nail gun lets anyone frame a wall fast. It doesn't make anyone a structural engineer, and the wall doesn't care who fired the nails.
"Should designers code" was never really the question worth asking. It was a proxy for a harder one most companies have avoided asking out loud: when a tool lets anyone generate functional software, who is accountable for what it does wrong. The market didn't answer that question. It just made it possible to avoid asking it for another quarter, until the checkout flow a designer shipped through a prompt corrupts an order, and someone has to explain why nobody reviewed it.
Top comments (0)