Most design systems were built for designers and developers. A third user just arrived, and it reads very differently.
Something shifted quietly in how design systems work, and I don’t think most teams have caught up yet. We’ve spent years building systems for humans, designers who open Figma, developers who read documentation, and product managers who occasionally glance at guidelines. The whole infrastructure of a design system: the component naming, the documentation style, the way tokens are structured, all of it was designed with a human reader in mind.
But there’s a new user in the workflow now. And it doesn’t read the way humans do.
AI coding tools, the kind developers are increasingly using to generate production code from design files, don’t browse your Figma library with curiosity. They don’t infer meaning from context. They parse structure, read metadata, and follow explicit rules. If those things are clear, they perform well. If they’re not, they guess. And when AI guesses, it guesses confidently, which is often worse than a blank screen.
This isn’t a distant future problem. It’s a right now problem. And the design systems that will hold up are the ones that start thinking about this transition before they’re forced to.
What happens when AI tries to use a system it can’t read
When an AI coding tool encounters your design file, it’s looking for structured information it can act on. It wants to know what a component is called, what its variants mean, what tokens it uses, and how those tokens map to code. When that information is clearly expressed, AI can generate accurate, on-brand code quickly.
When it isn’t, when layers are named “Frame 1337,” when tokens are ad hoc pixel values rather than named variables, when documentation exists only in someone’s head or in a Notion page nobody links to, AI fills in the gaps. It invents plausible token names. It drifts from your actual design values. It produces code that looks almost right but isn’t.
Figma’s Thomas Lowry, in his article, Why you should care about design context, put it directly: when layer names are unclear, AI is more likely to misinterpret the design, creating downstream problems for developers. A layer called “card” or “avatar” gives AI something to work with. A layer called “Group 47” gives it nothing.
This isn’t just a naming hygiene issue. It’s a signal that the entire way we’ve been thinking about what a design system is for needs to expand.
What “AI-ready” actually means in practice
The good news is that making a system more readable for AI also makes it better for humans. The two goals don’t conflict. Being explicit and well-structured has always been a good design system practice. AI just raises the stakes for doing it. Here are three things that matter most.
Tokens that mean something.
The shift here is from arbitrary values to a closed, semantically named system, and it’s one we already use in our work.
The idea is straightforward: design tokens operate in layers. Primitive tokens capture raw values like purple.500, or gray.200, and semantic tokens define how those values are actually used. Instead of padding: 16px being scattered across files, you use var(--space-200). Instead of a hex value that nobody will remember, you use background.interactive.primary.default, which tells both a designer and an AI tool exactly what that color is for.
The naming structure itself carries the logic. Primitive names like purple.500 don’t tell you anything about use, is it a button background? A focus border? A system error? Semantic names answer that question before anyone has to ask. foreground.system.success and background.interactive.primary.default communicate intent, not just value.
This matters for AI because, as Contentful’s Scott Rouse puts it, AI will not magically correct deficiencies within a design system. It amplifies and extends the foundational structures provided, filling what’s missing. A semantically named token system gives AI a closed set of named variables to choose from. Without it, AI invents plausible values and confidently does so, which is the worst kind of wrong.
The teams we see handling this well aren’t necessarily the ones with the most sophisticated systems. They’re the ones who treated token naming as a decision about meaning, not just a filing convention.
Documentation that’s structured, not just written.
Most design system documentation was written for humans who skim, infer, and ask follow-up questions. AI doesn’t do any of those things. The practical shift is writing guidelines as explicit rules, not prose explanations, and linking them directly to the components they govern, not keeping them in a separate doc nobody finds.
Figma’s Code Connect feature is one way to bridge this: it links Figma components directly to their coded counterparts and surfaces accurate snippets in Dev Mode. You can read more about how Figma's Code Connect works in Thomas Lowry's article. The principle behind it, that design and code context should be connected, not maintained separately, is the right direction regardless of which tools you use.
The most common failure I see is documentation that exists but isn’t connected to anything. It lives in a separate tool, nobody links to it from the components, and it gets stale within a month of launch.
File structure that communicates intent.
How you name layers, how you use auto layout, whether you annotate interactive states, these aren’t just hygiene choices anymore. They’re the language your design file speaks to the tools that generate code from it. A well-structured file with clear frame names, auto layout applied consistently, and annotations for interactive states gives AI agents enough context to generate code that actually reflects the design intent.
Why is this transition coming for every team
I want to be honest about where I’m standing when I write this.
Until recently, this wasn’t something I was thinking about either. At my last project, AI readiness for design systems wasn’t on the radar. We were focused on shipping. And right now I’m working on a project that uses an existing system we’ve adapted rather than one built from scratch. So this isn’t me reporting from the other side. It’s me mapping out what I can see coming.
What makes me confident it’s coming: the same data that shows design system buy-in dropped from 42% to 32% in a single year, according to Zeroheight’s annual survey. Teams are being squeezed, asked to ship faster, do more with less, and keep systems coherent while AI tools multiply around them. The systems without a clear structure are the first ones to get bypassed under that pressure.
But here’s what I keep coming back to: the teams that invest in this now will be in a good position regardless of how AI develops. Because a system that’s structured clearly for AI is also a system that’s easier to teach, easier to adopt, and easier to maintain. The clarity compounds. The transition from “built for humans” to “built for humans and AI” isn’t a rebuild. It’s a layer of intentionality applied to decisions you’re already making.
The practitioners who lead this won’t be the ones who react to it when they have to. They’ll be the ones who started thinking about it before anyone asked them to.
What to actually do with this
If you’re building or maintaining a design system right now, here’s how I’d think about prioritizing this.
Start with tokens. It’s the highest leverage change. Move from arbitrary values to a closed, semantically named token system. This helps developers, helps AI, and makes your system more teachable to new designers all at once.
Audit your layer naming. It takes an afternoon and immediately improves how AI tools interpret your files. Rename anything that reads as “Frame” or “Group” with a number.
Connect documentation to components. Whether you use Code Connect, annotations in the file, or a linked documentation page, the goal is that context travels with the component, not separately from it. If someone has to go looking for the documentation, most won’t.
Write for explicit rules, not inference. When you document decisions, write them as things AI can act on: “Always use space-200 for internal card padding” is better than “cards use comfortable spacing.”
None of this requires rebuilding from scratch. It requires deciding that readability, for humans and machines, is part of what quality means for your system.
The teams that make that decision now will be the ones teaching everyone else in a year.
No comments.