Design-to-Code That Survives Review

The screenshot pipeline fails for a knowable reason: a flat image destroys the design's structure. Auto-layout constraints, spacing tokens, variable bindings, component instances, interaction states — none of it survives rasterization, so the model reconstructs structure by guessing, and its guesses are trained on everyone else's designs, not your client's. Design-to-code that survives review is a context problem before it is a generation problem: feed the machine the design's data, not its picture. That is exactly what the Figma Dev Mode MCP server exists to do — and this module covers the full pipeline: MCP context, Code Connect grounding, structured fidelity review, managed pipelines like v0, keeping design files honest afterward, and doing all of it NDA-safely on client work.

What You'll Learn

• The Dev Mode MCP pipelineselection to layer tree, variables, and screenshots to generation
• Code Connect mappinggenerated code emits your components, not rebuilt primitives
• Structured fidelity reviewmultimodal screenshot diffing; eyeballing retired
• The v0-class boundarywhat managed pipelines may own, and what they may not
• Code-to-canvas handbackdesign files stop lying after code-side iteration
• NDA-safe design-to-codeclient files handled safely in services contexts

The Dev Mode MCP Pipeline

The Figma Dev Mode MCP server turns "look at this design" into structured tool calls. Connected to Claude Code, Cursor, or VS Code Copilot, the agent can pull — for your currently selected frame — the real layer hierarchy, auto-layout constraints (direction, gap, padding, sizing rules), the variables and styles bound to every node (spacing tokens, color variables, type styles by name), component and instance relationships, and a rendered screenshot for visual reference. The generation prompt changes character completely: instead of "make it look like this image," it becomes "implement this layer tree, honoring these constraints, using these named tokens."

Operating discipline, in order:

1. 1Select tight. Select the specific frame or component in Figma before invoking — the selection is the context scope. Whole-page selections drown the model in irrelevant nodes; component-level selections generate best.
2. 2Pull structure first. Have the agent fetch the layer tree and variables and summarize them before generating. This surfaces missing bindings early — a design full of detached hex values will generate detached hex code, and you want to know that before, not after.
3. 3Generate against your system. All M2 conditioning still applies: instruction files, exemplars, and — the design-side half — Code Connect (next section). MCP context tells the agent what the design is; conditioning tells it what code to say that in.
4. 4Keep the screenshot in the loop. The rendered frame image rides along as a visual check for what the tree can't express — layered effects, image treatments, optical alignment.
5. 5Review structurally (the section after next) — the pipeline reduces deviations; it does not eliminate them.

Code Connect: Stop Regenerating Primitives

Even with perfect structural context, the agent faces a choice at every component instance: emit your <DatePicker> or rebuild a date picker from divs. Code Connect removes the choice. It maps Figma components to code components — this Figma Button is @acme/ui's Button, this variant property maps to this prop — so MCP responses carry the code-side truth alongside the design-side node, and generation emits imports instead of imitations.

This is the design-to-code twin of M2's registry grounding, and together they close the loop from both ends: Code Connect grounds what the design references, the registry grounds what code exists. Teams that wire both report the qualitative shift Divya saw — review conversations stop being about rebuilt primitives and start being about composition and states. Mapping is platform-UI work (each component once, maintained as the system evolves), which makes it a design-system team deliverable with track-record ROI: every mapped component is a class of fidelity deviation that can no longer occur.

Structured Fidelity Review: Diff, Don't Eyeball

Human eyes normalize. After two hours on a screen, 16px and 20px look the same, and the review that relies on squinting ships Divya's eleven deviations. The replacement is mechanical:

The workflow behind that panel: render the implementation (Storybook or the running app), capture screenshots at the design's breakpoints via Playwright or chrome-devtools-mcp, export the Figma frame, and hand both images to a multimodal model with a structured request — "list every discrepancy in spacing, type scale, color, radius, shadow, and missing states; be specific; cite locations." The model is a tireless deviation-lister; you adjudicate each line (intentional deviation vs. defect vs. design-file staleness). Fix, re-capture, repeat until the list is empty or every remaining line is an approved deviation. Lab 02 runs exactly this against a frame with five seeded deviations — passing means your review sheet catches all five.

