By Robin Cannon, VP of Product, Knapsack
Ask an AI tool to build a screen today and watch what it reaches for. Inside tools like v0, Cursor, and Figma Make, a model will happily generate a working interface in seconds — and most of the time it builds from whatever components it already knows, not from yours. Often that's shadcn/ui, the open-source library these tools ship with and were trained on. Your team spent two years on a design system — the shared rulebook for how your product looks and behaves — and the fastest-growing consumer of your UI (user interface) never opened it.
That's the quiet shift worth naming: increasingly, the heaviest reader of your design system isn't a person scrolling your docs — it's a model. And it doesn't read the way people do.
The numbers say teams already feel it. In zeroheight's 2026 Design Systems Report, 56% of design-system teams now use AI in their work — but only 15% say it's living up to the hype, and adoption has been the number-one challenge five years running. We've wired AI into the work faster than we've given it anything good to work from.
I've argued before that the real work is product context, not components. This is the part I didn't show then: why the component model runs out of road when the consumer is a machine — and how you'd measure whether you've fixed it.
A component is a cache
Sit with what a component actually is. A button in your design system is the output of a hundred decisions — when to use it, what never to pair it with, which of your four legacy variants you actually trust, and why. The component is what's left after all that judgment gets compressed into something reusable. It's a cache. And like any cache, it's lossy: the decisions that produced it aren't stored inside it.
We never noticed, because people re-hydrate the missing decisions automatically. A designer looks at the button, half-remembers the thread where you killed the old variant, asks the person who built it, and fills the gaps from hallway memory. The cache was always missing its source — we just had humans to reconstruct it on the fly.
A model can't do that. It reads the cache as if it were the source, and confidently ships the compression artifact as truth. So here's the uncomfortable reframe: AI didn't break your design system. It revealed that your design system was always a cache with no source behind it.
What that looks like: an agent generates a checkout button. It picks a near-match, styles it close to your brand, and ships. It looks right. But it's the deprecated variant, it misses your accessibility rules, and it quietly drifts your checkout off-brand. The rule a human carries — never use the ghost button on a paid action — was never written anywhere the model could read it. The catalog described what the button is; it never captured what your team decided about it.
The richest decision records go deeper than the component. A service blueprint for that same checkout captures who the customer is and what they're trying to accomplish, the decisions your team made about how the experience handles their specific needs, and the guardrails that govern when the rules change. That's three layers of context a component rule can't carry — and the kind of structured, queryable record a model actually needs to build the right experience, not just the right button. Most teams have this context sitting in Miro boards no tool can reach.
Name the missing thing: the decision record
If components are the output, the source is the decision record — the reasoning a component was compressed from: when to use it, what to avoid, which variant wins a conflict, and why. Most teams have thousands of components and almost no decision records. The decisions live in people's heads, in closed threads, in the tribal memory a model can't query.
That gap is measurable — and I think it becomes the number that matters. For a decade we've tracked component coverage: how much of the UI lives in the library. The AI-era metric is decision coverage: what share of the decisions behind that UI are captured where a machine can read them. Two teams can have an identical component count and wildly different decision coverage — and it's the second number that predicts whether AI builds the right thing.
Two teams, identical component coverage. Very different decision coverage.
So the design system gets promoted — from a site people were supposed to read into the place those decisions finally live, where both people and machines can act on them. The hard part isn't writing decisions down; it's that they conflict. Your design files, your code, and your latest ticket disagree all the time, and pointing a model at all three just retrieves the contradiction. The real job is to reconcile the sources and serve one governed answer — the coordination problem that doesn't disappear just because execution got cheap.
Isn't this just better docs, or a search index over them? No — and the difference is the point. Documentation describes state; this governs decisions under conflict. Retrieval over contradictory sources only surfaces the contradiction; it can't tell the model which source wins.
The plumbing for moving that context around is standardizing in public — the Model Context Protocol (MCP) Anthropic introduced in late 2024 was donated to the Linux Foundation's new Agentic AI Foundation in December 2025. But plumbing was never the hard part. The governed answer you send through it is.
Same problem, two very different teams
If you're at a large or regulated organization, the risk is speed without control — and the payoff is real when you close it. Atlassian built exactly this: a "context engine" feeding its design system to AI through MCP, and reported output 52% more accurate and tasks 34% faster once the context was structured. A governed answer is the guardrail and the accelerant at once.
If you're on a smaller or mid-market team, the problem is the opposite. The overhead of a traditional design system — the headcount, the maintenance, the months-long rollout — is more than you can carry. You don't need a cathedral. You need something you can point at the work you already have and get value from in days. Same architecture, two pains.
Most of the market is solving neither. One camp is racing to automate code generation; Supernova raised $9.2 million in 2025 to push that further. Another doubles down on documentation. Both are good at what they do — and both are improving the artifact we just argued is no longer the point.
What to measure
You don't need a platform to start. You need to know your decision coverage. Four honest questions:
- Are your tokens and names semantic — do they describe intent, not just appearance?
- Are the decisions behind your components written down anywhere a tool could read them, or only in people's heads?
- Do your service journeys and blueprints live somewhere a tool can actually read — or only in Miro boards and slide decks no model can parse?
- When two sources disagree, is there a governed answer — or just an argument?
Sam Alexander, Principle AI Engineer at Knapsack, adds a dimension worth naming: evals. An eval is an automated check — you run your AI tool, compare its output to the governed decision, and ask whether it got it right. Sam's point is that you can only write a meaningful eval when you have one unambiguous answer to test against. If your design files, code, and docs all disagree, the eval has no stable ground truth. The decision record isn't just useful for AI to read — it's the precondition for knowing whether your AI is reading it correctly at all.
We have built the same architecture inside Knapsack — an AI knowledge base ingesting our own meeting transcripts, tickets, and customer records. The first hard lesson came immediately: source citations aren't optional. Without pinning which source an answer came from, you can't tell when a model is blending contradictory records and serving the mixture as truth. The citation is what turns retrieval into a governed answer — and it's what tells you when the governing failed. He's the one who taught me that "don't let sources conflict" and "cite every answer" are the same instruction.
Here's our bet: by 2027, design-system maturity stops being measured in component coverage and starts being measured in decision coverage. The teams who start writing those decisions down now — and govern them so they enable work instead of gatekeeping it — get a head start that compounds. The rest will spend another year wondering why adoption is still their number-one problem.
The design system isn't over. It's been promoted — from a site people were supposed to read into the infrastructure both people and AI build on. The teams that notice will be the ones whose AI builds the right button without being told.
Curious where your decision coverage stands? Connect with Knapsack today.
This piece reflects thinking across the Knapsack team. Particular thanks to Sam Alexander, Evan Lovely, Brennen Thaney, Carly Stevens, and Chris Strahl, whose work on AI context infrastructure, archetypes, service blueprints, and the governance thesis shaped the ideas here.
Sources
- zeroheight, Design Systems Report 2026 (56% use AI; 15% say it's living up to the hype) — report.zeroheight.com
- Robin Cannon, Design Systems Are Over. Product Context Is the Work. (Jan 2026) — robin-cannon.com
- Robin Cannon, Execution Is Cheap. Coordination Is Not. (Feb 2026) — robin-cannon.com
- Atlassian, Building the context engine for the AI era (52% more accurate; 34% faster) — atlassian.com
- Linux Foundation, Agentic AI Foundation / MCP donation (Dec 2025) — linuxfoundation.org
- Anthropic, Introducing the Model Context Protocol (Nov 2024) — anthropic.com
- Tech.eu, Supernova raises $9.2M Series A (Sep 2025) — tech.eu
- shadcn/ui on GitHub — github.com/shadcn-ui/ui
