AI means your design system can't suck anymore

People patch the gaps. AI falls down the holes.

Jun 02, 2026

Many so-called design systems are really component libraries with some human support wrapped around them.

A library is where you put your artifacts.

The humans provide the system.

People explain what the documentation misses. They can tell you why a component works that way. The problems with the official pattern, and why it hasn’t been fixed. They’re the emergency service for a team who can’t find the artifact or guidance that quite fits what they need.

Design system teams patch the gaps with critique. Slack threads. Office hours. Design reviews. The accumulated judgment of the organization.

We got away with that for a good while now.

It’s not ideal. Not efficient. But it’s workable.

AI makes it a lot less workable.

That’s not because AI needs something fundamentally new from a design system. It’s because it exposes a requirement we’ve been fudging all too often.

A system that doesn’t know how it wants to be used isn’t incomplete because AI arrived. It was already incomplete.

Its humans were just better at workarounds.

It’s why I’m skeptical of the idea that making design systems “AI-ready” is a new category of work.

AI consumes information differently than a person browsing a docs site. Markdown, frontmatter, metadata, and retrieval-friendly matter in a way they might not for a human reader.

That’s an important representation layer.

It doesn’t change the concept of a design system.

Design systems have always needed to explain more than just what exists. They need to explain how to use what exists, why, what it replaced, where it can flex, where it breaks, and what to do when something’s missing.

That’s design system maturity.

It just happens to parallel AI readiness.

The real shift is this:

AI won’t let you get away with building a mediocre component library, calling it a design system, and relying on human ingenuity to patch over the holes.

Take away your components, and what have you got?

Salesforce Lightning, Google Material, IBM Carbon. These systems didn’t arrive as immaculate frameworks, independent of existing product realities. They emerged out of large organizations that were already shipping at scale.

They codified familiar solutions, refined them, integrated them with existing ways of working.

The best systems grow out of prior knowledge.

At IBM, Carbon has components, tokens, and documentation. But what makes it strong is that it has a stance.

It explains how the system wants to be used. It makes decisions visible. It gives teams accessible components, but also explains how IBM thinks about accessibility.

What to avoid. Where to extend. How to think when the answer isn’t obvious.

I pointed an AI at Carbon when I was vibe coding a personal project. It got a solid result.

Carbon hasn’t been magically reimagined for AI. Carbon is powerfully explicit about how the system works.

The operating model is more important than the components.

Broader product and brand intelligence still matters too. A design system alone can’t tell AI what your company should build or what your product strategy is.

The design system has a narrower responsibility. How to make its own operating model legible.

That means decisions on what the system encourages. What makes a good extension? Which are the patterns we like and which do we tolerate? Why did we change that component? What’s the justification for that exception?

Humans usually want to ask those questions.

AI powers past all the missing answers.

“Context-based” design systems, also known as “good” design systems

So much of this “AI-ready design system” conversation misdiagnoses the problem. It’s as if “context” is some mysterious new discovery that we need to add for the machines to use.

Not the thing that separated a design system from a component library in the first place.

The system is not just its visible parts. It’s the reasoning that connects them.

TJ Pitre at Southleft describes part of this problem well in his writing on context-based design systems. His diagnosis is right: components and tokens alone are not enough. AI needs the context around the system, not just the artifacts inside it.

But this isn’t a new model for design systems.

It’s the old model.

Except now it’s being tested by a consumer that can’t quietly compensate for everything we failed to document.

Plausible is not the same as good

AI design system demos can produce something plausible when the room’s furnished. The framework. The components. The tokens. Codebase conventions it can imitate.

Plausible is not the same as correct.

Plausible means it holds together in that moment. Consistent spacing, the right component names. It passes the first glance test.

Good means the decision makes sense.

Good means the pattern fits the use case. That we understand the accessibility tradeoffs. Know that the exception in the implementation is intentional and justified. That it respects the system.

You can’t get that kind of quality from just your artifacts.

It depends on the receipts behind the artifacts.

People carry a lot of that context informally. In the heads of people who’ve been around long enough, who take the time to talk about it. In the old email threads that live long past their expiration date.

That’s worked better that it might have.

It’s also failed regularly.

This is how design systems drift. It is also how products drift away from design systems. It’s why you can build an inaccessible experience from 100% accessible components. The pieces are correct. The composition is not.

Someone might have the artifact, but not the context, the nuance or judgment to make the artifact useful.

AI accelerates that. A lot.

AI reaches for what’s visible. Uses the semantically close component. Follows a statistically likely pattern. It will make something that looks kinda aligned and completely miss the reason the alignment mattered.

That is a design system problem exposed by AI.

Different format, same responsibility

We don’t need to invent a separate discipline or domain around “AI design systems”.

We need to be more rigorous in doing the work that good systems always required. Then make that work consumable by machines as well as people.

Write guidance that explains usage, not just availability.

Document the reasons why, not just the end outcome.

Use examples as evidence of judgment.

Be explicit about exceptions.

Explain what to do when the system doesn’t have an easy answer.

Structure the content well. So that humans can read it and machines can retrieve it.

The design systems that handle AI well are ones that already understand what they’re for.

They will have a point of view. Patterns grounded in use. Teams that have captured not only what they shipped, but why it was worth sharing.

AI doesn’t make that a new requirement.

But it probably removes our ability to pretend the artifacts were ever enough.

Robin Cannon

Ready for more?