A Design System For Machines

How a human team of three kept agents aligned on one design system across three vast applications.

Context: Prototyping against production components
Role: Fractional CPO. Led product and engineering
Type: Design systems, agent tooling, governance
Impact: Three applications. One component source

A convolutional neural network drawn as a diagram. Eight handwritten digits enter at the left, each fanning into hundreds of fine lines that pass through successive layers, narrowing at every stage until they converge on a single point at the right.

How do you keep a design system coherent when a small team is building three applications at once and an agent is composing most of the screens?

We believed that a workbench rendering the true production components, rather than copies, would constrain an agent to buildable interfaces. And that review could happen on a working surface instead of through descriptive prose.

The Opportunity

Agents are probabilistic. Without constraints an agent will fill in gaps with an average of its current context. UI included. Ensuring UI consistency at speed over a vast platform build requires a bullet proof rule-set.

I led product and engineering for an insurance benefits admin platform that consisted of three separate applications functioning as one system. As things go when building complex platform software quickly, the UI packages and component libraries drifted during the initial build-out.

When I first began this work 2 years ago, I would write out the cases and business logic using the research agent. Naming the components, services, and business logic as a product requirements doc. Then I would work with the dev agent to build out the views and so on. Then on to QA. This was a linear process and very high touch. Lots of iteration and QA/QC around catching invented styles, classes, copy pasted components, invented components, etc. Slow, messy, and unpredictable with a never ending conga line of tech debt. There had to be a better way.

As the agents and the harnesses evolved, there definitely was. I know Figma allows for MCP connections and this could be solved there in a fashion but I wanted something local, open source, extensible and customizable, and that rendered only what actually existed in the codebase as the source of truth. Figma seemed like an abstraction. Storybook with Claude producing real components in the codebase itself read as the answer.

The new arrangement for the three apps became four Storybook instances. A Storybook workbench for each of the three applications. Each workbench aliases through Vite into the real component source of its sibling application. Each repo serves Storybook’s MCP add-on locally. The fourth Storybook instance running as a hub, composing all three UI packages into one sidebar.

This way the agent enumerates the components, reads their real props and variants, and composes a fully interactive prototype before any code exists. With this method the agent doesn’t design anything. It assembles what is there and hands back the result based on our conversation. If a variant, class, token, or functionality is missing it is immediately obvious and when remedied the solution is 1 step and now part of the production UI package.

The Challenges Overcome

Drift between applications

Components existed in various shapes and versions across a shared platform. The three component trees started as forks of one ancestor. Each application then moved at its own speed, under its own deadlines, and the shared components drifted. By the time we were running final end-to-end testing the debt from drift became sizable.

Prose to visuals

We deal with LLMs via prose. A written description is already an abstraction of a visual asset, and I would venture this is one reason visual designers still lean into visual tooling. Using Storybook the prose and the artifact presented are directly linked in the same step.

Design drift to tech debt

The typical Storybook setup copies components into the workbench. Figma copies them into a stage. Drift begins the moment a copy is made. The method where prototyping directly from the UI package in the codebase removes these abstraction layers entirely and therefore drift.

Velocity

Our challenge was a need for velocity and a desire to shorten the process. Prototyping with the literal UI package in the app short circuits the time to resolution and reduces design tech debt to nearly zero.

The Process Today

Today, the longest part of this task is documenting the expected outcomes and business logic. Once that’s settled, the prototypes happen in seconds. I review in Storybook by clicking through the rendering, Claude and I iterate using the actual UI package until the edge, error, and corner cases are worked out, and only then do we move inward to the data logic. I’ve always worked this way, and today it happens at the speed of AI.

Governance became three primary rules that made generating predictable UI without a designer involved with every decision possible:

01A prop or function that is not in the source component does not exist, so an agent cannot invent an affordance.
02Color and type come from tokens only.
03A color or size with no token is a design decision, and it gets surfaced in step one instead of improvised and reviewed from the codebase later.

The hub allowed us to see the three applications side by side. Three versions of the same component sitting in one list became the entire drift audit report, and repairs are edited directly in the codebase.

The Outcome

All three applications now prototype against their own production components, so the prototype that renders in conversation is the prototype built.
The hub collecting all three apps into one sidebar serves as a way to visualize component drift and offers a straight forward visual method to align to one shared library across a vast platform.
This design system is read and used by an agent far more often than a person. It is the most accurate and efficient system I’ve ever worked with.