Figma Code Layers was the headline announcement at Config 2026, and within a week the internet had a dozen near-identical recaps of it. What almost none of them had was the thing that actually matters: an honest account of what happens when you put real work through it. This piece is the strategic reality of code living on the design canvas, what it changes, what it doesn't, and who should care, plus a clear guide to what to test on your own repository before you rebuild your workflow around it.
Because Code Layers is new and still rolling out, the finer specifics will keep shifting, but the shape of it is clear. What this post is really about is the underlying question every design-to-code feature has to answer: does putting code next to design actually close the gap between designers and engineers, or just move it. Code Layers moves the boundary in a real way. Whether it closes the gap depends entirely on details worth understanding before you rebuild your workflow around it.
What Figma Code Layers actually are
Figma Code Layers was the headline announcement at Config 2026, and within a week the internet had a dozen near-identical recaps of it.
Figma Code Layers are a layer type that brings working code onto the design canvas, so a frame can hold real code rather than only a visual representation of it. In practice, that means you can bring a codebase into a Figma file, work with the actual components that ship in the product, and move between the design representation and the code representation of the same thing, on the same canvas.
That's the shift in one sentence: for most of design's history the design file and the codebase were separate universes joined by a manual handoff, and Code Layers puts a piece of the codebase directly into the design environment. The design tool now has access to real code, not just a picture of what the code should produce.
What you can actually do with it
At a working level, Code Layers points at a few distinct capabilities, each of which changes a different part of the workflow.
Bring a codebase into the file. You can add a code layer from the toolbar, create one from an existing frame, or ask the Figma agent to generate one, and you can import a GitHub repository or upload a local folder directly. Rather than recreating components as static design elements, you work in the file with the components that actually exist in the product, which closes the oldest gap in design systems, the drift between the design library and the shipped components, because the file references the real thing rather than a designer's copy of it.
Move between design and code representations. Any design layer converts to an interactive code layer with a single click or a prompt, and you can extract editable design frames back out of code, with one click syncing the code layer to the design changes. So a designer can see and edit the code behind a component and, in the other direction, work on the rendered result as design. This is what makes the canvas a shared surface for both disciplines rather than a design-only space with a code export bolted on.
Extract interaction and flow information. Because the tool holds the real code, backed by React and able to pull in npm packages including motion and 3D libraries, it can surface how things actually connect and behave, not just how they look, which is information a static design file never had.
The reason these matter is not the novelty. It's that each one removes a specific translation step that used to introduce error and delay between design and engineering. Whether it removes enough of them to change your workflow is the real question, and it depends on what Code Layers does and doesn't replace.
The handoff it replaces, and the handoff it doesn't
Here is the analysis that outlasts any feature detail, and the reason to be precise rather than excited.
Every design-to-code feature makes the same implicit promise: handoff is dead, designers ship code, engineers stop rebuilding. And every one so far has run into the same wall, which is that producing code that looks like the design is a different job from producing code an engineer can own and maintain inside a real product. That distinction is the whole story of design-to-code, and it's covered in full in why export isn't handoff. Code Layers changes where the wall sits. It does not remove the wall.
What Code Layers genuinely replaces is the translation loss. When the design tool only ever saw a picture, everything about the actual code, its structure, its components, its behavior, had to be reconstructed by a human on the other side, which is slow and lossy. By putting real code on the canvas, Code Layers gives the tool the context it always lacked, so the design and the code can reference the same components and the same reality instead of a designer's approximation of them. That's a real reduction in the busywork and the drift that plagued handoff, and it's the legitimate core of the excitement.
What Code Layers does not replace is engineering judgment about the parts a design view can't see: how a component connects to real state and data, how it fits the app's architecture and conventions, how it behaves under load and at the edges, whether it's secure. Those decisions require knowing the whole system, not the component in isolation, and a design canvas, even one with real code on it, is not where that whole-system judgment lives. So the handoff that survives is the judgment-heavy part, and the handoff that shrinks is the translation-heavy part. A team that understands which is which will use Code Layers well. A team that believes the "handoff is dead" headline will hand engineers code that renders and doesn't fit, and wonder why the promised speed didn't arrive.
The honest framing: Code Layers is the strongest move yet toward closing the design-code gap, precisely because it gives the tool real code context, and it is limited by exactly the same boundary as every prior attempt, the difference between a component that looks right and one that belongs in the system.
Hands-on: what to test, and what to expect
The account that outranks the recaps is a hands-on one, so here is exactly what to put Code Layers through, and what to expect when you do. Clone a real repository into a Figma file and run a non-trivial component, something with state and data like a data table or a form, not a static card, through it: watch the import and setup, what converting to code produces and how usable it is, what converting a design change back does, where it saves time versus breaks, and how it handles messy input, long strings, an empty state, an error state.
What to expect, as informed prediction rather than tested fact: based on how every design-to-code tool has behaved, Code Layers is likely strongest on the presentation layer, the structure and styling of a component, and weakest on the integration layer, the state, data, and app-specific wiring, because the former is visible on the canvas and the latter requires the whole codebase. The real question your testing answers is how much Code Layers' access to real code narrows that gap compared to older export tools. If it narrows it meaningfully, that's the story. If it doesn't, that's also the story, and a more useful one than any recap will tell.
Where it breaks today
Every new feature ships with limits, and the honest ones are worth naming so readers can plan around them. A few practical ones: Code Layers is currently in closed beta and rolling out through a waitlist, so not every account has it yet. It runs on React and works within Figma Sites, and while it can sync changes back to your codebase, Figma frames it as a space for exploration rather than for pushing production-ready code straight into your pipeline, so treat the output as a proposal, not a deployment. Because availability, plan gating, and supported stacks are exactly the things that shift fastest as a beta matures, check the current Figma pricing and help pages for where your plan and seat stand before you build a workflow around it.
Beyond the tool-specific limits, the durable ones are architectural and worth stating from first principles. Code Layers can only be as useful as the connection between your design and your code is clean, which means it rewards teams that already have mapped tokens and one-to-one components and offers less to teams whose design and code are loosely related. It inherits the version-control problem that comes with connecting design to a live codebase, which is its own discipline covered in design version control. And it does not remove the need for the shared context and tooling that make handoff work, the kind of setup the Figma MCP server provides, so much as add a powerful new surface on top of it.
Who should adopt now, and who should wait
The right move depends entirely on how your team is structured.
Adopt now if you're a design engineer or a designer-heavy team that already works close to code. If design and engineering are the same people or sit tightly together, Code Layers removes translation steps you feel the pain of daily, and the presentation-layer wins alone are likely worth the setup. You have the context to use the real code well and to know where its output stops being trustworthy.
Explore deliberately if you're a product design team with a strong design system and mapped tokens. The value scales with how clean your design-to-code connection already is, so a team with real system infrastructure will get more from Code Layers than one without, and the sensible path is a focused pilot on one well-structured area rather than a wholesale switch.
Wait, or watch, if you're a design team handing off to a separate engineering org, or if your design and code are loosely connected. For you, the risk is repeating the "export equals handoff" mistake at a larger scale, sending engineers code that renders and doesn't fit, which creates more cleanup than it saves. This is the same tradeoff at the center of the broader no-code, low-code, AI-code decision, and Code Layers doesn't change its logic. Build the connective tissue first, then adopt.
Start Monday
If Code Layers is available to you, run one honest test this week rather than reading another recap: clone one real repository, put one real component through it, and write down where it saved time and where it broke. That single hands-on hour will tell you more than every launch summary combined, and it's the exact material this post is built around. If it's not available to you yet, do the preparatory work that makes it valuable when it arrives: map your most-used design tokens to code variables and get your top components corresponding one-to-one with code, because Code Layers rewards a clean design-to-code connection and offers little to a loose one.
Code Layers is the most significant step yet toward dissolving the boundary between design and code, and it's bounded by the same reality every prior step hit: a component that looks right is not automatically a component that belongs in the system. Use it for what it genuinely does, collapse the translation gap, and keep your engineering judgment exactly where it was, on the parts a canvas can't see. Test it on your own repo, verify the specifics, and you'll have the one account of Code Layers actually worth reading.