Most design systems are unprepared for AI
I asked an agent to generate a settings page using our design system.
At first look, the result looked reasonable. The right components were there. Buttons, inputs, toggles. Everything compiled. Everything rendered.
But something felt off.
Spacing was all over the place. Components were combined in a weird way, for example, the agent placed a destructive “Delete account” action next to the primary “Save changes” button. The agent had the docs, that was not the problem. What it missed was the part of the system people usually learn only through practice.
Placing some actions wrong might sound like a small thing. And on its own, it is. But when a single vibe-coded output contains fifteen issues like that, it becomes exhausting, and the likelihood of slop creeping into the codebase starts to rise.
Technically nothing was broken. But the page did not feel like it belonged to the product.
Everything was technically correct. But culturally wrong.
Design systems were built to guide humans, not AI. They assume the person using them will read the docs, learn the conventions, sit through reviews, and slowly pick up the unwritten rules of the system.
AI does none of that.
It sees components, props, and examples, then assembles something that works. But “works” is not the same as “belongs.”
The gap lies in the unwritten rules that shape how components are combined. Every design system contains patterns that rarely appear in documentation. Which components belong together, which combinations teams tend to avoid, and when one layout pattern makes more sense than another. In the past, only the largest design system teams had the time and resources to capture this layer well.
Humans absorb these patterns through reviews and repeated use across the product.
AI does not, unless those rules are made explicit.
Design systems for AI
Design systems now have two consumers. Humans and AI.
Humans benefit from explanations, examples, and visual documentation that explain design decisions.
It helps AI too, but AI also needs something different. It needs explicit rules and structured patterns.
Without that structure an AI model will treat a design system as a loose collection of components rather than a coherent system.
This suggests a different mental model.
What if a design system behaved less like a component library and more like a compiler?
Today design systems expose building blocks that developers and agents can combine freely. However a compiler does something interesting. It enforces rules.
If the code breaks those rules, it simply does not compile.
Imagine applying the same idea to UI. A design system would define not only which components exist, but how they are meant to be used together and which screen patterns are actually acceptable.
Generated UI would have to pass those constraints before it is considered correct.
From components to constraints
If AI is generating UI, the system needs to define more than components. It needs to define how interfaces are assembled.
Most products reuse the same few structures. Dashboards, settings pages, detail views, onboarding flows. Humans learn those patterns by working inside the product. AI does not, unless that structure is made explicit.
Sometimes that structure can be captured in templates, higher-level patterns, or composition rules. Instead of generating every screen from scratch, the model works inside known boundaries.
None of this is entirely new. Design systems have aimed at this layer for years through templates, composite components, and pattern libraries. What changes with AI is the urgency. Guidance that once felt optional starts to become infrastructure.
That is the shift. A design system starts defining not just what components exist, but how interfaces should come together.
What this means for design system teams
This also changes the job of the team maintaining the system.
In the past, a design system team could focus mostly on components, documentation, and adoption across product teams.
That work still matters. But if AI is now generating part of the interface, the team also has to define the rules that generation should follow.
That means capturing patterns that used to stay implicit. Which layouts are valid, which combinations are discouraged, where destructive actions belong, how dense a page can become, and what “on-brand” structure actually means in practice.
The work shifts from maintaining a component inventory toward maintaining a system of constraints, patterns, and guardrails.
In other words, design system teams are no longer only curating UI building blocks. They are increasingly defining the operating model for how interfaces get produced, on scale.
That is a different kind of responsibility. Less about documenting pieces in isolation. More about steering the behavior of agentic UI generation across the organization.
Where design systems go next
Design systems were built for humans.
They assumed someone would read the documentation, learn the conventions, and gradually understand the unwritten rules of the system.
But the next generation of UI will not be written only by humans.
It will increasingly be generated.
And when that happens, the most important part of a design system will no longer be the components it contains.
It will be the rules that shape how those components are assembled to highly polished interfaces.