Process · Product development
Every case study here shows an outcome. This is the machine behind them: where the work starts, what gets written down, where the agents are allowed to write code, and what has to be true before anything ships.
It is one loop in four movements. The shape has not changed much in a decade; what changed is who does the typing in the third one, and how much has to be written down before that is safe.
Selected step
What it is
One authoritative store for the knowledge a project runs on: decisions and the reasoning behind them, user stories, research, and customer facts. Elsewhere this is a knowledge base; the decision records specifically are ADRs. I call ours the vault.
How I run it
It is not documentation and it is not written for posterity. It is the context that makes everything after it work. Agents build the right thing because the context is complete, not because the prompt was clever, and the gap between those two is most of the difference between an AI workflow that holds up and one that demos well.
Read the full section ↓The loop, with the agents fenced on both sides
What it is
The phase before anything is designed, where you find out what is actually wrong for someone rather than what somebody wants built.
How I run it
Work starts from a pain point in the user's words. Everything downstream has to trace back to it; a decision that cannot is decoration, and decoration is the first thing cut when scope gets real.
Read the full section ↓What it is
Named, evidence-backed profiles of the distinct kinds of people who use a product, each with different goals and constraints.
How I run it
I hold several, always, because no product has one kind of user. What separates them is whatever changes a decision, not demographics. Holding more than one is also what makes an experiment mean something later: you are testing which person you were right about, not which button won.
Read the full section ↓What it is
The backlog: what the first version contains, and each unit of work written as a need a specific user has.
How I run it
Scope is the decision and the feature list is the easy part. Every story carries the persona it serves, which is what keeps the build honest months later when the reasoning is forgotten and only the ticket survives.
Read the full section ↓What it is
The versioned set of tokens, components, patterns and rules a product is built from, plus the governance that keeps them true.
How I run it
What is allowed and what is not. Color named by role and never by value, which is the decision that lets one system survive five themes. Versioned with migration notes, so a change arrives as a version bump rather than a surprise on somebody else's screen.
Read the full section ↓What it is
Coding agents write most of the code; a person reviews every change and owns the result. Human-in-the-loop, not hands-off.
How I run it
The user stories are the work queue, front end and back end. They already carry their persona and their reason, which is what stops a task from being executed correctly and pointlessly. An MCP server over the design and development assets lets the agents read the system instead of guessing at it.
Read the full section ↓What it is
Constraints enforced automatically rather than by review. Policy as code. For interface work, the rules of the design system expressed as something a machine can check.
How I run it
A deterministic engine checks every edit against the system, whether a person or an agent made it, and hands back the fix. The failure mode of agent-built interfaces is not broken code, it is plausible code, and plausible code passes a reviewer at three in the afternoon.
Read the full section ↓What it is
Checks a change must pass before it can merge. Standard CI/CD vocabulary; the point here is which checks and who wrote them.
How I run it
Authored by a person, and the final call is always a person's. Accessibility is a gate rather than an aspiration. Copy is reviewed, including empty states, errors and labels, because in an agent-built front end the words drift first and the words are the interface.
Read the full section ↓What it is
The automated path from a merged change to production, with versioning that tells everyone what shipped.
How I run it
Error pipelines catch what gets past the gates, and semantic versioning means every change is numbered and the whole team is moving against the same numbers.
Read the full section ↓↺ Telemetry and feedback go back to discovery. The last step rewrites the first, which is what makes it a loop.
Underneath all of it
One authoritative store for the knowledge a project runs on: decisions and the reasoning behind them, user stories, research, and customer facts. Elsewhere this is a knowledge base; the decision records specifically are ADRs. I call ours the vault.
Read the full section ↓One
Work starts from something that is actually wrong for someone. Not a feature request, not a competitor's screenshot, not a roadmap item that arrived without a reason attached.
Everything downstream should trace back to it. When a decision cannot be traced back to a pain point it is decoration, and decoration is the first thing to cut once the scope gets real.
No product has one kind of user. I have never worked on one that did.
What separates them is rarely demographic in the marketing sense. It is whatever changes a decision: where someone lives, what they believe, what they are afraid of, what they are paid to do, how much time they have when they open the thing. Two people with identical job titles can want opposite outcomes from the same screen.
Holding more than one persona is also what makes an experiment mean something later. Test with one persona in mind and you are testing a button. Hold several and you are testing which person you were right about, and that answer changes the product rather than the color of the button.
Two
Anyone can write down everything a product could do. The work is deciding what is not in the first version, and being able to say why out loud without flinching.
The story is the unit of work and it carries its persona with it. That is what keeps the build honest three months later, when the reason behind a decision has been forgotten and all that survives is the ticket.
It is a continuous document rather than a phase. As you learn more about who is actually using the thing, the stories change, and the layout and the design change with them.
A new product gets a color study, a logo, a look and feel, and the style guide that comes out of it. An existing product skips all of that: you inherit a language, and the job is to apply it coherently rather than to relitigate it.
Tokens, components, patterns, and the rules that govern them. What is allowed and what is not. How color is named, by role and never by value, which is the decision that lets one system survive five themes. How language and localization work. What a component owes the people building on it.
It is versioned, with migration notes, so a change arrives as a version bump rather than as a surprise on somebody else's screen.
A wireframe is a proxy for something I can now simply build, so exploration moves into the medium where it is cheapest, and that medium is no longer a gray box.
You give up the cheap throwaway, which is a real loss when an idea deserves to die quickly. What you get back is an artifact a real person can use the same afternoon, which settles the arguments a wireframe can only postpone.
Three
Every decision, every story, every customer fact, everything learned in a meeting, in one place. A knowledge base, with the decision records as ADRs. Internally I call it the vault, and it is the organization's brain.
It is not documentation and it is not written for posterity. It is the context that makes everything after it work. Agents build the right thing because the context is complete, not because the prompt was clever, and the gap between those two is most of the difference between an AI workflow that holds up and one that demos well.
Model Context Protocol is the open standard for exposing tools and data to a model. Putting the design system and the build assets behind one means the agents read the system rather than guessing at it.
Concretely: an agent asking for a surface color gets the three tokens that exist rather than a plausible hex value, and asking what a card looks like gets the component that is already built rather than a new one that resembles it. Context alone would let it invent both and be confident about it.
The user stories are the work queue, front end and back end. They already carry their persona and their reason, which is what stops a task from being executed correctly and pointlessly.
The failure mode of agent-built interfaces is not broken code. It is plausible code: an off-system value that looks perfectly fine in a screenshot, arriving faster than any team can review it.
So the rules become policy as code. A deterministic engine checks every edit against the design system, whether a person or an agent made it, and hands back the fix. That is a system doing the work rather than a reviewer's attention, which is the only version of this that survives contact with a real release cadence.
Concretely, from Zengin's own fixtures: an agent writes px-[13px] on a Button. That single class trips two separate rules at the same position. It is an arbitrary literal where a spacing token belongs, and it is a policy violation on a component that does not take arbitrary padding, so the engine reports two violations rather than merging them into one vague complaint. The hook running after the write exits non-zero with those violations on stderr, which is what the agent is shown as the reason its edit was refused. It fixes it and moves on. Nobody was asked to notice a thirteen-pixel value in review.
The vault is full of these and they are mostly dull, which is the point. Here is one from Zengin, in the shape they all take: context, the decision, and what it cost.
Context. The hook checks a file after it is written. A file in a codebase that predates the design system carries dozens of pre-existing violations, so a single changed line would block on all of them.
Decision. On an edit, report only violations on the lines the edit touched, and say how many pre-existing ones were left out. A whole-file write still reports the whole file.
Consequence. The engine stops being a complete picture of the file, and that is a real loss, because drift nobody edits stays invisible until CI runs. It buys the only thing that matters more: without it, one line changed in a drift-heavy file blocks on forty unrelated violations, and the team turns the hook off within a week. A guardrail nobody keeps enabled has a conformance rate of zero.
That last line is why the record exists. The decision is not obvious from the code, it looks like a weaker check, and in eighteen months somebody reasonable will want to make it stricter. The record is what tells them what happens when they do.
The pipeline and its checkpoints are written by a person, and the final call is always a person's. Accessibility is a gate rather than an aspiration. Copy gets reviewed, including empty states, errors and labels, because in an agent-built front end the words drift first and the words are the interface.
Error pipelines catch what still gets through, and semantic release means every change is versioned and the whole team is moving against the same numbers.
Four
Telemetry, session review, and experiments run across the personas rather than across the whole population.
The readout does not just produce a backlog. It rewrites the personas, which is the only part of this loop that can tell you whether the pain point you started from was real. A process that never returns to the person it started with is a production line, not a design practice.
Where this breaks
The case studies are this loop with the names filled in. Zengin is the guardrail stage built as its own product. Spellbook is a design system and its governance, running across ten application teams. MixShift is the whole loop inside a company, source of truth included.
The other engine is content and distribution, the same shape pointed at finding the people this was built for.
Half an hour, no deck. Where your current loop leaks, which stage would pay back first, where automation would actually help, and what still needs a person to look at it before it ships.