What your design system can't teach AI agents

For months, colleagues kept asking me a version of the same question. Could I write down how I approach design, so they could draw on it without waiting on my calendar?

The question kept coming back because of how we now build. Tessl runs a software factory, Kikimora: agents do the making, people set direction and decide what ships. As its use spread, more of what we shipped was arriving without a designer having touched it.

What people ask for is almost always help with the pixels, but you cannot start there because a brand comprises three pillars:

• Values are what an organization believes.
• Voice is how it articulates those beliefs.
• Visuals are how it presents them.

Codify the visuals alone and an agent gets a list of preferences with none of the reasoning underneath. The order is forced, even though the pressure comes entirely from the visual end. It also reinforces that design only equates to pixels.

Visuals are also the hardest to write down, and the reason took me a while to name. Composition, the judgment of what goes on a screen, where it sits, and what gets left out, lives in a designer's head. It is applied by hand and passed on through proximity, not documentation, because a person was always there to supply it. Nobody writes down what nobody has ever had to hand over.

Codifying values and voice for agents

Voice was the most tractable. Every piece of copy the organization has ever shipped is a data point, so the rules are recoverable: 'American English throughout', 'name the thing before explaining it', 'no exclamation marks', 'no em dashes'. The first pass at the rules came straight from that shipped copy, then each one was refined with our Head of Marketing through worked examples until it met our standards. A person can check these. So can a machine.

Values look easier but are not. Most organizations have written theirs down already, but the words are open to many interpretations. The real work is spelling out the decisions each value implies, which is where everyone discovers they were not agreeing after all.

Values started from our operating principles, and I worked through each one with our operations and leadership teams, pushing until it produced a decision without losing the spirit of the principle it came from. The output of both is deliberately plain: a document of checkable rules, which is exactly the form an agent can act on.

Why a design system can't teach composition

Which is usually where someone asks: but what about the design system?

We have one. It is good. But it was never going to teach composition. A component library tells you what the parts are. It says nothing about which parts to reach for, how many, or when the right answer is none of them. Composition is its own discipline, and no designer expects the library to carry it.

Agents make that gap expensive. They inherit the library in full and the judgment not at all, and they will not absorb it by sitting near me for six months.

This was exemplified by the screens our software factory was producing. Every component came from our design system, every color was a token, every spacing value was legal. Nothing would have failed a linter. Yet panels sat on panels with four levels of elevation, each drop shadow implying a surface floating above the last, and no hierarchy telling the eye where to start. Borders wherever two things met, as though adjacency needed explaining. Modals interrupting people for no good reason.

On the surface, none of these are component bugs. Each is a composition decision, a call I make in seconds without conscious effort. Judgment that fast never produces an artifact, so there was nothing for an agent to read.

Zoom

Zoom

Extracting design rules from a Figma diff

Having failed at introspection, I went the other way round. I took three agent-built screens, deliberately different in purpose and layout, and redesigned each properly in Figma. Then I put each pair in front of another agent and asked it to describe the difference: not to judge which was better, but to enumerate what had changed.

Low expectations. Mostly I wanted to see what it would come up with.

Zoom

Each pair came back as a list of specific, checkable deltas. Nested surfaces, cards sitting inside cards, cut from three levels to one. Fourteen borders removed, separation carried by spacing. A modal replaced by an inline expansion. Section spacing doubled. Most were decisions I had made in one fell swoop, and seeing them itemized was the first time my own reasoning had been visible to me.

The process works best across several designs, because that is how you tell a rule from a one-off. A change recurring across all three was an emerging rule.

Diffs suit how agents work. Introspection asks you to retrieve something that was never stored as language. A diff turns it into an observable difference between two artifacts, which is exactly what a model is good at describing.

None of this makes design a checklist. Good design is contextual, and part of the craft is knowing when to break your own rule. When these rules later become checks, they should start at 'warn' rather than 'block': in a discipline where the exceptions carry information, blocking the exception throws away your most interesting signal.

What automated design and brand checks actually catch

Guidance sitting in a document is not guidance that acts. Ours ships as two skills in a plugin: one loads at the point of creation, before the agent makes anything, and the other reviews output against the same rules at the pull request and again before release.

The trigger is nothing cleverer than the skill's own description: when a task involves making something user-facing, a screen, a doc, a piece of copy, the agent matches on that and loads the skill before it writes a line. Each skill pulls in the pillar docs the task touches, resolving conflicts in a fixed order: values decide ambiguous calls, voice governs the copy, visuals govern layout and hierarchy. Both end with a checklist, and an instruction to surface any call that needs human judgment rather than guess at it.

What I did not anticipate was pointing the same guidance at work that already existed. We built automations to sweep whole surfaces rather than check new changes, and the first run raised thirteen pull requests against accumulated drift. All thirteen merged.

Zoom

Some were mundane. Our external copy standard is American English, but the team is mostly London-based and writes British by reflex, so 'colour' and 'organisation' keep turning up in the product. A reviewer who spells it 'colour' will not flag it; the agent has no such blind spot. Other catches were harder, where the copy was grammatically fine but did not sound like us.

None of the thirteen would have been caught by a reviewer reading a diff, because none arrived in one. They accumulated a word at a time, each change too small to object to. A sweep sees what a diff-scoped check structurally cannot. It now runs weekly across our codebases.

Is it complete? Of course not.

The rules are incomplete and some will turn out to be wrong. That is not a temporary state I am working through. Maintaining the guidance, and the agents that enforce it, is now part of the discipline: the rules change as the product changes, the sweeps surface things that need new rules, and none of it arrives at done.

It would be easy to read all this as a designer writing themselves out of the work. It is closer to the opposite. An agent can apply a rule to every screen the factory produces, but it cannot decide what the rule should be, or whether the exception in front of it is a mistake or the interesting kind. Deciding the guidelines and verifying what comes back is where a designer's judgment now concentrates, and it is leverage of a sort the job never had: one person's taste, reaching every screen that ships.

If you want to try this yourself, the path does not start with a manifesto. Take three screens an agent built, redesign them by hand, and ask a model to enumerate the differences; what recurs across all three is your first rule set. Ship those rules to the point of creation, set the gates to warn, and point a sweep at something that already exists.

It is better than unguided agent output, and it improves each time a correction goes into the guidance rather than a single artifact. That is the test I hold it to: not whether the line produces perfect work, but whether it produces better work this month than last.

Which is not a new job, in the end. I trained as a mechanical engineer, and factories run on one principle: quality is built into the line, not inspected at the end of it. The craft moving from the artifact to what the artifact is made from is that same idea, turning up where I did not expect it.