Our product UI was made with AI. To keep prototyping with AI, it needed a system.

The brief had two audiences. People: designers and engineers who need one trustworthy source. Machines: the AI agents that already generate our prototypes, and will only stay on-brand if every element has a name, a role and a rule.

I used Google's Material Design 3 as a benchmark for depth: every component on its own page, full variant matrices, real states, documentation. I was explicit that it was not a style to copy. The product's purple, its type and its density had to survive intact.

I organised the file the way people look for things: start here, learn the rules, find the part, see it in context. Each layer only uses the layers above it, so the structure itself teaches how the system works.

Three layers keep decisions where they belong. Primitives are hidden from designers so nobody picks "purple 600" by accident; they only pick a role such as action/primary/bg, which can change underneath without touching a single component.

I worked with Claude in Cowork, connected to Figma through the Figma MCP server. It could read the source file, write Plugin API scripts and build directly in our design-system file. My job was the brief, the structure, the taste and the review.

Each component page follows the same template: what it is, when to use it, anatomy, the full variant specimen and usage examples. Consistency is what lets a new designer, or an agent, learn one page and understand all of them.

This was the real test of the architecture. The workspace, the conversation panel and the modals below contain no hand-drawn buttons, tags or icons; every one is a live instance. Change the Button component, and every screen in the product follows.

The first pass looked finished. Then I started using it the way a designer would: clicking into variants, typing long labels, swapping icons. That is where the real work was.

"AI-friendly" isn't a style. It's whether an agent reading the file gets the same answer a senior designer would. Five properties make that possible, and each one is checkable.

The real test of the system is what an AI agent receives when it reads a design. Same component, same tool, before and after.

I asked the Figma MCP server for the design context of the AI Message component in the original file and in the design system. This is what an agent gets to build from (trimmed; brand names removed).

With the system in place I ran two prototyping experiments. In both, the prompt was short; the fidelity came from what the agent could read.

The agent read the AI Message and Composer components, pulled their variables, and generated React. Left is the Figma render; right is the code it produced, rendered live on this page from the component library.

The agent asked two questions (format and subject), read the relevant patterns (AI Summary Card, Metric Card, Build Row, Filter Bar, Workspace Action Bar), exported the real icons, and produced the page below. An automated check confirmed it uses no colour that isn't a design-system variable and no undefined token.

Generated code that matches the design is good. Generated code that uses our components is better. So we started the codebase from the system itself.

The library is React and TypeScript with CSS Modules. Tokens are generated from the Figma variables with one command, so a colour change in Figma is one re-export away from production. Component props mirror Figma properties word for word: tone, size="extra-small", leadingIcon, selected. Hover, pressed, focused and disabled are real CSS states, just as they are variants in Figma.

To show the whole chain, I took part of the Share Feedback modal and generated it from the design system. Every element of the generated JSX is one of our components, chosen from its Figma counterpart, and rendered live below.

I ran every test on matching pairs: the same component or screen in the original AI-built file and in the design system. The counts come straight from the Figma files.

A fix is any value an agent receives that isn't a system token (a raw colour, size, radius or gap), or a token named after another screen, such as feedback/text-subtle on a workspace. Each one has to be corrected by hand before the prototype matches the product.

Before, there was no code library, so every visible layer had to be built as markup. With the library, each coded component is a single element. The 26 core components already cut the work; coding the patterns is where the big drop is.

The speed was the least interesting part. What surprised me was how quickly my job turned into the parts I value most: deciding how the system should be organised, noticing when something was subtly off, and explaining why. The agent was tireless and fast, but it was also confidently wrong at times, and the work only became good once I treated it like a talented junior designer who needs a clear brief and honest, specific feedback.

The moment that changed my mind was the dashboard. One sentence produced a page that used our colours, our spacing and our components, and that wasn't luck: it was the structure underneath. That's the case I'd make to any team: invest in making your system legible, and AI becomes a multiplier instead of a source of drift.

The system is validated and implementation-ready. The next phase turns readiness into production use, and the measured gains into delivery numbers.