We recently used AI to build a new piece of UI using an existing design system. The first result looked good. It compiled, broadly matched the design and used familiar patterns from the product.
Then the design departed slightly from the existing system. It introduced a new border colour and a small variation on an existing component. Instead of treating them as extensions of existing patterns, the AI created new components from scratch.
Nothing it produced was obviously broken. The interface looked reasonable in isolation, but it was slowly building a design system of its own.
AI can generate interfaces, but getting it to generate interfaces that belong in your product is much harder.
A component library is not a design language
Most design systems give engineers a collection of components, tokens and documentation. They tell us what exists. The decisions around how those pieces should be used together are often less visible.
One of our form inputs had an option to preserve space for validation messages. The team had decided to always enable it because the form shifted whenever a message appeared beneath an input.
The component defaulted to leaving the space out. Engineers on the project knew to override the default. The decision had become part of the team’s shared knowledge, passed between people during implementation and code review. It wasn’t documented anywhere the AI could find.
Whenever the AI added a form, it used the default. It found the correct component and used its API correctly. It had no way to know that the team had established a convention beyond what the component expressed.
This is where a component library stops short of describing the full design language.
Components and tokens define the available vocabulary. Teams also make decisions about composition, hierarchy and behaviour. Which variants are preferred. How components should respond to loading and error states. Which optional properties should be used in almost every implementation.
People absorb these decisions over time. AI needs somewhere to find them.
What makes a design system AI-ready?
An AI-ready design system makes its components, rules and examples discoverable without relying on someone remembering whom to ask.
Components in design map cleanly to their production equivalents. Tokens are structured and consistently used. Component APIs guide consumers towards expected behaviour. Documentation stays close enough to the implementation to remain accurate. Examples show components working together in realistic situations. Tests verify some of these expectations.
These are familiar design system concerns and AI gives them a new consumer.
An engineer faced with a confusing API can search the codebase, inspect existing implementations or ask another engineer what the team normally does. An AI agent works from the context it has been given. If it finds three competing form patterns and incomplete examples, it has to choose between them.
It will usually choose something plausible. That can be difficult to catch because the resulting code often compiles, passes a quick visual check and looks reasonable in isolation. The inconsistency only becomes obvious when you understand the wider system.
An AI-ready design system makes those wider decisions visible.
Access is getting better
The tools around design systems are starting to expose more useful context to AI.
Figma’s MCP server can provide structured information about a design instead of requiring an agent to infer everything from a screenshot. Code Connect can link a component in Figma to its production implementation. Storybook can expose component APIs, stories and documentation. Its MCP integration also gives agents a way to render components and run tests. Component registries make existing implementations directly available.
An agent has a better chance of finding your Button when it can discover the real component and see how it is used, however that access only solves part of the problem.
It won’t explain why your team always preserves validation-message space unless the decision appears somewhere in the system. A Storybook story that demonstrates the default behaviour may even reinforce the wrong pattern. Several discoverable components that solve the same problem still leave the agent to decide which one to use.
The quality of the result depends on the quality of the system being exposed.
Defaults carry more weight now
Our form-input problem could have been addressed through documentation. The component API offered another place to capture the decision. If every implementation should preserve message space, the default should reflect that.
Component APIs already guide engineers towards particular outcomes. AI agents follow that guidance very literally. They reach for the available component, accept its defaults and continue building. A good API makes the expected behaviour the easiest path.
That might mean changing a default, removing an option with few valid uses or introducing a higher-level composition that encodes the team’s preferred layout. A recurring component variation might belong in the design system instead of being recreated with local styles each time.
Some decisions will always depend on product context and need explanation. Others can be captured directly in components, tokens and tests.
Every decision encoded in the system is one less decision an engineer or AI agent has to rediscover.
Start with the mistakes
Teams can start by looking at what AI already gets wrong. Ask it to implement a small workflow using the existing design system. Watch where it invents a component, reaches for a raw colour value or chooses an unwanted variation. Pay attention to the corrections an experienced engineer makes during review. Those corrections point towards specific gaps in the design system.
The agent may create a component because the existing one was difficult to discover. It may use a raw value because the appropriate token was unclear. It may choose the wrong variant because every documented example used the default. It may assemble the right components incorrectly because the expected composition lived only in the team’s shared knowledge.
Each mistake gives you something concrete to improve. Take the component and connect it to its implementation. Update the default, encode the common composition and add a test that captures the expected behaviour. Then run the same task again.
The useful measure is whether the system helped the agent make a better decision without another carefully worded prompt.
AI exposes the gaps
The real design system is usually spread across Figma libraries, production components, documentation, code review comments and the memories of people who have worked on the product for years.
AI has none of that shared history unless we make it available.
It will use the default. It will choose the first plausible component. It will recreate a pattern when the existing one is difficult to find. Those choices reveal where the system depends on knowledge it has never captured.
Preparing a design system for AI means making those decisions clear, discoverable and verifiable. That helps AI generate interfaces that belong in the product. It also helps the next engineer understand why they were built that way.
