Only 6 of 37 Design Systems Are Actually AI-Ready
By The WAALEE Team · · 5 min read
DesignSystems.One re-audited 37 design systems this September and published the results under a section it calls the Agent-Ready Index. The headline number is the one worth sitting with: 6 of 37 publish confirmed W3C DTCG tokens. Three ship Figma Code Connect. Of the 185 data points the audit tracked across those systems, 48 came back unknown, meaning the auditors couldn't confirm the answer from the repository tree at all. These are mature, maintained design systems, the kind every "how to build a design system" guide points to as the gold standard. Most of them still aren't readable by the agent you're about to hand a prompt to.
What "AI-ready" actually means here
The audit didn't grade on vibes. It checked three specific things: whether tokens are published in W3C Design Tokens Format with semantic names and machine-parseable types, whether an MCP server exposes those tokens and components as callable tools like list-tokens or find-component, and whether components ship as TypeScript-first contracts with discriminated-union prop APIs an agent can read without guessing. The page's own readiness checklist asks something concrete: can a fresh Cursor session find your tokens without browsing Storybook first? For most of the 37, the answer the audit found was no, or unknown, which in this methodology counts the same as a fail. Absence of evidence was treated as evidence of absence, on the reasoning that if an agent can't find it in the repo tree, it doesn't exist as far as the agent is concerned.
Even the famous ones didn't clear the bar
The detail that stands out is who missed. Polaris and Spectrum get cited constantly as examples of teams that "did tokens right," and the audit found both pre-spec or absent from the parts of their repository trees it could read. That's not a knock on either team's actual design work. It's a reminder that a design system can be excellent to look at and still be structurally invisible to a coding agent, because the two things were never built for the same audience. A Figma file and a style guide were built for designers and engineers reading documentation. An MCP-exposed token set and a typed component contract are built for something that calls a tool and expects a specific shape back. Most design systems, including very good ones, were never asked to do the second job.
The one library that cleared it without even trying for DTCG
The audit calls out shadcn/ui as the de facto default for new AI-assisted builds in 2026, not because it publishes DTCG tokens, but because it ships components as plain TSX files that live in your own codebase. An agent doesn't need an MCP server to read a component it can just open and edit directly. That's a different path to the same destination: instead of exposing a token API, shadcn/ui removed the abstraction layer an agent would have had to query in the first place. It's also why "why does every AI app look like shadcn" is its own recurring complaint, since copy-paste-into-your-repo is easy for an agent to follow and easy for a thousand other projects to follow identically.
- 6 of 37 audited systems publish confirmed DTCG tokens; 3 ship Figma Code Connect.
- 48 of 185 tracked data points came back unknown, meaning the audit couldn't confirm the answer from the repo at all.
- Polaris and Spectrum, often cited as model token implementations, were found pre-spec or unconfirmed in this specific audit.
- shadcn/ui's readiness comes from removing the lookup step entirely, not from DTCG compliance.
What this means if you don't have a design system at all
Here's the part the audit doesn't cover, because it only looked at teams that already built something: most businesses never had a design system to audit in the first place. No component library, no Figma file, no tokens.json sitting in a repo waiting to be graded pass or fail. Just a live website that happens to already express a real brand, real colors, a real type scale, whether or not anyone wrote it down. If 6 out of 37 teams that tried to build an AI-readable system actually pulled it off, the honest takeaway for everyone else isn't "go build one of those." It's that extracting the values straight from what's already shipped, as actual W3C tokens, skips the multi-quarter project these 37 teams attempted and sidesteps the 83% failure rate in the process.
Three different answers to "can an agent read my design system":
- DesignSystems.One Agent-Ready Index: The audit itself. Scores existing design systems against DTCG tokens, MCP exposure, and typed component contracts. A diagnostic, not a fix.
- shadcn/ui: Sidesteps the token question by shipping components as plain TSX in your repo, so an agent reads the component directly instead of querying a token API.
- WAALEE: For teams with no design system file to audit at all. Paste a live URL and get the real colors, type, and spacing back as W3C DTCG tokens plus AI-ready prompts for Claude, Lovable, v0, Cursor, and Bolt.
Build toward the grade, or skip the test
If you're one of the 37 and you want to actually clear this bar, the audit's own checklist is a reasonable to-do list: publish real DTCG tokens, stand up an MCP server over them, type your component props as discriminated unions. That's real engineering work, and it's worth doing if agents are going to keep touching your codebase. But most teams reading this aren't maintaining a design system that needs a grade. They're trying to get an agent to stop inventing a generic palette for a brand that already has a real one. For that job, the question isn't whether your tokens are DTCG-compliant yet. It's whether the values exist anywhere an agent can get to them before it starts guessing.