Your design system is no longer written for people

A design system was always two things: a set of components, and a story about when to use them. The story lived in Storybook pages, in Notion, in Figma descriptions, and it was addressed to a person. A model reads the system now, and the two halves have come apart. The machine takes the components. It never sees the story.

What does a model actually see?

Be concrete about it. Figma's Dev Mode MCP server exposes twenty-four tools to an agent. Two of them are this post:

get_variable_defs returns, in Figma's own words, "the variables and styles used in your Figma selection (such as colors, spacing, typography)".
get_code_connect_map returns Figma node ids mapped to components in your codebase — the component name, the source file, the snippet.

Sketch's server has the same shape: get_design_assets, get_libraries, get_symbol_overrides.

Read that list carefully. What the agent sees is names, values and mappings. Your usage guidance is not in it. The note you wrote — use this one only when there are fewer than three items — is not reachable from there. The readable surface of a design system has narrowed, and what survives in the narrowed surface is naming.

A long list of what a person reads from a design system beside the three tool calls a model reads — The left column is everything you wrote down. The right column is everything the server returns. The gap between them is where invention happens.

Why did a token name suddenly matter?

color-brand-500 used to be a matter of taste. If a name was uninformative a person asked the colleague next to them, posted in Slack, or opened an example. A model has nobody to ask. For it the name is the instruction.

color-brand-500 does not tell a model when to reach for that colour; it names a step on a ramp. color-action-primary-bg tells it exactly. Semantic naming has been the recommended practice for years and most teams treated it as a style argument. It is not a style argument any more: whatever the name fails to carry becomes a guess in the output.

Be fair about this. AI did not invent the rule. It made the cost of breaking it visible.

A coverage gap used to produce inconsistency. Now it produces invention.

No empty-state component in your system — what used to happen? A designer built something close by hand, review caught it, the next release absorbed it. The defect was visible.

A model behaves differently in the same gap. It produces something that resembles your system, uses your colours and your spacing, and has no counterpart in the library. The result is not obviously broken. It is plausible. And plausible is the hardest thing to catch in review.

An undocumented component does not exist

A component that lives in the codebase but never made it into the library, and never got a Code Connect mapping, is invisible to the agent. The agent does not skip it. It rebuilds it. You end up with a second component doing the first one's job.

Two years ago that came from carelessness. Now it comes from the system not showing itself. Coverage stopped being a pleasant metric and became a question of visibility: anything the system does not expose gets reinvented.

So is the design system a prompt?

Not literally, and the distinction is worth keeping. A prompt is what you write. A design system is what the model retrieves. One is instruction, the other is source.

But functionally it now occupies the position a prompt occupies: it is the context that bounds the output. Which makes design system work partly context engineering — deciding what the model can see, and in which words.

A token name is no longer a preference. It is an instruction.

What should a designer do?

Semantic naming is functional now, not stylistic. brand-500 names a step on a ramp; action-primary-bg names a decision. Write the second and you are the one making the decision. Write the first and the model makes it for you.
Coverage means visibility. Every component missing from the library, unmapped, or left with an empty description will be produced again from scratch. Measure coverage by what the agent can see, not by what percentage is "done".
Put the reasoning where the machine can reach it. Component and variable descriptions are fields the MCP server returns; your documentation site is a place the agent never opens. Write the rule in both.

The system is part of the build now

A design system has stopped being a document about the product and become part of how the product gets made. That is not an argument for writing less for people. It is an argument that people are no longer the only reader.

You learn what a system actually says by watching someone read it for the first time. A model is exactly that reader: no context, no questions, and it knows only as much as you wrote down.