Bidirectional Design-Code Sync? The Design-Code Roundtrip That Isn't

Jonathan Gordon

6

min read

Figma, Claude, and Codex announced bidirectional design-code workflows. Here's what they actually shipped — and the pain it leaves completely unsolved.






TL;DR

  • The "roundtrip" model is full of guesses at every step — nothing is compared, nothing is reconciled.

  • AI writes code faster than anyone can check it, so code drift is multiplying rapidly.

  • The more a team uses the design-code loop, the further the drift compounds.

  • AI generates; it doesn't maintain. That gap is where the next six months of pain comes from.




The demos look seamless. A Figma frame becomes React code in seconds. A running app becomes editable Figma layers. The narrative writes itself: design and code, finally in sync, AI-powered, bidirectional, round-trip.




None of that is actually happening. And the gap between the story and the reality is exactly where your next six months of pain is going to come from.




What Does Figma's Design-Code Roundtrip Actually Do?

Design-to-code (get_design_context)

Reads the node tree of a Figma frame and passes that data to an LLM, which generates code.

What it doesn't do: By default, it doesn't read your codebase, doesn't know your components, and doesn't know your design tokens. It generates fresh code from design data, probabilistically, as if your repository is a blank page. Figma's own developer documentation is direct about this: without manually maintained Code Connect mappings, "the model is guessing."




Code Connect

Lets teams manually map Figma components to their corresponding code components, so the LLM gets import paths and usage snippets instead of guessing from scratch. That's genuinely useful.

What it doesn't do: Code Connect is a manually maintained mapping layer — someone has to create each mapping, keep it current as the codebase evolves, and extend it every time a new component ships. It tells the LLM which component to use. It does not tell you whether the component used last week still matches the design updated yesterday. The mapping is a hint to the generator, not a check on what the generator produced.




Code-to-design (generate_figma_design)

Opens a browser, loads your running app, takes a screenshot of the rendered DOM, and uses AI to reverse-engineer approximate Figma layers from those pixels.

What it doesn't do: It's not reading your source code. It's not reading your design system. The layers it creates aren't linked to your components, your variables, or your tokens — they're a screenshot-derived shadow of what the running UI looked like at the time of capture.




The full loop, in one sentence: 




Design data → LLM generates code → browser renders it → screenshot → AI infers approximate layers.




Every arrow is a probabilistic guess. Nothing is compared. Nothing is reconciled. Error accumulates at every step.




This is a fast iteration tool for building new things. It only operates on what you're building right now, in this session, starting from scratch. It has nothing to say about the thousands of components already running in your production codebase, and no mechanism for detecting whether what just got generated matches your actual design system, or whether it still will in three months.




Why is code drift accelerating right now?

AI coding velocity has multiplied how quickly new code gets written. It has not accelerated the ability to verify that code stays aligned with the design system. The data backs this up:

  • In a survey of 22,000 developers across 4,000 teams, Faros AI (2026) found that code churn (lines revised or reverted within two weeks of being written) increased 861% over a pre-AI baseline.

  • The same study further found that the average PR size increased 154% and PR review time increased 91%.

  • The Stack Overflow 2025 Developer Survey found 80% of professional developers are now actively using AI tools, up from 44% in 2023 — this isn't a coming wave, it's already the default way software gets written.




Do roundtrip tools make design-code drift worse?

Yes. When generate_figma_design captures your running UI as Figma layers, those layers are not your design system — they're a pixel-derived approximation of one moment in your app's rendered state. If you edit those layers and then use get_design_context to generate more code from them, you're now iterating on a probabilistic approximation of an approximation, progressively further from your canonical design intent with every pass through the loop.




The demos show a beautiful first iteration. Nobody shows iteration twelve, after six engineers have each run the loop with their own prompts, their own Figma selections, and their own AI-generated output. At that point, no one knows what drifted, where, or by how much — and technical debt is now the number one frustration developers report, at twice the rate of the next biggest pain point.




Why doesn't manual auditing solve code drift?

Manual auditing is time-intensive archaeology: tracing changes, reconciling competing truths, deciding which side is authoritative. It only finds a fraction of actual drift, and by the time it's finished, new drift has already accumulated.




Inspection is the wrong response to drift because by the time drift can be detected manually, the damage is already distributed. What teams need instead is code governance — continuous, structural enforcement that makes alignment the default, not the exception.




What actually solves design-code drift?

Not better generation. Not a smarter screenshot-to-layers pipeline. Not a more capable LLM that approximates your token system slightly less often.




The solution is semantic comparison between canonical representations, continuous detection of divergence regardless of which side changed, and governed propagation of resolutions — with a human in control of every change that crosses the boundary between design and code. This is what ReWeaver AI builds.




Drift governance: Making the invisible visible. 

ReWeaver AI continuously compares what your design system specifies against what your codebase actually implements — semantically, not just visually. It understands that different representations can mean the same thing, and knows when those equivalences break. When implementation diverges from design intent, ReWeaver AI surfaces what drifted, where, and by how much — regardless of which side changed, and across your entire production codebase, not just the component you're currently looking at.




Governed bidirectional sync: closing the gap on human terms. 

Detection without resolution is just a reporting tool. ReWeaver AI goes further: when drift is detected, it proposes a resolution — a code change reflecting the updated design, or a design update reflecting what shipped in code — using your team's actual components, tokens, and conventions. Every proposed change goes to a human for review before anything crosses the boundary between design and code. The automation level is configurable — some teams review everything, others automate low-severity categories — but the principle is constant: the AI surfaces and proposes, the human governs.




Should you stop using Figma's roundtrip tools, Claude, or Codex?

No. Use every tool you have. Use Figma's MCP tools, Claude Code, Codex, Cursor. Generate as fast as you can; the velocity is real, and there's no reason to leave it on the table.




Just understand what those tools do and don't do. They give you a fast starting point for new code. They do not maintain the semantic integrity of your design system against your production codebase, do not detect the drift that accumulates every time any engineer generates anything, and do not close that gap in a way that's repeatable, governed, or grounded in your actual design intent.




That's what's missing — quietly, invisibly, compounding — for every team moving fast right now without it. ReWeaver AI is the part of this workflow nobody has built yet: the part that comes after generation, and makes generation sustainable.




FAQ

What is code drift? Code drift is the growing gap between what a design system specifies and what a codebase actually implements — caused by manual changes, AI-generated code, or design updates that aren't propagated to the other side.




Does Figma's Code Connect prevent design-code drift? No. Code Connect is a manually maintained mapping that tells an AI model which code component corresponds to a design component. It improves generation accuracy but doesn't detect drift between what's already shipped and the current design spec.




Can AI coding tools like Claude Code or Codex cause code drift? Indirectly, yes. These tools accelerate how fast new code is written but don't verify that generated code stays aligned with a design system over time, which is what allows drift to compound as usage scales.

Try out the ReWeaver Playground and see how much drift is in your code. We're actively recruiting a small group of beta testers. Join the beta!




References

Faros AI, 2026. The AI Engineering Report: The Acceleration Whiplash.

Figma Developer Docs, "Structure your Figma file for better code." Figma, 2025.

Google DORA Team, "2024 Accelerate State of DevOps Report." Google Cloud, October 2024.

Harding, B., "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones." GitClear, 2025.

Stack Overflow, "2025 Developer Survey." Stack Overflow, 2025.



 

Jonathan Gordon is the founder/CEO of ReWeaver AI. He has worked as a user-focused software designer leading design and engineering teams at Google, Microsoft, Oracle, Facebook, SAP, and Apple.