Figma → Production Code: a 6-step AI workflow

Most teams trying to generate UI code from Figma get a demo that works and a codebase that doesn't. The component comes out looking right, and six weeks later nobody can tell you which version of the button is canonical.

The failure is almost never the model. It's that teams give an AI agent a Figma link and expect it to infer everything a human designer already knows — what the product is, why it exists, what "secondary" means in this system, which states matter. You have that context. The agent doesn't. Everything below is about closing that gap systematically.

I developed this while leading a design system migration at a financial services company. It's written so another team can run it.

What you need first

Tool	Role
Figma	Source of truth: tokens, components, variants
A Figma MCP connector	So the AI agent can read your design files directly, rather than guessing from screenshots
An AI coding agent	Claude Code, Cursor, Copilot — the workflow is agent-agnostic
Storybook	Component documentation and isolated preview
A component framework	React, Vue, Svelte — the process doesn't care

The one non-negotiableThe Figma connector. Without it the agent is reading a picture of your design system instead of the design system, and everything downstream is a guess dressed up as output.

Step 1

Write the PRD before you write anything else

This is the step teams skip, and skipping it is why they get spaghetti.

The context you carry about what you're building and why — the agent needs that exact same context. Not a summary of it. It has no access to the six months of conversations that produced the design, so if it isn't written down, it doesn't exist.

The PRD

What you are building
Why you are building it — goals and objectives
Core features
What is explicitly out of scope — the most useful section, and the one people leave out
Tech stack
Links to every Figma screen to be built

A spec per screen

What is this page for?
What are the user flows on it?
What data is displayed?
What components does it need?
States and edge cases — especially the ones the Figma file doesn't show

/docs
  PRD.md
  /screens
    screen-1.md
    screen-2.md

Worth knowingThese specs can be AI-generated. Describe the screen to your agent and have it draft the spec in this format — then correct it. Editing a draft is faster than writing from scratch, and the corrections are where your judgment actually lives.

Step 2

Extract design tokens

Without tokens, colors and spacing get hardcoded across every file. Change a button color on twenty screens and you're doing twenty find-and-replaces, each one an opportunity to miss one.

// Without tokens — hard to find, harder to change
<button className="text-[#1B1F3B]">

// With tokens — defined once, changed once
<button className="text-primary">

Point the agent at your design system frame and have it produce a tokens.css of custom properties plus a framework config that references them. Group by: backgrounds, borders, text, actions, status, typography, spacing, radii.

Follow the naming that already exists in Figma. If your palette is Slate-100 and Primary-500, those are the names in code. Which brings us to the thing that actually decides whether this works.

The make-or-break detailWhen Figma layer and variant names don't match code conventions, generated code drifts immediately — and so does hand-written code, which is the tell that this was never really an AI problem. "Primary" in Figma must become primary in code. Not main. Not type1. Fix the naming at the source, once, before generating a single component. It's the least glamorous week of the project and it's the one that determines the outcome.

Step 3

Set up Storybook

Every component you build gets a matching stories file, automatically. This is what lets you review a component in isolation before it's buried inside a screen — every variant, every state, every edge case, on one page.

Keep it open in a second tab while you work. The feedback loop is the point.

Step 4

Build and refactor components — one at a time

The temptation is to generate twenty components in a batch. Don't. Generate one, review it, refactor it, then move on — because the corrections you make on component one are the corrections you'd otherwise make twenty times.

The review is the job. Specifically, check the things Figma structurally cannot tell the agent:

Props and API shape — is this a sensible interface, or a transcription of a layer panel?
Accessibility — focus states, ARIA, keyboard interaction, contrast. Figma has no opinion about any of it.
Edge cases — loading, empty, error, overflow, the 47-character name. A design file shows the happy path.
Composition — is it reusing your existing primitives, or has it quietly reinvented one?

Step 5

Assemble screens

Now the components exist, screens are assembly. Give the agent the screen spec from Step 1 and let it compose. If Steps 1–4 were done properly this is the fastest part of the process; if they weren't, this is where it becomes obvious.

Step 6

Refactor at the screen level

A final pass at the layer above the component: repeated patterns that should be extracted, hardcoded values that escaped tokenization, responsive behavior nobody specified, state that's living in the wrong place.

What this actually gets you

Not "AI writes your frontend." What it gets you is a design systems practitioner able to produce reviewed, tokenized, documented components at a rate that used to require a dedicated build team — while a front-end engineer reviews pull requests instead of implementing them.

The human judgment doesn't go away. It relocates: out of typing and into specification, naming, review, and edge cases. That's a much better use of a senior person, and it's the reason this works.

The part people underestimateNone of the above prevents the system from rotting. Generation is a one-time cost; drift is a recurring one. If nobody owns the library, if there's no contribution path, if changes aren't versioned — you will regenerate this in eighteen months. That's a governance problem, and it's the other half of the job.