From Figma to Code: How AI Is Breaking the Handoff

Your Figma files were never the problem. The loop between them and the browser was.

The ticket says “match the Figma.” The linked frame shows a table with eight rows of clean data, a filter chip, and a tidy pagination control. What it does not show is what happens when the API returns four hundred rows, or zero rows, or one row with a company name long enough to wrap three lines. There is no loading skeleton, no failure toast, no filter applied while a previous request is in flight. The developer guesses at half of it, ships something reasonable, and two sprints later a QA engineer files a bug about the empty state nobody designed.

This is the part people usually get wrong about the death of the handoff. The old model did not fail because designers were sloppy. By 2024 the tooling existed and well-resourced teams had most of it: Dev Mode, variables mapped to tokens, component libraries, and Code Connect, which maps a Figma component to the real one in your repo so the code panel shows your

The Autopsy of the Old Handoff

The standard flow ran in one direction. A designer explored in Figma, got signoff, marked the frame ready for dev, and a PM turned it into a Jira ticket. A developer built it, a designer reviewed staging and filed pixel comments, and QA ran the test cases. Every step was a translation, and each one lost something that surfaced later.

Interaction timing never survived a static frame, and neither did responsive behaviour between the three breakpoints anyone drew. Real content was the biggest casualty, because designers use placeholder data that fits and production data does not care about line height.

There is also a cost nobody puts on a roadmap, which is the cost of asking. A developer hitting an undefined case either pings the designer and waits or decides alone. Across a sprint, with a distributed team and a few timezone gaps, the waiting compounds and the guessing accumulates into a product that drifts from what anyone meant.

Underneath it is a question about what a design actually is. In the artifact model, the design is a picture of an app somebody else will build, and its job is to be complete enough to execute from. In the software model, it is a running thing you can click and break, and the picture becomes an intermediate step you may not need.

What the New Stack Actually Does

Generative UI and fast prototyping. v0, Figma Make, and Claude Design sit here. You describe a screen or paste a sketch and get something working back in a minute. v0 hands you React with Tailwind, convenient if that is already your stack. Claude Design, in research preview from Anthropic Labs since April, renders live HTML on a canvas you refine through chat and pinned comments, then exports or hands off to Claude Code. Anthropic’s own guidance is blunter than the marketing: without a published design system the output is functional and generic.

None of this is production code, and treating it as such is the mistake I have seen most. These are the new wireframes, and they are interactive, so you can tab through a form and paste in a five hundred character job title to see what breaks.

Full-stack builders. Lovable and Bolt.new generate a frontend and wire up a backend, auth, and a database. Aimed at founders and PMs validating a workflow before spending engineering time on it. What gets produced is a decision rather than a codebase.

AI-native IDEs and repo work. Cursor and Claude Code operate inside the actual repository, with the actual component library, routing, and tests. Figma’s MCP server connects the two worlds. MCP stands for Model Context Protocol, a standard for handing structured data from one application to an AI tool, so the model gets your real variable names and component structure rather than guessing from a screenshot.

That connection now runs both ways. Through Figma’s Code to Canvas work with Claude Code, the server also writes: agents can create and update frames, components, and variables, and a live interface in a browser can be pushed back into Figma as editable layers rather than a flattened screenshot.

Figma itself. At Config 2026 in June, Figma announced Code Layers, in waitlist early access since July, which turns any design layer into an interactive code layer with a click or a prompt, lets teams clone a GitHub repository onto the canvas, and extracts flows from existing code as inspectable design layers. Dylan Field’s framing from the keynote was that code is material for design rather than its opposite. Yuhki Yamashita was more specific, describing it as a way to iterate on ideas rather than produce pristine production code, which is the disposable-draft argument above, said by the company selling the canvas.

Knowing which tool does what is the easy part, and it is not why most teams get worse output than the demos. Those run against clean, conventional, well-named code. Your repo is not that, and the tools read your repo.

One caveat before the sequence below. It assumes a mid-sized team with an existing design system, frontend engineers, and a QA function, because that is the shape I have worked in. A four-person startup has nothing to migrate, which makes Phase One an afternoon rather than a project. A large enterprise cannot put designers on PRs against shared components without a governance conversation I have not had. Both of those are inference. The middle is not.

Phase One: Tokens and Primitives Come First

