Developers have been building throwaway prototypes in Claude Code for months now. Quick UI experiments that never make it past localhost. The problem isn't the code. It's what happens after.
You build something in an hour. It works. Looks decent. Now you need feedback. So you take screenshots. Or record a video. Or worse, you ask someone to pull your branch and run npm install. By the time they see it, the moment's gone. The energy's dead.
Figma just shipped something different. You can now send live browser UI directly into Figma as editable frames. Not screenshots. Not static images. Actual Figma layers you can move around and change.
Reddit's already calling it the reverse of design-to-code. And they're right. For years we've gone from Figma to code. Now the flow works both ways. You start in Claude Code, build something real, then push it to Figma where your team can actually do something with it.
This matters because code moves fast but dies alone. Canvas moves slower but opens things up. When you're exploring, you want speed. When you're deciding, you want space. This gives you both.
Why code-first breaks down
I used to think building in code first was always faster. And it is. Until you need other people.
Code is single-player. You hold the context. You know which branch you're on. You remember what broke and why. But the second you want input, that advantage disappears.
Most devs share screenshots. Some record Loom videos. A few spin up staging environments. None of it's great. Screenshots freeze one state. Videos are hard to annotate. Staging deploys take time and still don't let anyone edit.
The moment you need collaboration, localhost becomes a prison.
Here's what actually happens: you build three variations of a navigation. They're all in code. All work. You want to compare them. But you can't see them side-by-side. You take screenshots and paste them in Slack. Someone comments "try moving the logo left." Now you're back in code making pixel adjustments based on text feedback.
What Figma actually built
The feature's simple. You're running something in a browser. Could be production. Could be localhost. Could be a staging server. You type "send this to Figma" in Claude Code.
It captures what's rendered. Sends it to your Figma file. Shows up as actual frames. Not flattened. Editable.
The Figma MCP server handles it. Same infrastructure that lets Claude read Figma files. But reversed. Code goes in. Frames come out.
You can capture multiple screens in one session. Preserve the flow. Get the whole user journey in Figma where people can see what comes next.
The roundtrip part
Most tools go one direction. Figma's built both.
Design to code has been around. Plugins that export React components. Tools that generate Tailwind. They're fine for starting points. Never perfect but useful.
Code to Figma is new. And it connects back. You capture UI in Figma. Make changes. Then use the Figma MCP to pull it back into Claude Code with a prompt and a link.
One Reddit user tested it with 11 app screens. Fed them all to Claude at once. Said GPT-5 struggled but Claude built the whole structure. Pages averaged 100-150 lines. Generated accurate SVGs.
The canvas lets you diverge. Code lets you converge.
That's the actual value. When you're exploring, you want options visible. When you're building, you want one clear path. This lets you switch between modes without losing work.
Setup's not hard
You need Claude Desktop app. Figma MCP server installed. A Figma access token with file-read permissions.
Configuration goes in Claude's MCP servers file. Someone on Reddit walked through it: create token, enable Figma MCP, add to claude_desktop_config.
Then it's just prompts. "Implement this Figma design" pulls from Figma. "Send this to Figma" pushes to Figma. The server handles translation.
The naming problem
Nobody calls this the same thing. Figma's blog says "Claude Code to Figma". The MCP page says "Figma plugin". Dylan Field's LinkedIn post says "Claude Code to Figma Design".
Developers just call it "the Figma thing." Which is fine. We're bad at naming. I once worked on a project called "Database Helper 2" because "Database Helper" was taken. Nobody questioned it.
The naming confusion doesn't matter. What matters is that it works across contexts. You're not locked into Figma Make. You can start anywhere. Localhost. Production. That random CodeSandbox you forked at 2am.
And this connects to something bigger. Tools used to force linear workflows. Design then code. Code then deploy. You had to pick a starting point and stick with it.
Now the boundaries are softer. Start in code if that makes sense. Move to canvas when you need it. Go back to code when it's time to build for real. The tool adapts to how you actually work instead of forcing a process.
When this doesn't matter
If you're working solo and don't need feedback, this is overkill. Just keep building in code.
If your team's already aligned and moving fast, adding Figma might slow you down. More tools isn't always better.
If you're building something small, a few components or a landing page, screenshots probably work fine. You don't need editable frames to decide on button colors.
This matters when exploration matters. When you need to compare flows. When your team's spread across design and engineering and you're tired of translation layers.
Also matters if you're using Claude Code heavily already. The integration's tight. If you're in Cursor or VSCode with different setups, it might not be worth the switch.
The actual shift
Someone on Reddit asked if you could push code back to Figma at scale. Modify designs directly from code. The answer's sort of.
You can send rendered UI to Figma. You can edit it there. You can pull the Figma version back into code. But it's not automated. It's still manual steps with prompts.
Which is fine. Full automation sounds good until you realize you don't want every localhost change syncing to your design files. You want control over what moves and when.
The shift isn't about automation. It's about optionality. You can start building without designer approval. You can share progress without deployment. You can explore in code then decide in canvas. The gates are gone.
I still think the best work happens when you're not switching contexts. When you're deep in code or deep in design. Not jumping between. But that's ideal state. Reality is messier. And for messy reality, this helps.