A few months ago I was talking to a design systems lead at one of the larger Polish product companies. He was telling me about their system with pride that was entirely justified - years of work, hundreds of components, coherent documentation, a token pipeline that finally did what it was supposed to do. And then he said something that stayed with me: “We finally have something that everyone understands and actually uses.”
I asked him if their AI coding tools used it too.
Silence.
Not because the question was stupid. Because the answer was more complicated than yes or no. His design system was built so that humans could understand it. So a designer would know when to use a primary button versus a secondary one. So a developer could read the documentation and start producing consistent UI within a week of joining the team.
All of that worked. And that’s exactly why AI had a problem with it.
Your design system has a new primary reader - one that doesn’t interpret, doesn’t bring years of product design experience to fill in the gaps, and doesn’t infer intent from prose. AI coding agents - Cursor, Claude Code, GitHub Copilot - are now consuming design systems directly, in real time, as structured data. Figma launched their Dev Mode MCP server in June 2025 (MCP: a standard protocol for AI agents to query external tools, including your system, instead of guessing). Affirm and Coinbase are already using it to build complex user flows. Spotify built their own MCP server for Encore so that Cursor generates code aligned with Spotify standards without any configuration on the developer’s side. Indeed, Notion, zeroheight - all doing the same thing, or building toward it.
AI agents became users of your design system. And they read it very differently than humans do.
You have a design system. The question is whether AI can use it.
The two design systems you already have
Most companies have two design systems. Not by choice. By accident.
The first lives in Figma. Beautiful variants, thoughtful properties, Auto Layout that actually works. Your designers love it, or at least tolerate it. It documents what the design team believes to be true.
The second lives in code. It has the components that actually ship to production. Its own props, its own variants, its own edge cases that only emerged during implementation. It documents what the engineering team believes to be true.
These two systems started as the same thing. But with every sprint they drifted a little further apart. A designer added a new variant in Figma - nobody updated the code. A developer refactored a component - the Figma file stayed old. Someone built a new version of a card directly in code because the sprint was too short to “do it through the design system.” And so on, for months, then years.
I saw this taken to its logical extreme once. A design system that had been growing for years, not fully reflected in Figma, and at the repository level had split into three separate systems - each with its own components, none of them matching across repos. A button. The simplest possible component. Existed as 47 independent implementations. Not one component with 47 variants. 47 separate components, written separately, living separately, inconsistent with each other in ways nobody had a full map of.
That’s not a failure of one sprint. That’s what happens when the drift has no mechanism to stop it.
The result is two sources of truth that constantly diverge - and unlike a human developer who might notice the gap and ask about it, AI will pick one source and commit to it without flagging the contradiction.
You know the symptoms. The exhausting ping-pong between design and dev during visual QA. Designers limited to perfect variants in Figma, with no way to check how a component behaves with real data. Developers writing the same component for the fourth time because “the one in the design system doesn’t do exactly what we need.” New team members learning tribal knowledge instead of reading documentation.
AI didn’t create this problem. It made it impossible to ignore.
When a developer sits with Cursor and asks it to build a component consistent with the system, the AI reaches for whatever documentation it has access to - and that documentation is almost certainly written for humans. It uses natural language. It describes intent without describing decision logic. “Use the primary button for main actions on the page” - a sentence that a human understands with years of context behind it. AI sees the phrase “main actions” and starts improvising about what that means.
Cristian Morales Achiardi, a design engineer at Enara Health, described exactly this. A developer asked Claude to generate a new component. Claude wrote var(–color-blue-500) in the CSS. The component compiled. The PR passed review. The color never appeared in the browser - because that token doesn’t exist in their design system. Never did, never will. Nobody caught it. Not the developer, not the AI, not code review. The component shipped with a silent failure baked in.
The developer didn’t know the token didn’t exist. Claude didn’t know either. Both had instructions - and instructions have gaps.
This is what happens when a system grows beyond one person’s head without structure that AI can actually query.
What AI sees when it reads your system
A developer can generate a button component in 30 seconds with AI. But that button won’t know it should use your danger token inside an alert. It won’t know it should be secondary inside a card. It won’t respect your spacing scale. The code is free. The understanding is the expensive part.
Romina Kavcic, who works on agentic design systems and spoke at the Into Design Systems conference this year, puts it precisely: “AI generates code. Design systems generate understanding.” The question isn’t whether AI will write your components - it will, and it does, right now. The question is whether it writes them with your understanding or with whatever it infers from the average of everything it was trained on.
Most design systems have what Kavcic calls an index - what components exist, what depends on what. Fewer have metadata: not just that Button exists, but that the destructive variant should always be paired with a cancel option, that it signals irreversible action, that it should never appear as the only choice. Almost none have the third layer: reasoning - the composition logic that tells an agent that a confirmation dialog for deleting a workspace should be Dialog plus Alert plus two Buttons, with color.bg.danger applied to the destructive action, not color.bg.primary. Without that layer, the agent guesses. And it guesses confidently.
Human-readable documentation describes intent: “Use the primary button for main actions.” Machine-readable documentation encodes decision logic: if this is the main action on the page, use variant primary, because it carries the highest visual weight. If the action is destructive, use variant destructive - and here’s what destructive means, here’s what it doesn’t mean. The difference isn’t cosmetic. AI, unlike a new hire, will never ask for clarification. It will fill the gap with whatever pattern is most common in its training data - which is almost certainly not yours.
Diana Wolosin at Indeed spent the past year making that gap measurable. She tested eight different configurations across 77 components and 1,056 prompts. Documentation in Markdown costs five times more in API costs than the same information in JSON, and generates hallucinations that JSON eliminates. Her rule: JSON for MCP, Markdown for LLM. In the four months after Indeed deployed this, their team generated 4,300 AI prototypes using components from their design system - not instead of designers, alongside them.
I keep coming back to that number. 4,300 prototypes in four months, each one using components correctly, within the system, without a designer in the loop for each decision. That’s what changes when the system is readable by machines.
Brad Frost, who’s been writing about design systems longer than most of us, draws a clear line between vibe coding and DS+AI - the AI constrained to your actual system rather than improvising from training data. Spotify put this into practice: when their team asked what happens when a developer asks Cursor instead of reading Encore documentation, they built an MCP server so that question doesn’t arise. Cursor generates Encore-compliant code by default - and to verify it actually does, they built a testing framework that measures how close AI-generated components are to the real thing.
The companies doing this well aren’t thinking about documentation. They’re thinking about infrastructure - something with the same status as your CI/CD pipeline or your database. Infrastructure is worth exactly as much as its adoption. A system that developers bypass - because it’s easier to ask AI than to search Storybook - isn’t infrastructure. It’s an artifact.
Where this is going and what it means for you
Morales built his system at Enara Health as the only designer on a team of engineers - ten developers, one designer, no design systems team. At the old pace of work, that was manageable. At the 3-4x faster development speed that AI delivers, it breaks - not because there aren’t enough designers, but because reviewing every visual decision and every component usage doesn’t scale to the new pace.
His benchmark: machine-readable infrastructure runs 2.5x faster, with 54% higher accuracy and zero false negatives compared to a system without it. He also built a token auditor that catches situations where someone wrote custom CSS duplicating functionality the system already provides - governance that previously required manual audits by someone who already knew what to look for. The cost of running it is nearly zero.
The hard part, he says, isn’t technical. “You have to articulate rules you’ve been following unconsciously. The process of building the token auditor forced me to write down what ‘correct’ means. Not as documentation, but as knowledge the system can execute.”
This connects directly to what I wrote in the previous letter about taste. A machine-readable design system does for organizational taste what a good designer does in a design review: it converts implicit knowledge into explicit rules, at a scale no individual can sustain. (If you can say why something works instead of just that it works - that skill transfers directly. You’re just not yet encoding it.)
One caveat worth naming: this only holds if the decisions being encoded are good ones. A poorly designed design system made machine-readable doesn’t become better - it becomes faster and more consistently wrong. AI will execute your bad decisions at scale just as faithfully as your good ones. Which means the work described in the previous three letters isn’t optional preparation for this one. It’s the prerequisite.
As Morales put it: “Most designers hand off decisions and hope. I encode decisions and know.”
The zeroheight Design Systems Report surveyed 147 teams this year. Only 40% have token pipelines - the rest sync tokens manually between design, documentation and code. Only 37% automate any element of their system. Gartner places design systems in the Trough of Disillusionment - the phase after hype, when reality checks the promises.
I don’t read this as design systems dying. I read it as a moment of sorting. Design systems built only for humans are completing their maturity cycle. Design systems built as AI infrastructure are just beginning theirs. The teams in the second group are a minority right now - but they’re generating 4,300 prototypes in four months and shipping with fewer implementation errors. That gap compounds.
The companies that have moved first aren’t the biggest or best-resourced. Enara Health is a digital health startup. Indeed is a job board. Neither of them waited for a budget approval or a design systems team of ten. They stopped asking “how do we get people to use our design system” and started asking “how do we make our design system the most precise answer to the question AI is already being asked.”
A year from now, developers at your company will ask AI about components regardless of whether your system is ready. AI will answer. The question is whether it answers with your system or with an approximation assembled from the average of everything it was trained on.
That approximation will compile. It will look fine in a PR. And somewhere in the CSS there will be a token that doesn’t exist.