The v0-Class Boundary

Managed pipelines — v0 with Figma import, custom design-system bindings, and a Git panel that opens PRs — compress the whole flow into one product. Used with a contract, they are a legitimate accelerator; used without one, they are an off-system code firehose with merge access. The contract that works:

• v0 may ownmarketing and landing surfaces, internal tools, prototypes, first drafts of low-risk screens; exploration of layout alternatives at conversation speed.
• v0 may draft, humans re-implementproduct surfaces headed for the design system: harvest structure and copy, rebuild on-system through the MCP pipeline above.
• v0 may not touchcore product screens with complex state, anything with auth or payment logic, and any repo path where your off-system lint (M2) would fire; its PRs enter through the same gates as every AI PR (types, a11y, visual diff — M1).

The test for whether a surface belongs inside the boundary: if a fidelity deviation or an off-system component on this screen would cost real review time to catch, it goes through the full pipeline, not the managed one.

Code-to-Canvas: Keep the Design File Honest

Design-to-code has a return path now. After code-side iteration — the built screen evolved through review, the file didn't — the design file is lying, and every future generation from it inherits the lie. Code-to-canvas handback (Claude Code's generate_figma_design integration, from the Figma partnership) captures live running UI back into editable Figma layers, letting designers pull reality into the file instead of reconstructing it by hand. Treat it as a sync tool with a review gate on the design side — designers adjudicate what the canonical frame should absorb — and verify current availability before making it a team dependency; at launch it was Claude Code-exclusive.

NDA-Safe Design-to-Code on Client Work

For services engineers, the client's Figma file is client IP — and design assets leak through sloppier channels than code does. The "can I paste this?" decision tree extends to designs:

The habits are cheap: default to the client's tool tenancy, keep a redaction pass in your screenshot workflow, and when no sanctioned multimodal path exists, fall back to structural review (computed-styles export plus the layer tree — text, not pixels) which most client Copilot deployments can handle.

Try It Now

1. 1Run the two-pipeline comparison. Take one frame you have access to. Generate once from a screenshot paste, once from structured context (Dev Mode MCP, or manually pasted layer/variable data). Count fidelity deviations in each against the file. The delta is the pipeline's value, measured on your own work.
2. 2Draft one Code Connect mapping. Map your most-used component (probably Button) from Figma to code. Regenerate a screen that uses it and confirm the output imports instead of rebuilds.
3. 3Do one structured fidelity diff. Screenshot a shipped screen and its frame, run the multimodal discrepancy prompt, and adjudicate every line: defect, intentional, or stale design. Most engineers find at least one shipped deviation nobody ever caught — and one place the design file is lying.

Your playbooks & labs

This module's playbooks: pb-09 (Figma Dev Mode MCP: From Frame to Production Component), pb-10 (Code Connect Mapping), pb-11 (Visual Fidelity Diffing with a Multimodal Model), pb-12 (v0-Class Pipelines with an Explicit Ownership Boundary), and pb-13 (Code-to-Canvas Handback). Lab 02 is the proving ground: a provided Figma file, five seeded deviations, and a fidelity-and-a11y review sheet that passes only when you catch all five.

Further Reading

• •
  Figma — Guide to the Figma MCP server — the canonical setup and capability reference.
• •
  Figma — Claude Code and Figma: set up the MCP server — the agent-side wiring.
• •
  Builder.io — Figma MCP server, in practice — practitioner walkthrough with failure modes.
• •
  Vercel — Working with Figma and custom design systems in v0 — the managed pipeline's own boundary documentation.
• •
  alexbobes — Figma MCP: the CTO guide to design-to-code in 2026 — the organizational rollout view.