Writing · 5 min read
What does a design system need once AI is in the product?
AI changes a design system from both sides. Coding agents build from it, so it has to say what each part means, not only what it’s made of. And AI inside the product hands its components claims instead of facts, which they were never built to show.
An agent can build from the parts and still miss the meaning
Before I designed anything for review, I gave Claude Code the same request twice: add bulk actions to a customer data table built from a React component system.
One run read twelve written design rules first. The other had only the components, the tokens, and the stories. Both stayed inside the system, and the checks found no defect in either.
The parts carry a lot. Agent Review’s simulated run shows where they stop. In it I hand Claude Code a job: bring Relay’s billing screens onto the design system, and change nothing anyone can see.
Every action on Billing settings is the system’s Button except “Cancel subscription,” small gray text built by hand. The rule says actions are Buttons, so following it makes cancel easier to find, in a job meant to change nothing.
A passing check establishes what that check measures, and nothing beyond it.
The designer decides what each thing is for
The checks established
- Every value is exactly a token’s
- The gray clears its contrast floor
- Neither direction moves a pixel
No check could establish
- Whether cancel is quiet on purpose
- Who decides how easy it is to find
- What a quiet variant would let the next agent do
So the real question isn’t which component to use. It’s how easy it should be to cancel.
The agent doesn’t guess. It stops on that one change and recommends a quiet variant, so nothing visible moves. That variant would let any later agent make any action this quiet.
I leave cancel as built, to be changed on purpose in its own change. My reason: “The gray link is from a retention test last year that ended without a decision, and nobody turned it off.”
None of that was in the code, and all of it decided the answer.
Then I keep the answer where the next agent will find it: on the billing screens, a hand-built action that ends or reduces a subscription never gets a quiet variant.
A rule is only one place to keep an answer, though. Reviewing the experiment changed the system in four places, and its twelve rules stayed twelve:
- A better test. The layout check had passed a toolbar 58 pixels too wide. Now it measures each toolbar.
- A clearer rule. It says what a reason for changing a shared component looks like.
- A condition written down. When a confirmation fits a destructive action, and when an undo does.
- A pointer to what exists. The bar of actions a selection needs, named, so an agent finds it before building another.
Every new rule is one more thing an agent reads before every run. Most of what a review teaches belongs in something the system already has.
AI inside the product hands the components claims, not facts
The other side is what the product shows. A design system like the one that held forty-plus SAP apps together is a system for facts. Every component assumes the number in the cell is true.
An AI feature hands the same components a claim: a recommended truck, a suspected cause, a drafted correction. The value looks the same in the cell.
A fact
- The value
- Its label and its unit
- Its state: editable, locked, invalid
- Where it goes when you press it
A claim adds
- Where the value came from
- How old it is, and when it goes stale
- Where it stands against its peers
- What to check before acting on it
The first thing AI asks of a design system is a way to say what kind of thing a value is.
In Dispatch Cockpit, my prototype on synthetic data, where a value came from is a slot in the component, with how old it is beside it: the GPS position four minutes ago, the driver’s hours forty-five minutes ago.
A confidence percentage is a claim about the system. A source and an age are claims about the world, and a person knows what to do with those.
Waiting, refusing, and undoing are states the system has to name
A spinner says busy. A pending state says what’s coming, what it will replace, and what the person can do meanwhile. Without one in the system, every feature improvises its own way to say wait.
In Dispatch Cockpit, the one truck a rule removes gets the only caution background on the screen, and no suggestion ever does. The day a rule and a suggestion share a style, people press through the caution color, and the rule is gone.
Once an interface can refuse, refusal is a state, and a state is a token before it is a screen.
Text the system wrote needs its own ink too, labeled as what it is, so a drafted sentence never passes for a written one.
Pressing Assign puts Undo in its place. But undo, cancel, revert, and stop are four words and four promises:
- The thing never happened
- The thing will not happen
- The thing happened and has been put back
- The thing is in progress and will go no further
The pattern’s job is to make the promise clear before the press, not after it.
The checks have to reach every state
The checks that hold this site once passed Dispatch Cockpit after measuring a sixth of it, because twelve of its states take a press to exist.
- 12
- states in Dispatch Cockpit that no check had ever seen, because each one takes a press to exist
- 1.29:1
- the live hover the checks found on their first pass through them, against a 4.5 floor
- 7
- reachable states the page registers now, each measured on its own fresh load
Pending, stale, refused, drafted, undone: none of them is on screen when the page loads. A state the checks can’t reach is a state the system doesn’t have, whatever the documentation says.
Agent Review has its own limit: I haven’t tested it with anyone. A design system can carry what a team has decided. Noticing what it hasn’t decided is still the job.