The Space Between the Components
A mature design system makes the build faster. The opportunity is to spend that saved time on the work that determines whether anyone can actually use what we ship.
A design system can make every button look right, but cannot guarantee that the person clicking those buttons will finish what they came to do.
AI has not closed that gap. If anything, it has made the gap easier to see. That is useful, because now we can do something about it.
The same system, two different outcomes
Imagine one product manager, one engineer, one problem, and one mature design system.
In the first version, an experience designer joins them at the beginning. Before anyone opens a design tool, the team spends time understanding the task. What does the customer already know? What will they need to remember by the third step? Where are they likely to hesitate or give up?
Once those questions are clear, the team starts building. The components come from the system, but the flow comes from the thinking that happened first.
In the second version, the product manager describes the flow to an AI tool. The tool has access to the same system. It uses the right tokens, approved components, and accessible patterns. The screens look polished, and the engineer wires them up.
Both versions ship something consistent with the product. Only one may help the customer complete the task.
The difference is not the quality of the button component. It is the judgment applied between one component and the next.
What design systems solved
For the past decade, the industry has worked from a reasonable idea: if we build the system well enough, better experiences will follow.
That idea helped solve a real problem. Shared components eliminated endless variations of the same controls. Teams no longer had to redesign every button, modal, or input field. Products became more consistent, and engineers stopped rebuilding the same interface patterns from scratch.
At companies that invested seriously, much of that work is now mature. The parts are consistent. Yet those same companies can still ship flows that are pixel-perfect and frustrating to use.
Nathan Curtis has argued that the industry over-invested in the atomic layer: tokens, components, and primitives. I do not think that investment was a mistake. The atomic work simply has a natural endpoint. Once the parts are stable, the harder questions move up a level.
How should those parts come together across a task? What context needs to persist between steps? What happens when someone makes a mistake? How much are we asking a person to remember?
Those questions were never fully contained inside the component library.
The gap AI exposed
Brad Frost has described the issue clearly: agents consume design systems as written. They do not rely on intuition or infer what the team probably meant. Missing states, examples, and constraints show up directly in the output.
People used to cover those gaps without making much noise about it. A designer noticed that the empty state was undocumented and created one. An engineer realized that the transition between two steps would leave the customer without context and added a persistent cue. The system defined the surface, while people supplied judgment where the documentation stopped.
AI is less likely to hide that missing layer. It reads the available specification, produces what it was asked for, and fills any remaining gaps with its best guess.
That helps explain a pattern reported by Eleken, Figr, Superdesign, and Boldare. AI can generate polished interfaces quickly, but it still struggles with complex workflows, edge cases, and real product constraints. Individual screens look convincing while the full experience feels slightly wrong. Bolt.new was even documented repeating raw interface logic across eight screens rather than using one shared component.
The tools are already good enough to make the problem look finished. That is what makes this moment tricky.
A flow that nearly shipped
I watched this happen with a product manager who was comfortable working with AI. They described a flow in a chat window and refined the output over an afternoon. The resulting screens were clean, on-brand, and polished enough for an executive review.
The review went well. The concept began turning into a roadmap commitment, and the roadmap commitment started becoming an engineering specification.
Nobody had yet asked what the customer would actually be doing when they opened the experience.
The proposed flow required someone to remember six pieces of information across four screens without any persistent context. Every component was correct, but the experience as a whole was not.
What caught the problem was a simple request: "Walk me through what someone does with this."
That question changed the conversation. It forced the team to stop looking at the screens as a set of polished artifacts and start looking at them as a task unfolding over time.
The lesson was not that the product manager or engineer had failed, or that design had been excluded. The design system had done exactly what it was built to do. It made the build faster and kept the parts consistent. It had not removed the need to think about the person using them.
That work still has to happen, but it can be taught, scheduled, and shared across the team.
What happens as the models improve
There is an obvious challenge to this argument. AI could barely make a coherent screen a short time ago, and now it can produce entire flows. Why assume that usability or product coherence will remain outside its reach?
That is a fair question. Execution quality will keep improving, probably faster than most teams expect. A product manager with a mature system and a strong model may soon produce work that looks better than much of today's human-led output.
But generating a coherent option is different from deciding which option should exist.
If a model can produce ten plausible flows, the team still has to choose the one that fits this customer, this business, and this moment. Better generation gives the team better options more quickly. It does not remove the need to understand the people affected by the choice.
There is also a limit to what any system can specify. The richer the documentation becomes, the better an agent can follow it. Teams can add flow patterns, decision rules, recovery states, and examples. They should. But every real product eventually reaches a situation the system did not anticipate. Judgment begins where the specification ends.
We have seen a version of this before. Sketch made visual production easier, and visual designers moved further into systems and brand strategy. GPT-3 made basic copy easier to generate, and experienced content designers focused more on voice, structure, and strategy. Survey tools made data collection easier, while researchers spent more time on framing and interpretation.
When execution gets cheaper, the value of judgment usually rises.
What to do with the time AI gives back
A mature system and a capable model can turn days of production into an afternoon. That is a genuine advantage. The important question is what the team does with the time it gets back.
Document flows, not only components. Design systems have detailed rules for buttons, cards, and inputs. They need the same care at the flow level. When should a task live on one screen instead of three? What information must remain visible between steps? What should happen after an error? These decisions can be documented, reused, and improved just like components.
Review the experience as a sequence. A screen-by-screen critique will miss problems that only appear over time. Ask someone to play the customer and talk through the task from beginning to end. Where do they pause? What do they have to remember? When do they lose confidence? A short walkthrough can reveal more than another round of visual polish.
Teach flow thinking across the team. Product managers and engineers are capable of learning how to spot cognitive load, missing context, weak transitions, and broken recovery paths. Pairing them with a designer for a few focused hours each week will do more than adding a design gate at the end of the process.
Make selection an explicit part of the work. AI will generate more options than any team can use. The valuable skill is choosing which ideas deserve further investment. That choice should be grounded in customer knowledge, business context, and the consequences of getting it wrong.
What good can look like
A strong team does not begin by asking AI to generate everything it can. The product manager arrives with a grounded view of the problem and knows which directions are worth exploring. The engineer notices when a later step will strand the customer because the team has practiced looking for those moments. The design system describes not only what a good control looks like, but how good decisions, transitions, and recovery paths work.
In that environment, AI output becomes more trustworthy because the system around it has become more thoughtful.
Many companies still see a mature component library as the finish line. They are pointing AI at the library and expecting the rest of the experience to take care of itself. The teams that treat the system as a foundation will spend the next few years building the layer above it.
That difference will eventually show up in task completion, retention, and what customers say about the product when the company is not in the room.
The design system has done its job. It made the parts consistent and gave teams time back. Now we can spend more of that time on the whole experience, which is where the customer has been all along.