I’ve been saying for a while now that the most expensive problem in design systems isn’t the one teams are actively trying to solve. It’s the one they’ve made peace with.
Figma’s announcement this week is a good example of what I mean. Claude Code to Figma lets you capture a running UI from a browser, whether that’s production, staging, or a localhost, and convert it into editable frames on the Figma canvas. From there, teams can annotate, explore variations, compare screens, all without asking anyone to run a build locally or narrate a screen recording. The friction it removes is real. I want to be honest about that before I get to the part that bothers me. And I’ll go further: for teams already prototyping in Claude Code or Cursor before anything touches a canvas, this isn’t a workaround. It’s a workflow that matches how they’re actually working.
What it still is, underneath both of those things, is a better screenshot. And we’ve been solving for better screenshots for a long time.
What the captured frames actually contain
When you capture a running UI and bring it onto the Figma canvas, what lands is a collection of editable shapes that look exactly like your UI. In every structural sense that matters to a design system, they’re empty.
Those frames aren’t linked to your Figma components. They don’t carry your token values. Your spacing scale, your component states, the constraints you’ve encoded over years of careful design system work, none of it transfers. What the team gets is something that can be annotated and rearranged, but that doesn’t know it’s a modal, or a card using your surface-secondary token, or a form inheriting your input component’s accessibility behaviour.
I’ve been writing about design system entropy for a while, and the core observation there was that AI tools surface every inconsistency in your system by building from what they actually see rather than what you intended. The captured-frame workflow introduces a different version of the same problem, working in the opposite direction. You start from a correct implementation in code. You pull it onto the canvas as a visual approximation stripped of its structure. The team explores variations from that approximation. Someone translates those variations back into implementation decisions. At no point in that chain does the design system actually participate.
The roundtrip describes a loop. A loop we’ve learned to manage rather than close.
The parallel I can’t stop seeing
I’ve spent enough time in this space to have watched design systems solve the same problem twice. Around 2010, 2012, the original problem was embarrassingly simple. We didn’t have a reliable way to share component code. That sounds absurd now, but it was true. So we built tooling and abstractions, and eventually Sketch, and eventually Figma, specifically to solve the problem of getting the same button into everyone’s hands. It worked. And then tooling vendors, design teams, and the industry at large became so focused on the component as the deliverable that everyone stopped asking what it was actually for.
The component was never the point. Collaboration was. Consistency was. The component was the mechanism.
What’s unsettling about the current moment is that agentic tools are regenerating the problem we thought we’d solved without anyone noticing. A tool that spins up fresh React on every prompt isn’t reusing your components. It’s generating new ones that happen to look similar. Unless the design system you’ve built is structured as a genuine contract that those tools can read and reason against, you’re accumulating bespoke UI at speed and calling it productivity.
I’ve watched teams run Claude Code or Cursor at a prototype, ship it into review, then spend the next two weeks reconciling what was generated against a design system they never gave the AI access to. Deferred rework with extra enthusiasm attached to it.
The dynamic has a name, even if we don’t use it. Optimising the workaround. Every time we improve the translation between design and code rather than reducing the need for translation, we make the workaround more comfortable and the structural fix less likely. The tools get better. The gap stays.
The conversation I haven’t been able to shake
There’s a conversation between Elyse Holladay and Chris Strahl on the Design Systems Podcast from last year that keeps coming back to me. They were working through the difference between agentic tools that spin up fresh React on every prompt and tools that understand your design system well enough to compose from components that have already been through the process, through accessibility review, performance consideration, and the decisions your team has already made. The observation that landed hardest was about workflow. Most agentic tools don’t have one. There’s nothing attached to the generated output that tells you how to take it from LLM-produced to production-worthy. The speed is real. The path from that speed to something shippable is not.
I think it identifies the same gap I keep bumping into from a different angle. We’ve gotten very good at generating UI quickly. We haven’t built the tooling or the culture to ensure that the generated UI knows what it is, or honours what the system has already decided.
The roundtrip Figma is describing is useful for early exploration. What I’m noticing is that it implicitly accepts the translation layer as permanent, that design and code are two different worlds, that teams will keep moving things between them as the work demands. And every time we make that movement smoother, we reduce the pressure to ask whether it should need to happen at all.
What the better path is starting to look like
The design system is the interface. That’s the idea I keep coming back to. Not just for designers navigating a Figma library, not just for developers reading documentation, but for AI agents making decisions about what to build and how. If the system isn’t structured as something those agents can query and reason against, the AI has to guess. It will guess confidently. And it’ll be wrong often enough to matter.
The practical difference between system-level context and node-level context is significant, and it’s visible in the tooling if you look for it. The official Figma MCP works at the level of the individual element. Point it at a component node and it generates code informed by that component’s properties. That’s useful, but it’s still reading one piece at a time. Figma Console MCP from Southleft gives the AI access to the whole system as a queryable structure, tokens, component relationships, variables, how the pieces relate. When code gets generated against that context, it’s generated against something that understands the system rather than something reading a single node in isolation. I’ve found the output quality difference is significant, particularly for anything more complex than a standalone component.
TJ Pitre and the Southleft team are building toward a model where the design system isn’t a place you look things up. It’s a contract an AI reads at generation time. That’s a different premise from what most teams have built, but it’s the right one.
What designing in code would actually require
When I talk about wanting to design in code, I mean something specific. The decisions we call design, visual hierarchy, spacing, state behaviour, interaction patterns, should have a direct path into implementation without a human translator in the middle.
That requires, above everything else, a design system that functions as a shared contract rather than two separate artefacts that happen to resemble each other. Not a Figma library that design maintains on one side and a component library that engineering maintains on the other, with a quarterly sync to argue about which one is correct. One source. Tokens in a single location, propagating to both environments. Component properties that are identical in Figma and code because they’re describing the same API.
I covered this ground in Your next design system user is an agent, and the principle hasn’t changed. An AI agent consuming your system sees what you actually built, not what you intended to build. If the system lives in two parallel artefacts with a human translator bridging them, the agent is operating on approximations. It will fill the gaps, and those gaps will become technical debt you didn’t budget for.
The teams I’ve seen get closest to this tend to start with a specific question: if we deleted the Figma library tomorrow, would the codebase still know what it was building? If the answer is yes, you have a design system. If the answer is no, you have documentation with a pretty interface. Most teams, if they’re being honest, have the second thing. That’s not a criticism. It’s where most teams are when they start. The question is whether they’re building toward the first thing or just adding more translation layers on top of the second.
Tokens Studio with a GitHub sync, Style Dictionary for transformation, Figma component APIs that actually mirror the React props… It’s achievable. It’s just not the default, and the current wave of tooling is making it easier to avoid the work rather than do it. Every new smooth translation layer between design and code makes the underlying structural problem less visible, less urgent, less likely to get addressed.
Two versions of the same future
There’s a version of this where we end up in five years with translation tooling that actually works well. Code to canvas in milliseconds. Canvas back to code with full token fidelity. Collaboration happening fluidly across both environments.
And we’d still be running two parallel systems, kept in sync by increasingly sophisticated automation, with all the maintenance overhead and structural drift that creates.
The other version is one where the design system is the substrate both environments read from directly. Where a decision made in one place propagates to the other not through capture or export or handoff, but because they’re drawing from the same structure. Where AI agents generating UI are composing from a system that knows what it is, not generating approximations from visual reference.
I know which version I think we should be building toward. I’m not sure the tooling announcements of the past six months are pointing there.
The roundtrip is getting smoother. I’m more interested in why we need the trip at all.
Thanks for reading! Subscribe for free to receive new posts directly in your inbox.
This article is also available on Medium, where I share more posts like this. If you’re active there, feel free to follow me for updates.
I’d love to stay connected – join the conversation on X and Bluesky, or connect with me on LinkedIn to talk design systems, digital products, and everything in between. If you found this useful, sharing it with your team or network would mean a lot.
If you’re thinking about how your design system holds up for AI consumption, I built an assessment for that.
Design Systems for AI takes about ten minutes and gives you an honest read on where your system stands – what’s working, where the gaps are, and what to address first.
Member discussion