AI design-to-code tools: what they produce, and what a design engineer still adds

Insights

Can AI turn Figma designs into production code? Three kinds of tool, what each leaves missing, and when output is a prototype, a start or shippable. Yes, AI can turn a Figma design into working code, and for a first version of a screen the cost is now close to nothing.

Short answer

Yes, AI can turn a Figma design into working code, and for a first version of a screen the cost is now close to nothing. What it does not do is make the hundredth screen consistent with the first. The tools produce code that looks like your design. They do not know your components, your tokens, your states or your review standards unless someone sets those up for them.

So the useful question is not which tool is best. It is what each kind of tool produces, what that output lacks for production, and when it is a prototype, a starting point or code you can accept. The rest of this page answers those three, then gives a two-week plan for testing one tool on your own codebase. We cover the tools here; for the method of translating a design by hand, see our Figma to React guide.

Three kinds of tool, grouped by what they produce

Tools in this space differ less by brand than by output. Group them by what you get back.

Kind	Input	Output	Good for	Missing for production
Prototype app builders: Figma Make, v0, Lovable, Bolt	A prompt, with an optional attached design or screenshot	A running web app, some with a backend and hosting	Testing an idea with users, aligning a team, exploring flows	Your component library and tokens unless you connect a design system (see below), full states, accessibility checks, real data wiring, tests
Component code from a frame: Figma's MCP server, Anima, Locofy, Builder.io	A selected frame or component	Code for that frame or component	Turning one well-built screen or component into a first draft	Behaviour beyond what the frame shows, consistency across screens, ownership by your codebase
IDE agents working from a design: Cursor or Claude Code, with the Figma MCP server	A frame link, plus your repository	Code written inside your project	Reusing components that already exist, following your conventions	Only what the rules and the repository tell it; unguided, it drifts

What each vendor says about itself is worth reading, because it tells you where the vendor expects the work to continue. v0 describes React, Next.js, Tailwind and shadcn/ui output with one-click deployment or a pull request. Lovable describes a working app with a frontend, backend and database whose code syncs to a Git provider and that engineering teams can review and maintain. Bolt describes a browser-based builder for web and mobile apps, and says web apps are built with JavaScript-based frameworks. Figma describes Make as producing designs, prototypes and web apps whose code you can edit. These are builders of apps, and the prototype label fits them by default. It fits less once a design system is connected, and each now documents a route for that:

Figma Make has Make kits, announced on 2 April 2026: packages a design system author creates from a library's code components (through npm), styles and tokens, plus usage guidelines that teach Make how to use them. On 28 May 2026 Figma also announced Make working in a team's connected codebase, with Git branches and pull requests. That one is a limited beta, on the Mac beta desktop app, behind a waitlist.
v0 documents a registry route that passes your design system's components and tokens to its models. Its guide is labelled legacy, with a newer Design Systems 2.0 workflow named as current, and it warns v0 is trained on default shadcn/ui, so heavy customisation of primitives may give unexpected results. See its design systems guide.
Lovable supports design systems built as React components, on paid plans. A project can connect to only one, and the docs say Vue, Angular and Svelte are not supported today.
Bolt lets you attach a design system as the reference for components, spacing, type and colour. Its docs say attaching does not change existing code, so you prompt it to update components.

So "missing your components and tokens" holds when no kit, registry or design system is connected. Whether the connected output then stays consistent across a hundred screens is what the plan below tests.

The second group is closer to your codebase. Figma says its MCP server can generate code from selected frames and extract variables, components and layout data into your IDE, and that Code Connect lets it reference your actual components so output matches your code. Anima, Locofy and Builder.io each document a route for mapping design components or tokens to code. For Anima, the component matching sits in its Frontier VS Code section, which its docs mark as Legacy; its current route is adding a Figma design system in its Playground. Locofy's component mapping, for one, is documented as an Enterprise-plan feature, so check the plan before you plan around it.

What the output leaves missing

The gap is the same across all three kinds. It is not mainly visual accuracy. It is everything the frame cannot say.

Your components, when nothing is connected. A tool that does not know your system can write fresh markup for a button instead of using the one you already ship. The mapping features above are the vendors' answer to this.
Your tokens, likewise. Figma's own guidance describes its MCP output as React with Tailwind, as a description of the design to be translated into your project's framework, styling conventions and tokens. If that translation is skipped, the values in the frame become values in the code.
States. A frame shows one state. Loading, empty, error, disabled, overflow and long-text states are not in it.
Accessibility. Keyboard order, focus handling, labels and announcements are behaviour, not appearance.
Data wiring. Real endpoints, permissions, pagination and failure handling.
Tests. Nothing in a design implies them.
Consistency across screens. Each generation starts without memory of the last unless rules carry it.

Independent evidence is thin. We found no published, methodical comparison of these named products on a real B2B codebase. The closest is Design2Code, a benchmark of 484 real webpages that tests multimodal models, not these products. Its authors report that models mostly lag in recalling visual elements and generating correct layouts. Treat that as a reason to test on your own screens rather than as a ranking.

Prototype, starting point or acceptable code

A rule for deciding what to do with output:

Prototype. It runs and looks right, but it does not use your components or tokens, or you cannot say where its data comes from. Use it to learn from users. Do not merge it.
Starting point. It uses your components and tokens in most places, and the gaps are listed: missing states, unchecked accessibility, no tests. An engineer finishes it, and the review is the same as for any pull request.
Acceptable code. It uses only your components and tokens, covers the states the design specifies, passes your accessibility and test checks, and a reviewer can explain every line. Expect a first pass to land in one of the first two groups, and test whether rules move it up.

Reviewing the third kind is its own skill; our page on what review is for now with AI-generated front-end code covers it.

What a design engineer adds

The work moves from translating designs to setting up the system the tools must obey. In practice a design engineer:

Keeps components and tokens in code as the single source, so there is something real to map to.
Connects design and code, for example with Code Connect or the mapping routes above, so a tool can find the right component.
Writes the rules the agent reads on every run. Figma's guidance describes custom rules for layout components, file locations, naming and what never to hard-code, kept in `.cursor/rules` for Cursor or `CLAUDE.md` for Claude Code, and Cursor documents how those rule files are applied.
Defines the states and accessibility behaviour a frame cannot show, before generation rather than after.
Sets the review that catches drift: what gets checked, by whom, against which screenshot or test.
Decides when output is thrown away rather than repaired.

If you want a hand with this, our design to code service is where that work sits, and our design to code audit looks at how your design and code currently line up.

A two-week plan to try one tool on your codebase

Days 1 to 2: choose and fix the test. Pick one tool from one group. Pick three screens from your product: a simple one, a data-heavy one and one with many states. Write down what acceptable code means using the three outcomes above.

Days 3 to 5: run it unguided. Generate all three screens with no rules and no component mapping. Record how many of your components and tokens appear, which states are missing, and what an accessibility check finds.

Days 6 to 8: add the system. Add the rules file, connect or map your components, and make sure tokens exist in code. Regenerate the same three screens.

Days 9 to 10: compare. Put the unguided and guided results side by side against your acceptance line. The gap between them is what the system setup is worth.

Days 11 to 12: add a fourth screen. One the tool has not seen. This tests consistency, which is the real claim.

Days 13 to 14: decide. Name which screens reached starting point or acceptable code, what review they needed, and whether the rules held on the fourth screen. Then decide whether to adopt, adjust or drop the tool.