Last Wednesday, my designer pinged me on Slack with a screenshot: “Is this… our checkout flow?” It was. I’d vibe-coded a working checkout page with Claude Code the night before, and she was staring at it in Figma — fully editable, layers intact, auto-layout applied. Figma’s new Code to Canvas feature had turned my rough prototype into something she could actually work with.

For the first time in maybe two years of managing this team, the designer wasn’t starting from scratch to match what engineering had already built. That felt significant.

What Code to Canvas Actually Does

Figma partnered with Anthropic to build a bridge nobody asked for but everyone needed: you take code generated by AI tools (Claude Code, Cursor, whatever produces React/HTML), and Code to Canvas converts it into native Figma components. Not a screenshot. Not a flat image. Actual editable layers with auto-layout, proper text styles, and component structure.

The workflow looks like this:

  1. You build a working UI with an AI coding tool
  2. You paste the code (or point it at a URL) into Code to Canvas
  3. Figma generates an editable design from the rendered output
  4. Your designer refines it, applies brand tokens, iterates

It’s essentially reverse-engineering design from code, which sounds backwards until you realize this is how half the industry works now anyway. Engineers vibe-code something, ship it, and designers retroactively try to make it look intentional.

Three Real Projects, Three Different Outcomes

Project 1: Internal Dashboard (✅ Worked Great)

Our team was building an internal metrics dashboard. I’d prototyped the layout in about 45 minutes with Claude Code — cards, charts placeholders, a sidebar nav. Standard stuff.

Code to Canvas nailed it. The Figma output had proper frames, text was editable, spacing was roughly correct. My designer spent about 3 hours cleaning it up and applying our design system tokens. Previously she’d have spent a full day recreating the layout from my screenshots.

Time saved: roughly 4-5 hours on a task that usually takes a full day.

Project 2: Marketing Landing Page (⚠️ Mixed Results)

This one was trickier. The vibe-coded landing page had custom gradients, overlapping elements, and some CSS tricks. Code to Canvas handled the basic structure fine but flattened the gradient overlays into single rectangles and missed some responsive breakpoints entirely.

My designer ended up keeping maybe 60% of the output and rebuilding the rest. Still faster than starting from zero, but not the seamless experience Project 1 suggested.

Project 3: Complex Form Flow (❌ Mostly Useless)

A multi-step form with conditional visibility, error states, and inline validation. Code to Canvas only captured the default state — no error variants, no conditional branches, no loading states. Which makes sense — it’s reading rendered HTML, not application logic.

My designer looked at the output, said “I’ll just start fresh,” and did.

What I Actually Like

The mental model shift matters. Before Code to Canvas, the workflow was: designer designs → engineer builds → designer reviews → repeat. Now there’s a viable path for: engineer prototypes → designer refines → both iterate. For internal tools and quick prototypes, this is genuinely faster.

Component recognition is surprisingly good. It correctly identified buttons, input fields, and nav elements as distinct components. Not perfect, but better than I expected for a v1.

It makes vibe coding less wasteful. Previously, when I’d prototype something with AI, the design team would ignore my output entirely and redesign from scratch. Now at least the spatial relationships and hierarchy carry over.

The Honest Downsides

It only captures one state. Any interactive UI has multiple states — hover, error, loading, empty. Code to Canvas sees exactly one. This makes it useless for complex component design, which is where designers spend most of their time anyway.

It encourages a bad workflow. There’s a real risk that teams start treating “engineer vibes it, designer cleans it up” as the standard process. That’s backwards for anything user-facing. Good design should still precede engineering for customer-facing products. This tool is best for internal tools and prototypes — if your team uses it for everything, your UX will suffer.

The Figma output isn’t properly tokenized. Colors come through as hex values, not design tokens. Font sizes are pixel values, not typography styles. Your designer still has to manually reconnect everything to your design system. For a team that’s disciplined about design tokens, this creates extra cleanup work.

It’s solving a problem that’s about to disappear. If AI coding tools keep improving — and they are, rapidly — teams might skip the “refine in Figma” step entirely. Figma is building a better on-ramp to a highway it doesn’t control. CNBC made this exact point in their coverage, and Figma’s stock performance adds pressure to prove these features matter long-term.

Who Should Actually Use This

If you’re a tech lead managing a small team building internal tools — this is a clear win. Your designers can stop recreating what engineering already built.

If you’re building customer-facing products with a proper design system — use it for rough exploration only. Don’t let it replace your design-first workflow for anything users will see.

If you’re a solo developer who doesn’t have a designer — this is honestly less useful, since you’d be importing into Figma just to… look at what you already built in code.

The Bigger Picture

Code to Canvas is interesting not because of what it does today, but because of what it signals. The traditional waterfall of design → engineering is dissolving. Tools are converging. The people who thrive will be the ones comfortable working in both directions — designing in code and coding from designs.

My team has been experimenting with AI across our workflow for months now. Code to Canvas is the first tool that actually changes the relationship between design and engineering, rather than just making one side faster.

Whether Figma survives the SaaS correction long enough to iterate on this is another question entirely. But the concept — bidirectional flow between code and design — is here to stay, regardless of who builds it.

Quick Verdict

  • Best for: Internal tools, prototypes, design-eng alignment on layout
  • Worst for: Complex interactive components, anything requiring design system tokens
  • Time saved: 30-50% on simple layouts, near-zero on complex UIs
  • Should you try it? Yes, but set expectations. It’s a good v1, not a revolution.