The model was never the bottleneck

Every week someone announces that AI can now generate your entire design system, and every week the comments argue about which model does it best. I spent three months doing this on a real production system. I can save everyone some time: it is not the model.

Between May and July I built an AI-interpretable layer on top of a production Material UI design system at a global managed IT partner, so the team could generate prototypes straight from design briefs without losing consistency with their brand and component standards. The tool was Claude Design, freshly launched. There was no playbook, no best practice, nobody to copy. Most of the work was finding out, one failure at a time, where the idea breaks.

Attempt one: just give it the file

The first attempt was the one everyone tries. Hand the full Figma design system to the model and ask for screens.

The output was confidently wrong. Design tokens dropped silently. Components appeared that did not exist in the library at all. Existing components were recreated with the wrong anatomy. And the screens looked fine, which is exactly what made them dangerous. A broken screen that looks broken gets caught. A broken screen that looks finished gets shipped.

Fixing the output by hand was slow and inconsistent, and it fixed nothing upstream, so the same errors came back on the next generation.

The fix was upstream of the prompt

Better prompting was not the answer. The problem was that a design system built for human designers is full of things humans infer and a model cannot: hidden layers, variants tucked away, token values that exist in one place and are overridden in another, intent that lives in someone's head.

So the work moved upstream. Fix the design tokens and export them as JSON. Keep every component variant visible, with no hidden layers. Put component context directly in Figma. Write markdown documentation per component covering anatomy, composition, usage and the dos and don'ts. Keep all of it in one versioned repository connected to GitHub, instead of handing over the Figma file fresh every session.

An audit before anything else

The single most useful decision was building an audit tool before doing any other implementation work.

Without a readiness check, iteration was blind. Something went wrong, I tweaked something, and I had no idea whether the tweak was the reason things improved. So I built a small skill that answers one question: if I gave the model this Figma file right now, would it generate the design system correctly?

It reads the file through the Figma MCP and runs a structured check across foundations, components, documentation, naming and overall readiness, against three guarantees. The model can find everything. The model can correctly interpret everything it finds. The model can understand the intent and the rules behind everything. It outputs a pass or fail checklist, a fix guide, and scripts that apply the fixes. I ran it across every component in the system.

That turned failures from observable into diagnosable, which is the difference between a pipeline you can improve and one you can only complain about.

Documenting what the library does not

The standard Material UI components came with their own React documentation, which went into the repository alongside the design rules. The organisation's own custom components had nothing. So a second small skill turned any Figma URL, a component, a section, a screen or a whole page, into documentation files covering design intent, anatomy, props, token references, layer structure and usage.

Then complete screens were documented as templates, covering icon behaviour, filter states and transitions, and page-level content patterns such as tables, accordions and listings were catalogued as reusable modules. Each layer went back to the model with explicit instructions: follow the tokens strictly, do not invent components or styles, flag uncertainty, and ask when context is missing. The model started asking clarifying questions before it built anything. Quality jumped once those questions were answered.

Then the briefs broke it

With the system in good shape, I took a real module brief from the team and generated a prototype from it. It was poor. Missing components, inconsistent adherence to the system, broken layouts.

The root cause had nothing to do with the design system itself. Briefs from other teams were written without any awareness of the system's rules, and when a brief contradicted the documentation, the brief won. The model did exactly what it was told, and what it was told was wrong.

This was the harder call. I made the design system win every conflict.

The brief keeps ownership of business intent, content and microcopy. The system governs component selection and layout structure, because it encodes architectural constraints the brief author usually cannot see. A single component glossary became the reference for interpreting any brief, and a brief-rewriting skill now checks feasibility first, flags unsupported layouts and conflicts, and rewrites the brief in the system's own language before any prototype is generated.

The alternative, letting briefs override the system when they disagreed, is what everyone does by default. It is also precisely what kept producing broken prototypes.

What it cost

This is the part the "AI built my design system" posts leave out.

Brief regeneration became a mandatory step in a workflow that was supposed to be saving people time. There is no shortcut on Figma hygiene: token correctness, naming conventions and documentation have to be right, every time, or quality falls off. The README turned out to be the backbone of the whole system, because the model weights it heavily, so keeping it accurate and rule-rich became the single most critical maintenance job. I built a skill to update it whenever a component is added, because it was too important to leave to memory.

The pipeline got longer before it got faster.

The skills were not the point

I automated the repeating steps, the audit, the component documentation, the glossary, the brief rewrite, each with its own small skill. It would be easy to present those as the deliverable. They were not. The design system was the deliverable, and the skills existed to keep its inputs consistent every time, which freed my time for the method decisions that actually decided output quality.

Where it landed

The end state is design-system-compliant HTML prototypes generated directly from structured briefs, a reproducible repository architecture covering Figma structure, tokens and layered documentation, and proof that AI-assisted rapid prototyping works at that scale, provided the system is structured and the brief pipeline is aligned.

That proviso is the whole story.

The pattern

The tool itself matured while I was working with it, and that helped. None of it fixed a missing token, an undocumented component, or a brief that contradicted the rules.

AI tooling never rescues a design system you have not already made rigorous. It only pays back one that is.