Your design system checks spelling, not judgment

The design system is now the thing the model reads. In a July survey of 21 open-source design systems, Kaelig Deloumeau-Prigent found that 18 ship an official MCP server so coding agents can query them directly. Figma describes its new agent as having “deep context on your components, tokens, standards, and best practices”.

The position behind all of this is reasonable. Give the agent your system and it builds on your system. The components and tokens become the guardrail, and on-brand output follows.

I think that gets the guardrail half right and drops the half that matters.

What the machine-readable half enforces

The same survey catalogs 165 techniques teams use to keep models on their real components and tokens. The biggest groups are validation loops (31), prohibitions like “never invent components” (28), tool-gating that makes a fake component impossible to produce (22) and token enforcement that fails the build on a raw hex value (15).

That’s serious engineering, and it works. It also has a clear shape. Most of them answer one question: is this a real part of the system, used the way its API allows?

That’s spelling. An agent can pass all of it and still put a primary button in every row of a table, because every one of those buttons is a real button with a real token.

The part that got cut first

Atlassian tested Google’s DESIGN.md format against its own MCP server and skills and wrote up what happened. To fit the design system into one portable file, the team says it “had to remove much of the usage guidance from our 50+ components”. Agents given the file then went digging through component code to find the guidance that was missing.

Usage guidance is where the judgment lives. It’s the paragraph that says when not to use the thing. Nord, one of the systems in the survey, ships it to agents in exactly that form: “Don’t use a primary button in every row of a table.” No linter catches that sentence being ignored. It’s also what went first when Atlassian needed the file smaller.

Tokens are cheap to write down. They’re values with names. The reasons behind the choices are expensive, and the reasons are the part a designer was actually hired to supply.

Frequency is not a standard

When an agent has no reason to go on, it falls back on what’s common. Figma says its agent “uses your most frequently and recently used components as a starting point”. That’s a sensible default for a tool and a poor definition of good.

I have seen why. When I ran an agent audit across a whole design library, I wrote the crawler’s rules, and it counted every value we had. It couldn’t tell me which of two established values was right. Somebody had to decide, and the decision was nowhere in the data.

Nurkhon Akhmedov puts the failure mode well in a July post on this: five screens in a hundred ship off-system, and “the next agent reads those five as if they were the library.” A system that learns from its own output drifts toward whatever it did most, right or wrong.

Gated on spelling, trusted on judgment

The survey also looked for whether teams measure any of this. Eight of the 21 records mention evaluation work at all. The report calls its validation loops the closest thing the field has, and describes them as “checks that fail a build, rather than evals that score a model.”

So the mechanical half is gated and the judgment half is trusted. Akhmedov’s version is blunter: whether the agent picked the right component for what the user is trying to do is a question “you can’t grep for.”

Where the missing half comes from

Akhmedov argues the rubric is now the deliverable. I agree, and I’d go one step further on where it comes from.

Nobody writes good usage guidance in the abstract. Try to list every wrong way to use a button in advance and you get a style guide nobody reads. The useful rules show up one at a time, when someone looks at a screen an agent built and says no.

That moment is the raw material, and it’s easy to lose. The rejection happens in a review, the agent gets a new prompt, the screen gets fixed and the reason lives in one person’s head until they leave.

A rejection without a written reason is wasted. The reason goes into the system the agent reads, in the form Nord already uses: the choice that was wrong, the one that was right and why. Written that way, the next agent can be held to it and so can the next designer.

What the design system team is for now

For years the visible output of a design system team was the library. This year the industry made that library readable and enforceable for agents. That work was worth doing.

It was also the easy half. A system that only knows its own vocabulary will produce fluent, valid, wrong screens at whatever speed you let it. The half that decides whether a screen is right is still mostly sitting in people’s heads, and in at least one case it was trimmed out on purpose to make a file fit.