Three Agents, One Ticket: The Drift Audit Your Design System Never Ran

Matt Rothenberg gave three isolated agents the same component library, the same design tokens, and the same app shell, then handed each one an identical settings-page ticket. Three pages came back. One agent organized the settings behind tabs. One built long-form sections. One stacked cards. Rothenberg’s assessment of the output: “a token linter would likely pass all three.”

Sit with that result for a moment, because it will sound familiar to anyone who runs a production design system. The colors were right on every page. The spacing was right. The components were the sanctioned components. And the three pages still looked like three different products, because the system encoded components and tokens but never encoded the decisions about how to assemble them.

Then Rothenberg ran the experiment again. Same agents, same library, same tickets, plus one addition: written rules. A shared vocabulary of named patterns (SettingRow, SettingsGroup, ConfirmableSwitch) and explicit conventions, including a template that puts destructive actions last. The pages converged.

Two runs, one variable changed. The delta between run 1 and run 2 is a measurement of everything your design system left undocumented.

What the linter certifies, and what it cannot

A token linter certifies material compliance. It confirms that the button is the sanctioned button, the blue is the sanctioned blue, the spacing sits on the grid. It says nothing about whether settings live in tabs or sections, whether a dangerous action sits at the top of a group or the bottom, whether related controls cluster or scatter.

Those are decisions. Teams make them constantly, and too often they live in the heads of senior designers, in Slack threads that scrolled away, in the implicit precedent of whichever page shipped first. Rothenberg’s framing is precise: “Agents expose the gap quickly: they build from what you encoded and make reasonable but different inferences everywhere else.”

Every inference an agent makes is a decision your system failed to make for it. Human developers make the same inferences. They just make them slowly, one PR at a time, with enough taste and hallway context that the drift stays plausible. The agent compresses that drift into a single run and puts three variants side by side where nobody can pretend the system covered it.

Josh Puckett, quoted in Rothenberg’s post, described what the slow human version of this looks like at scale: “six main features in X built on four different view architectures.” No linter flagged that either. The architecture decisions were never encoded anywhere a linter could see.

Divergence is the readout

The instinct when agent outputs diverge is to file it under agent unreliability. Same prompt, different answers, the model is stochastic, tighten the temperature. That reading discards the most useful signal in the whole exercise.

The three settings pages did not diverge randomly. They diverged exactly along the axes the system never specified. Where the system had an answer (which button component, which token), all three pages complied. Where the system was silent (page architecture, grouping, ordering of destructive actions), each agent filled the silence with a reasonable guess. The divergence map and the undocumented-decision map are the same map.

Rothenberg embedded the live artifact in his post so readers can flip between runs and watch it directly. His instruction for reading it doubles as the method: whatever moves between runs is the drift.

This reframes what an agent is in a design organization. Deployed against a shared ticket in isolation, an agent is a repeatable probe. It has no memory of your hallway conversations, no loyalty to the page that shipped first, no embarrassment about picking tabs when the senior designer would have picked sections. It builds from what you wrote down, and only from what you wrote down. The output is an honest render of your documentation.

Human teams cannot give you this reading. Ask three developers to build the same settings page and they will talk to each other, look at existing pages, ask the designer. The undocumented decisions leak in through channels an audit cannot control. The agent’s isolation, usually listed as a limitation, is what makes the instrument work.

The audit any team can run this week

The experiment took Rothenberg one component library, one app shell, and three tickets. Nothing in the setup requires research infrastructure. A concrete protocol:

1. Pick a page type your product builds repeatedly. Settings is a good default. Forms, detail views, and dashboards work equally well. The requirement is that your team has built this page type more than once, so conventions should exist.
2. Write one realistic ticket. The kind a mid-level developer would receive. No extra guidance beyond what a real ticket carries.
3. Give it to three isolated agent sessions. Same model, same component library, same tokens, same app shell. No shared context, no access to each other’s output, no access to existing pages beyond what the system itself provides.
4. Diff the three pages structurally. Ignore token compliance, the linter already covers it. Compare page architecture, grouping, ordering, and interaction patterns for risky actions. Every axis of disagreement is a decision your system delegates to individual judgment.
5. Write the missing rules and rerun. Name the patterns, state the conventions, then repeat the same three tickets. Convergence tells you the rules landed. Residual divergence tells you which rules are still ambiguous as written.

The honest caveat: this is a demonstrated method, not a study. Rothenberg ran three agents and two runs on one page type. What the small demonstration establishes is the mechanism, and the mechanism is checkable in your own codebase for roughly the cost of three agent sessions.

We argued previously that the encoded rationale is the real constraint layer in a design system, and that agents already write against these systems faster than humans review the output. This experiment supplies the missing instrument for both arguments. Before you can encode the decisions, you need an inventory of which decisions are missing. The drift audit produces that inventory mechanically.

Run it before the fleet does

The uncomfortable version of this argument: if you are adopting agents for UI work, this experiment is going to run whether you schedule it or not. Every agent-built page in your product is one trial of run 1. Without written rules, each page samples a different reasonable inference, and the drift compounds in production instead of in a sandbox.

So run it deliberately. This week, one engineer, one afternoon. Three isolated sessions, one ticket, one structural diff. Take the divergence axes to your next design-system meeting as the agenda: each axis is one rule to write. Then rerun and confirm convergence.

The teams that treat agent divergence as noise will keep tuning prompts. The teams that treat it as a governance readout will finish the audit their design system never ran, and their run 2 will converge.

---

This analysis synthesizes You Don’t Have a Design System (Matt Rothenberg, August 2026).

Victorino Group helps engineering and design organizations turn agent divergence into governance audits and encoded decision systems. Let’s talk.