The design-to-code gap just closed. A new workflow lets designers build screens in Figma using shadcncraft components, then AI reads the Figma file via MCP and generates production React using the same components. No translation layer. No drift. Both teams work in native tools, and the output is code developers can ship.
This isn't another "Figma to code" plugin that spits out div soup. It's a unified design system where designers compose with real components, and the generated code imports those same components from the project's actual library. The AI doesn't invent structure - it maps design to code using a shared vocabulary.
How It Works
Designers work in Figma with a component kit from shadcncraft - a collection of pre-built, styled UI elements. They compose screens the way they always have: drag, drop, arrange, adjust spacing. The difference is the components in Figma correspond directly to React components in the codebase.
When the design is ready, an AI model reads the Figma file via the Figma MCP (Model Context Protocol). MCP is a structured way for AI to access external data sources - in this case, the design file. The AI identifies which components were used, how they're arranged, what props are set, and generates React code that renders the same layout using the shadcncraft library.
The generated code isn't a pixel-perfect HTML recreation. It's semantic React: proper component imports, props passed cleanly, layout handled by the design system's spacing utilities. Developers get code they'd write themselves if they were translating the design manually. It's readable, maintainable, and uses the project's existing conventions.
Why This Matters
Design-to-code tools have existed for years. Most fail because they solve the wrong problem. They focus on visual fidelity - matching the design pixel-for-pixel - which produces brittle, non-semantic code developers have to rewrite. This approach solves the right problem: it preserves intent, not pixels.
When designers use the same component library as developers, the design IS the code structure. The AI isn't interpreting a picture and guessing what code would look like. It's reading a structured file that already describes components, props, and hierarchy. Translation becomes mapping, not inference.
That's why the output is clean. The AI knows a button in Figma maps to the Button component in React. It knows a card layout maps to the Card component with specific props. There's no ambiguity, no hallucination, no creative interpretation. The design file contains enough structured information that code generation becomes mechanical.
The MCP Layer
Model Context Protocol is doing the heavy lifting here. MCP is Anthropic's standard for connecting AI models to external data sources in a structured way. Instead of feeding raw Figma JSON into an AI and hoping it understands, MCP provides a clean interface: the AI asks for specific data (component names, properties, positions), and MCP returns it in a predictable format.
This matters because it makes the workflow reliable. The AI isn't parsing arbitrary design files and inferring structure. It's querying a well-defined API. That's the difference between "this works sometimes" and "this works consistently."
MCP also means the workflow isn't locked to one model. Any AI that supports MCP can read Figma files this way. As models improve, the generated code gets better without changing the Figma side of the workflow. Designers keep working the same way, developers keep getting better output.
What Developers Get
The output is production-ready React. Not "clean it up and ship it" - actually ready. Developers receive:
Component imports from the project's design system. No new dependencies, no inline styles, no magic. The code pulls from the same shadcncraft library already in use.
Proper semantic structure. The AI understands layout primitives - flexbox, grid, spacing tokens - and uses them correctly. The generated JSX reflects how a developer would structure the component if writing from scratch.
Editable code. Because the output uses real components and follows project conventions, modifying it is straightforward. Developers can tweak props, adjust logic, add state - the usual workflow. The generated code is a starting point, not a black box.
What Designers Keep
Designers still work in Figma. They don't learn React syntax, don't write code, don't leave their tool. The workflow respects their process. The only change is using a component kit that maps to production components instead of arbitrary design elements.
That constraint is also a benefit. Designing with real components means designs are inherently feasible. There's no "we can't build this" moment in handoff because the design already uses buildable pieces. The component library defines the possible, and designers compose within that space.
Some designers will resist this. It feels like a limitation compared to freeform design tools. But it's the same limitation developers work within - you build with components, not pixels. Aligning those constraints earlier in the process eliminates an entire category of friction.
The Catch
This workflow requires design systems discipline. You need a component library that exists in both Figma and code, with consistent naming and behaviour. If your design system is loose or your components drift between design and code, this breaks down. The AI can only map what's already aligned.
For teams without strong design systems, this is aspirational. You can't adopt the workflow until you build the foundation. But for teams that already maintain component libraries - which is most product teams at scale - this is immediately useful. The infrastructure is already there.
Where This Heads
The next step is bidirectional sync. Designers update Figma, AI regenerates code. Developers modify code, changes reflect back in Figma. Full round-tripping without drift. The pieces for this exist - Figma's API supports programmatic updates, and AI models can generate Figma files as easily as they read them. It's plumbing, not a research problem.
If that works, design and code stop being separate artefacts. They become two views of the same system. Designers work in Figma, developers work in code, and the AI keeps them synced. The "handoff" disappears because there's nothing to hand off. Both teams are editing the same component tree in their preferred interface.
That's the real unlock. Not faster design-to-code, but eliminating the distinction entirely. The workflow described here is the first version that actually works end-to-end. If it holds up under real use, the design/development split starts to look like a historical accident instead of a necessary division.