Making Your Design System Readable by AI Coding Tools

Why the output drifts

AI coding tools like Claude Code and Cursor will build a screen in seconds. Left to themselves, they build it from their training data: generic spacing, a default blue, a card that looks like every other card. The tool isn't ignoring your design system. It can't see it, because the system lives in a Figma library and in a few people's heads.

What I put in front of the model

The fix is to write the system down in plain text that the tool reads before it touches anything. On this site that's a single context file. It holds the colour tokens and what each one is for, the 40px module every width and gap has to land on, the type scale, the components and when to use each one, and a checklist to run before anything is published.

Two things make it work. The rules are written as constraints rather than preferences, so "every offset is a multiple of 40" instead of "try to keep things consistent". And there's a drift log, a running list of where the live site has got ahead of its own rules, so the model can tell a deliberate exception from debt.

What the engagement covers

For a team with an existing design system, I compare what's documented with what's actually in the code, turn the tokens and component rules into machine-readable context, and put it where your tools will pick it up: a rules file in the repo, an llms.txt, or both. Then we test it. We generate a few real screens, see where the output drifts, and tighten the rules until it stops. It usually takes two to four weeks if the system already exists.

If your team is shipping faster with AI but the product is starting to look like five different people built it, let's talk.