AI + design systems: keeping components consistent at speed
Prompts, checks, and conventions that stop 'almost-right' UI drift when generation gets fast enough to outrun review.





Design systems exist to make the right thing the easy thing. AI generation makes any thing easy, which quietly inverts the whole premise.
The result is a specific failure you'll recognise: a button that's 2px off, a grey that isn't in the palette, a card with its own shadow. Individually invisible. Collectively, the reason a product stops feeling designed.
Here's how to keep the system winning.
Make the system machine-readable first
An AI can only follow a system it can read. If your source of truth is a Figma file plus tribal knowledge, generation will drift, because there's nothing to drift from.
Get your primitives into a format a model can consume:
- Design tokens in a real format. Tokens Studio for the Figma side, Style Dictionary for transforming them into every platform's flavour.
- Component documentation that states the rules, not just the anatomy. "Use secondary for any action that isn't the primary path on the screen" is enforceable. A screenshot isn't.
- A live component library such as Storybook, so both humans and tools have somewhere to look up how a thing actually behaves.
Supernova and zeroheight are the two mature options for keeping documentation and tokens in sync without a full-time maintainer.
Give the model your primitives, every time
The single highest-leverage habit: never prompt for UI without pasting your token names and component inventory first.
A prompt that begins with your actual spacing scale, colour names, radius values, and the list of components that already exist will produce output that uses them. A prompt that doesn't will invent a parallel system that looks fine in isolation and wrong next to everything else.
If you're generating code, paste the Tailwind config. If you're generating in Figma, start from an existing frame that uses the library rather than a blank canvas. v0 in particular gets dramatically better results when it's given the config up front, because it stops guessing at your conventions.
Ask for reuse before creation
Add one sentence to every generation prompt:
Before creating any new component, list which existing components in the inventory could be composed to achieve this. Only create something new if composition genuinely can't work, and say why.
This turns the model from a component factory into something closer to a systems thinker. It's a small change that prevents the most common form of bloat: six subtly different card components, each generated in isolation to solve the same problem.
Automate the checks that catch drift
Review doesn't scale to the speed of generation. Automation does.
Visual regression. Chromatic catches the 2px shift and the unexpected colour change on every pull request. This is the highest-value check on the list because it catches drift mechanically, without anyone needing to notice.
Token linting. Fail the build on hardcoded hex values, magic numbers in spacing, and font sizes outside the scale. A simple ESLint rule or a Stylelint config does most of this and takes an afternoon to set up.
Accessibility. axe DevTools in CI and Stark in Figma. Generated UI is routinely fine structurally and wrong on contrast, because models don't check contrast unless asked.
Component usage tracking. Most design system tools can now report which components are used where. The report you want is the one showing un-systematised UI: the divs with bespoke styling that should have been a component.
Use AI on the maintenance work nobody wants
This is where it genuinely shines and where almost nobody points it:
- Writing the documentation for components that have shipped undocumented for two years. Feed it the code, get a first draft of usage guidance, edit for accuracy.
- Generating the missing states. Take a component and ask for every variant the system says should exist. It'll find the disabled-and-loading combination you never built.
- Migration codemods. "Rewrite every usage of
<OldButton>to<Button variant='primary'>, flagging the ones where the mapping is ambiguous." This is exactly the broad-and-shallow work models are reliable at. - Auditing for drift. Point it at a directory and ask for every colour value that isn't a token. It's tedious, mechanical, and complete, which is three things humans are bad at.
What to keep human
The rules themselves. What a component is for, when to use which variant, what the system deliberately doesn't support. These are product decisions encoded as constraints, and a model will happily generate a plausible-sounding rule that contradicts one you made for a good reason two years ago.
Deprecation. Deciding a component should die is a political and technical judgement about who depends on it. Not a generation task.
The bar. Someone has to look at the whole thing and say "this doesn't feel right yet." No amount of passing checks substitutes for that.
The summary
Machine-readable primitives, primitives in every prompt, reuse-before-creation as a standing instruction, and automated visual regression. That combination lets you generate fast without the system quietly dissolving.
Without it, AI doesn't break your design system in one dramatic moment. It erodes it, one reasonable-looking component at a time.
More in the design systems list.

