Motivation

A conversation about adopting Storybook is what got me thinking about this. Instead of answering yes or no, I wanted to split the question into two: what is specific to Storybook, and what do we want out of it? The two lists turned out to be very different, and only the second one matters to us.

What is specific to Storybook

Two things, as far as I can tell:

• An MCP server built in, for agents to tap into
• Two-way sync between Figma Dev Mode and Storybook

Both are useful, but I don't depend on either right now. We can work without Figma, and MCP tends to work poorly across worktrees, which is where a lot of my work happens these days, with several agents running in parallel branches.

What we want from it

Most of the arguments I hear for Storybook are about things any component workbench would give us:

• Seeing every state a component can be in: a chat with an error, a widget with partial or missing data, an empty list, a slow load
• Catching UI regressions: change a shared component like Modal and see the effect at every call site
• Easier approvals: if we can see a new button variant everywhere it lands, we can approve it properly instead of accepting a diff blind

I like Storybook as an idea for improving process. I'm less sure we need its implementation when we could maintain a smaller tool that fits our own workflow.

Where velocity hurts

Most design and engineering teams end up on some version of this loop:

1. Prototype directly in code
2. Open a draft PR for preview
3. Request engineer review
4. Merge

This works at low velocity. Once AI multiplies the explorations a designer can produce in an afternoon, the same four steps start working against the prototyping phase:

• The repo fills up with prototype draft PRs, which pollutes it and makes it hard to filter or choose which one to keep
• Fast iterations and quick experiments burden engineers with approval requests, which at high velocity also compromises the quality of those approvals
• CI usually requires tests and checks to pass, even on branches that were never meant to ship

Exploration should be cheap. When every experiment carries the ceremony of production code, designers explore less.

What I'd build instead

1. Generate component docs for agents

Instead of Storybook for documenting components, use a script that generates component documentation directly for agent consumption.

The main gain is token cost, for very little effort: a script generates the files from the components we already have. Instead of opening a component's source to work out what it does, an agent reads one generated file. The script derives everything from TypeScript and reruns on every change, so the docs stay current. It also works across worktrees, where a Storybook MCP would struggle.

2. Give prototypes their own lane

Create a dedicated route or folder in the front-end app for prototypes, so there are two PR lanes: one for production code and one for prototypes and explorations.

• Anything in the prototype lane gets more relaxed testing and CI
• Reviewers can afford to be lenient about what goes in there, because it can't affect production

Promoting a prototype to production is then its own PR, which needs a real review anyway. The two steps are deliberate: designers get to iterate fast, and engineers only look closely at the prototypes that earned it.

3. Make that lane double as a component showcase

On top of the prototype lane, use the same surface to showcase components:

• Standardise a preset config to toggle states like loading, error, success and empty
• Leave room for whatever else a component needs: colour variants, different data shapes, widgets with partial data
• Agents can render their new work here instead of creating one-off mock files that get deleted right after
• Playwright can run against it automatically, so opening a PR triggers UI regression screenshots in CI
• Reviewers see those screenshots in the PR and approve the visual change directly from there

Where I landed

Storybook is a good answer to a question I do have, but it isn't the only one.

I want explorations to be cheap, component states to be visible without throwaway files, and agents to read a component in one file instead of five. A prototype lane and a generation script get me most of that, and they fit how we already work.

Thanks for reading!