2026-09 · 4 min read
Writing rules for a game nobody knows they're playing
AI agents can read components and rules. The harder part is making the judgment behind those rules available when they generate.
Most designers interact with a design system the way most people interact with grammar.
Not by studying every rule. They absorb enough of it that the rules recede and attention can move elsewhere. The designer thinks about the problem, not the token. They know what usually belongs together, what feels wrong, and when breaking the pattern is justified.
That intuition is part of the system too.
It just rarely lives in the documentation.
AI agents are changing that arrangement.
Design systems are increasingly becoming inputs to machines that generate interfaces and code. Components, tokens, examples, repository instructions, and structured metadata can all be supplied as context.
So the problem is no longer that an agent has no context.
The problem is that it has no shared history unless we deliberately make that history available.
A human designer acquires context through critique, corrections, failed explorations, exceptions, and the memory of why a team made one decision instead of another. An agent does not undergo that socialization. It sees the context made available at the moment of the task.
The challenge is not giving AI more rules. It is giving it access to the judgment that made those rules meaningful.
Most design systems are already good at encoding decisions.
This is the button. This is the spacing scale. These are the interaction states. These components can be combined in these ways.
For human designers, that was often enough because the missing layer lived in the people using the system. They knew when the approved component was still wrong for the situation. They knew which rule represented a principle and which represented a historical compromise.
An agent cannot reliably infer that from the component itself.
The next generation of design systems therefore has to hold more than reusable UI. It has to hold intent.
Why does this pattern exist? When should it not be used? Which constraint is load-bearing? Which exception is legitimate?
The design system starts to become something closer to machine-readable organizational memory.
Design systems used to encode decisions. Increasingly, they must encode the judgment required to make new ones.
There is a danger in that idea.
Making judgment explicit can easily become an attempt to turn judgment into rules. Those are not the same thing.
Good designers do not become good by memorizing increasingly detailed instructions. They learn which principles matter under which conditions. A machine-readable design system therefore also needs to represent uncertainty, exceptions, and boundaries.
Sometimes the right instruction is not "always use this pattern."
It is: "Use this pattern unless these conditions are present. If they are, stop and reconsider the underlying problem."
That points toward a different role for DesignOps: not merely maintaining consistency, but designing the context through which humans and machines understand what consistency is for.
For years, a large part of design quality lived between the lines.
In critique. In taste. In institutional memory. In the sentence that never made it into the documentation because everyone in the room already understood what it meant.
That was manageable while the next user of the system was another human who could acquire the missing context over time.
It becomes a structural problem when the next user is a machine that generates immediately.
The design system is becoming more than a shared vocabulary. It is becoming an interface to the organization's accumulated design judgment.
The next generation of design systems may be judged less by how consistently they reproduce the past, and more by how well they preserve the reasoning needed to design what comes next.
The tooling is new. The underlying problem — making tacit organizational knowledge transferable — is not.