Design tokens are named values for decisions that repeat: bg-surface-raised instead of #1C1F23, space-4 instead of 16px. The name is the point, because a name is something a human and a model can both look up.

Ask any of these tools to build a card in a project with no token system and you get hardcoded hex values, arbitrary padding, and a shadow that exists nowhere else. Ask the same where those names are real Tailwind theme values and the primitives come from shadcn/ui or Radix, and the output lands inside your system most of the time.

The model is not smarter in the second case. It is pattern matching against a codebase that has patterns: the same three shadow values across forty files, the same six spacing steps, one dialog implementation imported everywhere. That regularity is the signal. Where every card was styled independently there is no dominant pattern, so the model invents a plausible one.

Headless primitives do the other half. They ship the behaviour without the looks: keyboard navigation, focus trapping, ARIA wiring, escape-to-close, no styling at all. You write the appearance and inherit the accessibility work from somebody who audited it.

None of this is a sprint’s work. Defining the tokens is quick and reconciling them with what the product already ships is not, because every screen built before the system has a value that nearly matches and does not. That reconciliation is the project to budget for.

The last piece is a rules file, meaning CLAUDE.md or Cursor rules, the conventions you write down once so you stop retyping them: where components live, the naming convention, which state library you use, what you never want touched.

For the table in the opening, the missing tokens were the ones nobody thinks of as tokens: row density, the illustration slot in an empty state, the shimmer timing on a skeleton. Those are states a designer draws once and never names, so the model had nothing to match.

Phase Two: The Fast Draft Loop

Once the foundation exists, the loop gets short. Take the same filterable table. A designer sketches the structure, screenshots it, drops it into v0 with a paragraph of description, and has a clickable version in fifteen minutes. Not polished, but one where the checkboxes toggle, applied filters show as chips, and the empty result state appears when you filter everything out.

That last part is the payoff. The empty state that generated a bug in production is unavoidable in a running prototype, because you cannot demo a filter panel without at some point filtering everything out. Nobody has to remember to design it. A static prototype gets opinions about layout, and a running one gets people using it wrong in front of you.

Throw the prototype away, and expect to argue about it. Naming these builds as drafts in the demo, with a banner or a rough visual treatment, keeps the room from mistaking the speed of the artifact for the readiness of the feature.

Phase Three: Designers Working Inside the Repo

This sounds radical and turns out to be ordinary once a team does it for a month. A designer pulls the branch, describes the change in plain language, reviews the diff, runs it locally, and opens a pull request. The engineer reviews architecture and logic rather than spacing.

The changes that suit this are specific. Spacing and layout, copy, a missing empty state, a loading skeleton, responsive behaviour, a new variant of an existing component. What does not suit it is anything touching data fetching, state architecture, permissions, or performance. A designer restructuring how a dashboard loads its data will produce a PR that looks fine and behaves badly under real conditions.

The empty state from the opening sits on the first list. A designer who has already seen it in the prototype can wire it in the repo, and the illustration, the copy, and the reset affordance land in one small PR.

It is tempting to turn this into a syllabus, and most versions of this advice do. A designer does not need to write React to work this way. The model writes it, the browser shows the result, and the branching and committing can be handled by the same tool that made the change. What does not delegate is judgment about the diff: whether the change does what you asked, whether it quietly touched something you did not intend, and whether it was yours to make at all. Read the diff carefully and know where that boundary sits, and you can work in the repo without much else. Learn some React and skip the review, and you will ship confident mistakes faster than before.

The first month is worse, not better. Review load climbs, and designers break tests they did not know existed, usually snapshot and visual regression checks that fail on a two-pixel change nobody would notice by eye. One engineer generally absorbs most of that, and it goes better when the team names them and protects the time rather than letting it happen by accident.

Changing who writes the code changes what has to be checked, and that lands on whoever decides what gets tested.

What Changes for QA

Regression scope is the set of existing behaviour a change could plausibly break, and deciding it correctly is most of the skill in testing. A designer who edits a shared component has widened that scope to every screen importing it, and will usually have no idea. The PR looks small. The blast radius is not. Nothing in a diff shows the import count, which is why this needs a habit rather than a sharp reviewer.

QA in a prototype review is doing something different from QA on a release candidate. Nobody checks a disposable v0 build for defects. They check for missing states, because a prototype is the cheapest place to find out nobody decided what happens on permission-denied, and those states become the test cases later.

