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 genuinely specific to Storybook, and what do we actually want out of it?

Because those turn out to be very different lists, and only one of them matters.

What is specific to Storybook

Two things, as far as I can tell:

• An MCP server built in, for agents to tap into
• Figma ↔ Storybook dev mode sync

Both are real. Neither is load-bearing for me right now. We can technically skip Figma, and MCP tends to work less favourably across worktrees, which is where a lot of my work happens these days, with several agents running in parallel branches.

What we actually want

The arguments I hear for Storybook are almost never about Storybook. They're about:

• Testing different states. A chat in an error state, a widget with partial or missing data, an empty list, a slow load.
• UI regression testing. Change one shared component like Modal, and quickly see the changes across every other call site.
• Easing the approval process. If we can visually see a new button variant everywhere it lands, we can approve it properly instead of blindly accepting a diff.

Storybook as an idea for improving process is great. It's the specific implementation I'm not convinced we need, when we could maintain a smaller tool that fits our own workflow.

Where velocity actually 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 is fine at low velocity. It stops being fine the moment AI raises the number of explorations a designer can produce in an afternoon. The same four steps start working against the prototyping phase, and explorations begin to feel constrained:

• 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 is usually built to require tests and checks to pass, which affects branches that were never meant to ship

Exploration is supposed to be cheap. When every experiment carries the ceremony of production code, people quietly stop exploring.

What I'd build instead

1. Generate component docs for agents, not for humans

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

The main perk is token cost, at almost no effort. It's just a script that auto-generates files from the components we already have. Instead of an agent opening and reading a component's source to work out what it does, it refers to one generated file. Because it's derived from TypeScript, it's regenerated every time and never goes stale. It also works across worktrees, which is exactly 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, one purely 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. That's intentionally a two-step process: designers get to iterate fast, and engineers only look closely at the ones 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. I just don't think the answer has to be Storybook.

What I actually want is for explorations to be cheap, for component states to be visible without wiring up throwaway files, and for agents to read a component in one file instead of five. A prototype lane and a generation script get me most of that, in a shape that fits how we already work, and I get to keep the parts I need without inheriting the parts I don't.

Thanks for reading!