The Silent Killer of AI Design

Most of the discussion lately has been about whether AI can design. We tested a real design system using an AI agent and realized that is the wrong thing to put focus on. Having AI design turned out to be the easy part of the equation. The real issue was how the design system gave instructions to the AI. Whenever the system lacked clear details, the AI started guessing, and it was wrong every time.

To test this, we have an AI agent build a working screen using a design system of 51 components and a dedicated variable library. Technically the AI performed well, it used the correct components, bound colors and text styles to the right tokens, and did not make up custom elements. Even then, the final screen had nine mistakes, A human spotted eight of them, the automated testing agent only one.

This blog is not about whether AI will take over design, it also is not a product review. It is a reality check. With all the AI developments we now need design systems to work for humans AND AI Agents. While right now, most of the design systems are only built for humans.

Over the last year the conversation changed from: ‘Can AI make a believable screen?' To ‘Can it make the right one?’ Making screens with AI is no longer the hard part, and it gets cheaper with every new model update.

We tested this using standard tools that let an AI agent read and write directly in a Figma file, connected to a medium sized but well documented design system. Capturing the entire design system (51 components, 1101 variations and 275 variables) took just 5 requests. Building an actual screen took about 1 request per screen. Checking the final work however took longer than all above steps combined. And that review is where every single mistake was discovered.

And that right there is the major shift. Generating designs has become so fast and cheap that the models are not the limiting factor. The real bottleneck is whether your design system provides enough context for the AI to get it right.

Here is our core finding, which goes against how most teams write documentation:

The most valuable part of the design system we tested was not a component. It was written text. For example, one colour variable included a description: "Pair this with the danger text colour, never signal an error with colour alone." This single piece of context gave the agent an accessibility rule it never could have guessed correctly. Another component stated in its description that it has been tested against long text, single characters and right-to-left languages. That note told the AI what work had already been done, saving it from making bad assumptions.

And that is the key takeaway: write down why, not just what. A defined colour code tells AI what colour it is. A sentence tells the AI what that colour is for and what not to do with it.

Where these notes were missing, the AI failed in four predictable ways:

• Machine Readability: The system had zero links between its design components and the actual use case. The AI could see a button existed in the design file but had no way of knowing the methods of usage purely on the base component itself.

• Composition: Individual components worked fine by themselves, but failed when put together. A card, action buttons and a data display turned out to have different padding rules. When combined into one container, the layout broke because no single component spec explained how they should fit together.

• Fit: A list-row component worked correctly and looked on brand, but took up 80 pixels of height for a simple label and number. It passed all standard tests and checks for existence, but was useless in a compact data screen.

• Foundations: A colour combination passed accessibility contrast checks in light mode, but dropped to a failing ratio of 2.54:1 in dark mode on hover states. It passed all basic testing, but failed in the specific states nobody manually checked.

In every case the design system was correct, but silent. An AI cannot tell the difference between intentional design choices and missing context. When it finds a gap, it fills it directly. Confident, fluent, yet wrong.

This is in no way shape or form an argument against AI in design. It is an argument for doing things in the right order. We are building towards that in 3 steps.

A design system built for people is not a bad design system. Every gap mentioned in this post existed in a design system which could have been used successfully by teams of humans. Those gaps just became very apparent when a new reader showed up. One that cannot ask questions, cannot infer context from experience, and will guess rather than raise its hand when context is missing.

And that right there is the real change taking place. It is very easy to miss because the design system itself did not get worse. Instead, a new user has entered the chat and treats every undocumented rule as an invite to make something up out of thin air. To an AI, silence looks like permission.

The future design teams that stay ahead will not necessarily have the most polished design systems. The ones who realize they were writing for humans alone, and started writing for both humans and AI, will.