For years, we've been building design systems to make it harder for humans to make inconsistent decisions. Defining and enforcing things like:
- Here's the button.
- Here's the spacing scale.
- Here's the type hierarchy.
- Here's how a modal works.
- Here are the things you should and shouldn't do.
It made sense.
A growing team might have dozens or hundreds of people touching a product. The design system became a shared source of truth. It reduced the number of decisions each person had to make and helped the product remain coherent as the organization grew.
But we seem to be reaching the limits of that model, not because design systems are going away, but because the people consuming them increasingly aren't people.
We built systems for execution
Traditional design systems are very good at describing the output of previous decisions:
- A primary button is blue.
- A destructive action is red.
- The sidebar is 240px wide.
- Forms have this much spacing between fields.
That gives a designer or engineer a pretty good idea of what to build. What it usually doesn't tell them is why.
- Why is that action prominent?
- Why is this information visible here instead of hidden behind another click?
- Why do we interrupt the user before this particular action, but not that one?
- Why did we choose density over whitespace?
- Why does this workflow deliberately behave differently from the convention?
Humans have traditionally filled in those gaps.
- A designer remembers the research.
- An engineer remembers the incident that caused a particular safeguard to exist.
- A product manager remembers the argument from six months ago.
- A new person asks someone who was there.
Organizations carry a surprising amount of their actual design system around in people's heads.
Which works, imperfectly, when people are doing the work. It doesn't work so well when an agent is.
Agents are extremely good at following patterns
Give an AI coding agent a mature codebase and it can infer an incredible amount.
- It can see which components are used.
- It can find established patterns.
- It can copy the way similar features were implemented.
- It can inspect your tokens, styles, tests and documentation.
That is genuinely useful.
But there's a subtle problem.
A pattern tells the agent what usually happened. It doesn't necessarily tell it why.
Imagine an agent sees twelve forms where the primary action is aligned bottom-right.
It can reasonably conclude:
This product puts primary actions on the bottom-right.
But perhaps eleven of those forms are low-risk editing workflows and the twelfth is a financial transfer where the team deliberately changed the interaction.
Without the reasoning behind the system, the agent has no way to distinguish convention from intent.
It sees precedent. Not judgment.
And as agents build more of the software, I think that distinction becomes incredibly important.
The design system needs another layer
We've spent years making design systems increasingly machine-readable. Tokens were an important step.
- Instead of saying "use the slightly darker blue," we defined
color-action-primary. - Instead of arbitrary spacing, we created scales.
- Instead of recreating components, we created reusable primitives.
All of that makes software easier for machines to work with too. But it's still mostly describing what. The next generation of design systems also need to encode why.
Things like:
- We optimize for information density because our users spend several hours a day in this product.
- Expert users should be able to complete common actions without confirmation.
- Destructive actions must always be reversible or explicitly confirmed.
- Navigation should reflect the objects users think about, not our internal organizational structure.
- Existing muscle memory should not be disrupted without evidence that the new interaction is materially better.
- New features should reveal complexity gradually instead of expanding the default interface.
- When clarity and visual novelty conflict, clarity wins.
Those aren't component specifications. They're product beliefs. And they're much closer to what I actually want my agents to know before they start designing something.
The artifact is changing
This fundamentally changes the designer's job.
For me, design has always been about defining what can be done and how. Historically, we did that for people. A designer created an artifact. An engineer interpreted that artifact and turned it into software.
Something like:
Designer → design → engineer → software → user
But increasingly we're introducing another participant into that chain.
Designer → intent and constraints → agent → software → user
Sometimes there's still a Figma file in the middle. Sometimes there isn't. That's why I don't find the question of whether AI will replace Figma, or whether designers will start writing more code, all that interesting. Those are just implementation details, and they've changed multiple times over the history of design as a craft.
The more important change is that the thing being designed is increasingly the decision environment from which software gets generated.
That requires a different kind of design system.
Consistency isn't enough
There is an obvious danger here: agents are very good at making things consistent, possibly too good.
If you give an agent a component library and a codebase and tell it to build a new feature, the safest thing it can do is reproduce the patterns it already sees. That gives you perfectly consistent software. It can also give you incredibly average software.
Sometimes a new problem should look like the old problems. Sometimes it shouldn't.
Good designers know the difference because they're not just matching patterns. They're reasoning about people, context and intent. The goal can't simply be to give agents more rules. We need to give them enough context to understand when the rules apply, why they exist, and when they might need to be challenged.
That's a much harder problem than generating a component. It also happens to be a much more interesting one.
The system should remember
There's another reason this matters.
- Teams forget.
- People leave.
- Research gets buried in documents.
- Decisions that were obvious in the room become mysterious six months later.
Eventually someone looks at an interaction and thinks:
Why the hell do we do it this way?
Then they "clean it up" and occasionally rediscover exactly why it was designed that way in the first place. If we're going to have agents continuously working inside our products, there is an opportunity to make the reasoning behind those decisions persistent too.
Not just:
Button = Primary
But:
This action is intentionally visually dominant because user research showed people routinely missed it during the setup flow.
Now the system doesn't just preserve consistency, it preserves institutional memory, and the agent can reason with it.
Then you need the other half of the loop
Of course, intent written down isn't truth forever.
- Users change.
- Products change.
Something that was a good decision two years ago can become the wrong decision today, so the system also needs evidence.
Some of that evidence can arrive before anything ships. If the system says an action is intentionally dominant, that's a testable claim about attention, and it's the kind of thing we predict at EyeQuant before a design goes live. The rest only shows up once real people use the product, which is one of the ideas behind what I'm building with UXSense.
If an agent changes a product, I don't just want to know that the code passed its tests. I want to know whether the assumptions behind the experience still hold once real users encounter the change.
That creates a much more interesting loop:
Intent → generation → software → user behavior → evidence → updated intent
The design system stops being a static library of approved answers and becomes something closer to organizational memory.
A description of what the product believes, why it believes it, and evidence about whether those beliefs are still true.
Design systems were built to constrain humans
That was useful because humans are inconsistent. But machines have a different problem: they can reproduce consistency almost infinitely. What they don't inherently have is context, judgment or intent. It's probably a safe assumption that the design system of the AI-native software era won't primarily be a catalogue of components.
- The components will still exist.
- The tokens will still matter.
- The patterns will still matter.
But they'll be downstream of something more important.
A machine-readable explanation of why the product is the way it is.
Because when software is building itself, describing what to build isn't enough, we have to ensure it knows what we mean.