From Implicit to Executable
What AI-generated interfaces demand from Design Systems.
Over the past few months, a conversation has been growing across design Twitter, LinkedIn, Instagram or Threads: Design Systems are in crisis. Some people go further and claim they’ll disappear once AI starts generating dynamic interfaces.
The diagnosis points at something real: the Design System as we’ve documented it for the past decade is in crisis. But the industry has reduced “Design System” to a synonym of “component library”, and that’s a premise that needs to change. The debate is pointing at something deeper.
What is a Design System really, and what’s actually changing
The mistake starts here: assuming a Design System is its most visible manifestation, the component library.
It isn’t.
A Design System has multiple layers. The component library is just the skin. Underneath there’s:
Foundations — The conceptual rules about color, typography, spacing, accessibility. The principles, not the pixels.
Design Tokens — The abstraction that lets a color decision replicate across iOS, Android, web, and now, across AI-generated interfaces. They’re variables, not hardcoded values.
Patterns — The recurring solutions to flow problems, not just visual components.
Documentation and Processes — The guides for “when to use what”, “why we decided this”, and “how the system evolves”.
The problem is that many teams still think of a Design System as a visual inventory. But in a context where AI generates interfaces, the real asset isn’t the components. It’s the decision architecture behind them.
Because an AI doesn’t just need to know what a button looks like. It needs to understand:
What problem it solves and when it should or shouldn’t be used,
How it changes across contexts, platforms, and regulatory environments,
What constraints limit it and why those constraints exist,
How it relates to business intent and user goals.
That’s where a Design System actually begins.
The component library can transform radically. It can even disappear as we know it today. But that doesn’t eliminate the foundations, the tokens, the patterns, or the rules of the system. It actually makes them more important.
From tacit knowledge to explicit system
Here’s a point that conversations about AI-generated interfaces rarely address.
Yes, in the future AI will receive constraints, personality, business logic, and user context to generate interfaces dynamically.
But where do those rules come from? From the Design System.
What changes isn’t its existence. What changes is how it operates.
Today the Design System operates with a mix of explicit rules (documentation, tokens, components in Figma) and tacit knowledge (what the team absorbs through shared context, reviews, conversations). A lot of “when to use what” isn’t written down: it lives in the team’s accumulated intuition. And that works, up to a point, because humans interpret ambiguity.
With AI generating interfaces, that tacit knowledge stops being enough. Foundations, tokens, and patterns have to be structured as systems machines can interpret. Everything that gets absorbed today by osmosis has to become explicit.
It doesn’t disappear. It becomes more technical, more rigorous, and more critical.
Practical example:
Today you define a token like this:
json
{
"color-primary": "#0066FF"
}Tomorrow it could look like this:
json
{
"color-primary": "#0066FF",
"semantic-context": ["primary-action", "brand-signifier"],
"accessibility-contrast": "WCAG-AA",
"dark-mode-override": "#2684FF",
"applies-to": ["web", "ios", "android", "ai-generated-ui"],
"business-intent": "conversion-critical-action"
}The difference looks small. But conceptually it’s huge.
The first token describes appearance.
The second describes intent, constraints, behavior, and context. It’s defined by the organization as a whole, not just the design team.
Tokens have always been units of decision. What changes is that now they need to be that explicitly, because the AI requires parsing what was once implicit.
If there’s no absolute clarity about:
Purpose (what semantic intent the component solves),
Accessibility constraints (what standards it has to meet),
Contextual variations (how it changes between modes, platforms, or regions),
Scope of application (what surfaces it applies to),
Business priority (how critical it is for the organization),
…then the AI will generate interfaces that look visually correct but are strategically incoherent.
Pixel perfect was never the goal. It was always a consequence of well-defined rules.
The Design System is a strategic asset of the organization. It isn’t decoration delegated to the design team, it’s decision infrastructure that the whole organization needs to understand.
Because when AI enters the picture, the problem stops being “visual consistency” and turns into a much deeper question:
Does the organization actually understand its own rules and can it communicate them with precision?
If the answer is no, then you don’t have a Design System. You have a catalog of pixels.
And when AI tries to use it, it’s going to generate chaos.
The risks we’re underestimating
The future of AI-generated interfaces tends to be presented as something inevitably fluid: interfaces adapt, experience personalizes, the user receives exactly what they need.
But there are much more complex problems underneath that vision.
The coherence problem
If every user sees an interface dynamically optimized for their specific context, who guarantees that:
The experience is coherent across devices,
Users can share, socialize, or even use the product no matter whose device it is on,
There’s cumulative learning about how the system works.
Picture a support session: the user and the person helping them are looking at the same product, but not at the same interface. Different layout, different components, different flow. The user describes what they see, the person assisting them describes what they see, and the two don’t match. Multiply that by internal documentation that no longer applies, tutorials that no longer match the reality of whoever consults them, and user communities that can no longer teach each other because nobody is seeing the same product anymore.
Extreme personalization can easily turn into fragmentation.
And that’s where the Design System stops being a visual tool and turns into a system of limits and governance. Its function is no longer to dictate how something looks, but to define how much the interface can vary before it stops being the same product.
Without clear constraints, AI doesn’t generate better experiences. It generates personalized anarchy.
The ethical problem
And here’s where something even more delicate shows up: when the interface adapts dynamically to the user, the problem stops being only technical.
It becomes ethical.
Because “user context” also means profiling.
A delivery app detects that a user tends to order more when they hesitate and reduces the available options to push the decision. A finance app detects signals of anxiety in usage patterns and shows credit promotions in that moment. A productivity app notices accumulated fatigue and hides the pause option because it knows it reduces screen time. Each of those decisions is UX design. Each of them is manipulation.
If the AI modifies an interface based on inferred emotional states, behavioral patterns, or detected vulnerabilities, then design stops being only personalization and starts moving closer to behavioral manipulation.
The line between adapting to serve and adapting to extract is thin. And it gets crossed more easily when it isn’t written down anywhere.
A robust Design System can’t be limited to documenting visual appearance. It needs to incorporate explicit ethical constraints:
what can’t be optimized,
what patterns are forbidden,
what data shouldn’t influence interface decisions,
and what the acceptable limits of adaptation are.
Not as good intentions.
As technical rules the system cannot violate.
The maintainability and single-source-of-truth problem
There’s a structural problem behind all of this: the synchronization between reality and representation.
Because if AI generates interfaces based on structured definitions of the system:
Who keeps those definitions up to date?
What happens when the code evolves but the rules consumed by AI don’t?
What happens if the AI generates technically impossible compositions?
Today those problems are visible and annoying. A component with a bug looks weird. An outdated token jumps out in the next review. An obsolete pattern creates friction that someone is going to report.
Tomorrow they can be invisible and catastrophic. The AI generates a flow that looks correct but uses a field the backend deprecated months ago. It generates a component that passes visual tests but fails accessibility criteria because the new token didn’t propagate. It generates interfaces that work in 80% of cases and fail silently in the remaining 20%, with nobody knowing they’re failing.
That’s no longer a bug. That’s structural debt disguised as functional product.
Because a generative system depends entirely on the existence of a single source of truth that is consistent across design, logic, and code.
The designer’s new role
There’s a common claim in this conversation: the designer stops moving pixels around.
That’s true. But it doesn’t simplify the job. It makes it much more complex.
Complexity doesn’t disappear.
It migrates.
Today, a large part of operational work in Design Systems revolves around:
Maintaining libraries,
Documenting variants,
Updating components,
Chasing visual consistency.
A lot of that will probably be automated.
But what emerges in exchange demands a different kind of thinking.
The designer now needs to define ethical constraints as permitted and prohibited behavior inside the system, not as abstract principles. Saying “let’s avoid dark patterns” isn’t enough: you have to define which decisions are unacceptable, which signals can’t be used, and how behavior changes under different regulatory or cultural contexts.
They need to structure tokens that encode intent, constraints, business priorities, accessibility, and context of use. They need to design composition logic: how components combine, under what conditions, what relationships create friction. They need to understand information architecture, because the AI doesn’t render UI: it interprets context, rules, goals, and flows.
This implies knowing architecture. And it also means continuing to know visual design, as always, but now not to execute but to decide. The role doesn’t leave things behind. It covers more.
And above all, it covers a new responsibility: acting as a guard, not of the visual system but of the decision system. That means auditing, continuous evaluation, and accountability for the consequences of what the system optimizes.
The real question
The real question isn’t whether the Design System is going to die, or whether interface designers are obsolete.
The question we should be asking is how we evolve.
There’s an incomplete stereotype floating around in this debate: the designer who gets stuck in the visual without wanting to systemically understand the problems. That stereotype needs to be broken, because it appeals to an incomplete version of the role.
But there’s another challenge underneath, and it’s for everyone.
Automation is showing that we need more generalists than specialists. And that applies in the other direction too: strategists have to stop reducing UI to an arrangement of pieces that meet general usability and can be automated without supervision. That’s also an incomplete version of what designing experiences implies.
Real strategists understand that they can’t decide on what they don’t have command of. AI doesn’t solve a lack of judgment, it amplifies it.
That’s why they need to incorporate UI into their repertoire. Not to execute, but to set the limits and push the frontier that the biases of AI models themselves create.
The mindset shift applies in both directions.
AI makes building interfaces easy. It doesn’t make thinking them through easy. And that’s still the work.
Thanks for reading!
To read
The Organization Is the Bottleneck by Sarah Wells
Everyone is adopting AI coding tools. Engineers are writing code faster than ever. But are organizations actually delivering value faster? That’s not so obvious.