Design to Code and Back

You screenshot a Figma comp, ask the model to build it. The layout looks right — but every spacing value is wrong. The issue isn't the model's vision; it's that screenshots are a lossy format for design data.

What vision is actually good for

Not design-to-code. But for reviewing work, it's useful:

UI accessibility review. Send a screenshot and ask "what accessibility issues do you see?" Good for catching missing focus states, poor contrast, and layout problems that don't surface in code review.

Extracting from diagrams. Architecture diagrams, ERDs, flowcharts — turning visuals into text or data structures. Useful for extracting schemas from old ERD screenshots and turning whiteboard flows into specs.

Comparing UI states. Send before/after screenshots and ask what changed. Quick visual regression review without tooling.

What it can't do reliably: precise measurements, reading small text, or spatial reasoning you'd trust in production. For those, use the actual design tools.

Design to code with Figma MCP

The Figma MCP bypasses screenshots entirely. Instead of inference from an image, the model gets direct access to design data: exact spacing, colors, component variants, layout constraints. The output lands much closer to production-ready. For the full workflow and setup, see Figma MCP Workflows.

Code back to Figma

The loop runs both ways. Figma's Claude Code to Figma lets you capture a live rendered UI — localhost, staging, or production — and import it into Figma as editable frames. See Code to Canvas for the full reverse-loop workflow.

When to use each approach

| Situation | Approach | |---|---| | Implementing a new component from design | Figma MCP → code | | Reviewing an implementation with a designer | Code → Figma capture | | Checking accessibility or visual issues | Screenshot + vision | | Syncing design tokens to Tailwind config | Figma MCP | | Getting design feedback on a flow | Capture multiple screens → Figma |