Acceptance criteria change shape rather than disappearing. When the artifact was a spec, the PM writing the criteria spent most of that effort describing an interface. When it is a working draft, the draft shows that already, and whoever writes the criteria can cover what it cannot: thresholds, failure behaviour, the accessibility requirements a demo on a fast laptop with a mouse will never reveal.

A generated component will pass visual review and fail a keyboard pass, and somebody has to tab through it before merge. Naming that person in your definition of done is the only version of this that works.

Where It Breaks

Vague inputs produce confident wrong answers. A developer looking at an underspecified frame asks a question. A model invents an answer and commits to it. That inverts an old safety mechanism, because ambiguity that used to trigger a conversation now resolves silently into a decision nobody made.

Which means you specify more, and the specification has to live where the model reads. Put a states table on the frame: one row per state, with empty, loading, error, single-item, overflow, and permission-denied as the default set. The rules file covers repo-wide conventions and screen-specific ones badly.

Accessibility is where output looks best and behaves worst. Generated interfaces are full of divs with click handlers, missing focus management in dialogs, and colour combinations that pass nothing. It looks correct, which is why it clears review. Audited primitives handle a good chunk, and the rest needs the keyboard pass.

State is harder than layout. Models are strong at producing a static tree of components and weak at reasoning about two requests landing out of order, or a filter change cancelling an in-flight fetch. That second one is the exact failure the opening table had, and it survived the AI-assisted version too, because a prototype nobody stress-tests looks fine when requests return in order.

System drift is the slow one, and the best documented. Every generated component that skips your primitives is a small tax you pay forever, and the industry numbers are worse than most teams assume. GitClear’s 2026 maintainability research, across 623 million analyzed changes from 2023 to 2026, found block duplication climbing from 40.3 per million changed lines to 73.0, an 81% rise and the highest on record. Over the same window the share of changed lines classified as moved, their proxy for refactoring, fell from 13% to 3.8%. That tracks code-change trends across the years when AI assistants spread rather than proving causation per line, and GitClear sells tooling in this space, but the direction is hard to argue with. It matches what a design system looks like eighteen months in: four button variants that look almost identical and a component library nobody trusts. Someone has to own the audit, on the board, with a name next to it.

So Is Figma Dying?

Duplication and drift are governance problems, and governance is what Figma has spent the last year repositioning around. So, no, not dying in any way that shows up soon. The prediction assumes Figma’s value was drawing rectangles, and rectangles were never the moat. What Figma owns is the space where a team thinks before anything is committed. Exploration is cheap on a canvas and expensive in a repo, because on a canvas you put nine bad versions of a screen side by side and let a PM, a designer, and an engineer argue about them.

The stronger evidence is that Figma has already absorbed the thing it was supposed to be killed by. Code Layers puts a cloned repository and live code onto the canvas as a layer type, next to design layers in the same file where comments already live, and the MCP server writes back into that file. That is not a company being disrupted by code. It is a company deciding code is another material on the canvas.

The genuine risk is narrower. Teams building simple, conventional interfaces increasingly skip the design file entirely. Whether that dents seat count is a question about a public company I cannot answer.

The Rise of the Full-Stack Product Builder

Job titles are lagging behind all of this. Most postings still split design and frontend, so people doing both usually do it inside a designer title, on a designer band, with an engineer’s review responsibilities quietly attached. The role has a name, design engineer, and outside a handful of companies like Vercel, Linear, and Notion, few teams are hiring for it yet.

What Actually Changed

The bottleneck moved. For a decade the constraint on shipping interface work was production capacity, and process design was mostly about routing work through a limited number of frontend developers. That has loosened enough that producing a working interface barely factors into planning.

Judgment did not get cheaper. Deciding which of five approaches is right, recognising when a generated interface is subtly wrong, knowing which edge case will hurt users. Those still run at human speed, and they now sit directly in the path of everything.

So the handoff did not disappear so much as change what it carries. What gets handed over is less often a specification and more often a working draft with an argument attached, and the conversation is about whether the argument holds, not whether the padding matches.

Same table, rebuilt on a tokenised system, prototyped in an afternoon, empty state discovered by a designer who could not avoid seeing it, shipped in a PR an engineer read in one pass.

The bug never got filed.

From Figma to Code: How AI Is Breaking the Handoff was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.