AI Agents Can Build Features, But They Still Need a UI Contract

September 2, 2026

I have been building more and more with AI agents in AFK workflows.

By AFK, I mean long-running feature implementation in the background. I clarify the idea, turn it into a PRD, break it into issues, then let agents work while I do something else.

That flow works surprisingly well for backend behavior, architecture, refactors, and scoped product features.

But UI exposed a gap.

I stopped prototyping

Before using agents this way, I would naturally prototype more.

Not always in a formal design tool, but I would explore the interface manually. I would try layouts, move things around, feel the flow, and slowly discover what the screen wanted to become.

With agents, my process became more text-first:

clarify the idea with AI
write a PRD
break it into small issues
let agents implement in the background

That is powerful, but it changes how UI decisions happen.

If the UI only exists as text, the agent can implement something valid without implementing something I actually want.

Text specs were not enough

At first, I tried to make the clarification phase more exhaustive.

I described the feature, the expected behavior, the edge cases, the implementation notes, and some UI guidance in the tickets.

The result was better, but still approximate.

The real workflow became:

clarify
implement
inspect the UI
pair program with AI to rework it

The agent understood the feature. It could wire the state, call the right APIs, and handle the right cases.

But it did not have a visual target.

Better models helped

As models improved, the UI output improved too.

Layouts became more coherent. Components were used more consistently. There were fewer completely wrong visual decisions.

For small apps, this was fine.

If I was building a quick internal tool or a side experiment, 80% good enough was acceptable. Speed mattered more than polish.

Then I started building Space Zero.

Space Zero raised the bar

Space Zero is a desktop workspace for builders using coding agents.

At the beginning, I did a lot of UI discovery through pair programming with AI. I would set the base of a screen manually with the agent, then let AFK agents implement follow-up features.

That worked better because the visual foundation already existed.

But after the first release, I realized the product was not just a private experiment anymore. The category was real. Other people were building in the same direction. The quality bar changed.

Suddenly, 80% good enough was not good enough.

The product needed to feel consistent. Agents could not keep inventing small local variations every time they touched a screen.

The real problem was UI drift

The problem was not that agents were bad at UI.

The problem was that my UI contract was not explicit enough.

When multiple agents implement features over time, small inconsistencies start to appear:

  • slightly different buttons
  • duplicated component styles
  • layout shortcuts
  • one-off variants
  • inconsistent spacing
  • custom UI because it was easier in the moment
  • components overridden because the ticket did not forbid it

Each decision looks small in isolation.

Together, they create product entropy.

If I do not give the agent a component contract, it will invent one locally.

My first workaround

My first workaround was to create an in-app design system screen.

It was basically a debug page where I could render components, inspect variants, and give agents something concrete to reference.

It helped.

Components became visible. I could inspect primitives. Agents had a better base to copy from.

But it was still a workaround.

It lived inside the app, so I had to hide or remove it for deploys. Internal design tooling was mixed into product UI.

It also slowed the workflow. When I asked AI to change something inside the app, it had to load the full application context, deal with routing and state, and run the normal project checks.

That is too heavy for fast UI exploration.

What I needed was not a debug screen.

I needed a UI workbench.

Storybook became the missing layer

This is where Storybook started to make sense again.

Not because Storybook is cool. Not because every frontend project needs it.

Because it solves a specific workflow problem for agentic development.

The workflow I want is:

clarify the idea with AI
write the PRD
break it into tickets
prototype the UI in Storybook
reference the stories from the tickets
let agents implement against the visual contract

The important shift is simple.

Storybook becomes the visual contract between product intent and agent implementation.

Before:

ticket says what to build
agent invents the UI while implementing
human reviews and fixes UI drift

After:

ticket says what to build
Storybook shows how it should look
agent implements behavior against that target
human reviews less UI drift

A ticket can now include references like:

UI reference:
- Storybook: Settings / General / Default
- Storybook: Components / Button
- Run locally with pnpm storybook

That gives the agent component names, layout expectations, visual states, and interaction boundaries.

It turns subjective UI taste into something closer to an implementation contract.

The pattern I use

The key is not to build prototypes that get copied later.

I want Storybook to render real app components.

The pattern is:

GeneralSettingsPage
  app container
  loads data
  talks to Electron or the client runtime
 
GeneralSettingsScreen
  pure UI
  receives props
  renders in Storybook

The app renders the screen with real data.

Storybook renders the same screen with mocked props.

No duplication. No second fake app. No throwaway prototype that has to be rewritten later.

Why this matters for AFK agents

Pair programming gives immediate feedback.

If the UI drifts, I can correct it live. I can say the spacing feels wrong, the hierarchy is off, or the button should use the existing component.

AFK implementation is different.

I give the agent a task, leave it running, and review later. That means ambiguity has more time to compound.

For backend behavior, PRDs and tests reduce that ambiguity.

For UI, Storybook fills the same role.

It gives the agent a target before it starts.

What I changed in Space Zero

For Space Zero, I started moving toward this workflow:

  • use local Storybook for UI exploration
  • add stories for shared primitives
  • create stories for real screens, not fake copies
  • keep containers in the app and pure screens in Storybook
  • reference stories from implementation tickets
  • use the design system as an agent constraint, not just human documentation

For now, local-only is enough.

I do not need hosted previews or a full design pipeline yet. I just need a reliable way to turn product intent into a visual contract before agents implement.

Agents make design systems more important

AI agents make implementation cheaper.

But when implementation becomes cheaper, consistency becomes more important.

Without a design system, every task can introduce a little more UI entropy.

Storybook is not just a frontend tool in this workflow. It becomes:

  • a design-system catalog
  • a prototyping workbench
  • a UI contract for agents
  • a way to reduce rework after AFK implementation

The better agents get at writing code, the more important it becomes to tell them exactly what kind of product they are building.