AI doesn't read your design system the way you do

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 generate a working interface in seconds — and most of the time it builds from whatever components it already knows, not from yours. Often that means 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 contributor to your UI (user interface) never opened it.

That's the quiet shift worth naming: the heaviest consumer of your design system in 2026 isn't a person reading your docs. It's a model. And it doesn't read the way people do.

Figma says 8px. Your code says 12px. Your design system documentation says 10px. The AI picks one — not always the same one — and generates fast, plausible output. Your docs site, your Storybook, your brand guidelines: multiple sources, each served through their own MCP, all in competition for the model's attention.

The systems we built for human readers are straining, too. In zeroheight's 2026 Design Systems Report, 56% of teams now use AI in their design-system work — but only 15% say it's living up to the hype, and adoption has been the number-one challenge five years running. The job changed, and the artifact we keep polishing is the wrong one.

A component is a cache

AI doesn't consume components. It consumes context.

A button in your design system is the output of a hundred decisions — when to use it, what never to pair it with, which legacy variant you trust, and why. The component is what's left after 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. People never noticed, because we rehydrate the missing decisions from memory and the person who built it. A model can't. It reads the cache as if it were the source and confidently ships the compression artifact as truth. AI didn't break your design system. It revealed that your design system was always a cache with no source behind it.

Picture it: an agent generates a checkout button, 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 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, not what your team decided about it. The richest part of your design system was never the components. It was the decisions behind them.

Same problem, two very different teams

This is where it splits.

If you're at a large or regulated organization, the risk is speed without control. AI generates production interfaces faster than any review process can keep up, and off-brand or non-compliant output is hard to catch after the fact. A governed answer — one trusted response when your design files, code, and docs disagree — is the guardrail that lets AI move fast while you still stand behind what it ships.

If you're on a smaller or mid-market team, the problem is the opposite. The headcount and maintenance of a traditional design system is more than you can carry. You don't need a cathedral. You need something you can point at your existing work and get value from in days.

Same architecture, two pains — and most of the market is solving neither. One camp races to automate code generation; another doubles down on documentation. Both improve the artifact that's no longer the point. The move is to treat the design system as the shared context people and machines both work from, and to govern it so it enables work instead of gatekeeping it.

That's the bet we're making with our Intelligent Product Engine — a control plane that gathers your design files, code, documentation, and guidelines, resolves what's true and what's in conflict, and serves a governed answer to whatever tool is doing the work.

A short test

You don't need a platform to start — you need to know where you stand:

• Are your tokens and names semantic — do they describe intent, not just appearance?
• Are the decisions behind your components written 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 no model can parse?
• When two sources disagree, is there a governed answer — or just an argument?

The unit that's missing has a name: the decision record — the reasoning a component was compressed from. And the metric is shifting with it. For a decade we tracked component coverage (how much of the UI is in the library); the AI-era number is decision coverage — how much of the reasoning behind it a machine can actually read. Here's my bet: by 2027, design-system maturity is measured in decision coverage, not component coverage.

The design system isn't over. It's been promoted — from a site people were supposed to read into the thing both people and AI build on. The teams that notice will be the ones whose AI builds the right button without being told. Faster generation through AI is a given. We're betting on knowing what's right.

Read the full piece → and, if you're curious where your own decision coverage stands, try our short readiness assessment.