Storybook 10.4.0 on May 14 Turns Git Diff Into UI Review: How to Use Change-Aware Review Right Now

Most Storybook releases are useful in the abstract and forgettable in practice. Storybook 10.4.0, released on May 14, 2026, feels different. The headline feature is not another addon or another round of "AI is here" marketing. It is a review feature that maps much better to how frontend teams actually work: you change a component, and Storybook can now surface the stories that changed with it.

That sounds small until you remember how a lot of teams really use Storybook. Big design system, hundreds of stories, one pull request, and somebody has to guess what matters. If 10.4 does one thing right, it cuts down that guessing.

change-aware review is the part worth caring about

The release adds sidebar filtering for new, modified, and related stories, plus status filters that stick in the URL. Under the hood, Storybook also shipped a new change detection service and Git-aware rescans. The implementation notes in PR #34420 are the interesting part, because they describe the real workflow instead of just the marketing line.

The maintainer's manual test flow was straightforward:

• enable features.changeDetection

• edit a component and confirm related stories get a modified or affected status

• add a new story and confirm it shows up as new

• commit the changes and confirm those statuses clear

That last bit matters more than it sounds. The PR explicitly says Storybook reevaluates the module graph when a new commit is created or when you switch branches, so components stop showing as modified once the work is committed. That is the difference between a cute badge and a review tool you might actually trust.

If you want to check whether this is wired up in your repo, this is the switch to look for:

// .storybook/main.ts
import type { StorybookConfig } from '@storybook/your-framework';

const config: StorybookConfig = {
  features: {
    changeDetection: true,
  },
};

export default config;

I would not roll this out as a big migration project. Just upgrade, turn it on, and test it against one active branch.

• change one component file and watch the sidebar

• add one new story file

• make a commit and confirm the noise drops away

If that works in your codebase, Storybook becomes much more useful during pull request review. If it does not, you learned that in ten minutes instead of during a design QA meeting.

this is how I would use it on a real team

The boring problem with Storybook review is not rendering. It is focus. Reviewers do not need the entire component catalog every time somebody tweaks a button group and a form field. They need the affected stories first, then the rest if something looks off.

With 10.4, I would treat Storybook like a Git-aware review surface:

• open the PR branch locally

• launch Storybook

• filter to changed stories first

• review related stories second

• only browse the full tree if something feels suspicious

That is a much saner default than "scroll around and hope you noticed the right component." The new URL-persisted filters also help because teammates can share the same filtered view instead of re-explaining where to click.

This is the kind of feature that sounds minor in release notes and quietly saves time every week.

storybook ai setup is better as a recovery tool than a magic trick

The other part of 10.4 getting attention is the new AI-assisted setup. I am less excited about this than the review workflow, but I do think it has one genuinely useful use case: catching up on Storybook in repos where everyone meant to write stories and nobody did.

According to PR #34297, storybook ai setup inspects the current project and generates a project-aware markdown prompt for a coding agent. The prompt tells the agent to analyze component patterns, configure .storybook/preview.ts, write story files with play functions for representative components, and run Vitest until the result passes.

The command to try is simple:

npx storybook ai setup

The important detail is that this is not some hidden auto-generator that silently rewires your app. It is closer to a structured handoff. Storybook figures out the project context, prepares the prompt, and then your agent does the implementation work.

That makes it useful in a pretty specific situation:

• your Storybook setup exists but is half-finished

• your preview decorators are stale

• your component stories are inconsistent

• you want a fast first pass, not a final answer

I would still review every generated story. I would especially review any play functions, mocks, and global decorators. But as a way to get from "we should really fix Storybook someday" to "okay, now we have a baseline," this is much more practical than I expected.

the quiet wins are React support and less setup friction

10.4 also shipped a new @storybook/tanstack-react framework, React docgen powered by the TypeScript Language Server, and a bunch of setup polish around Vite and package detection in the release notes.

I would not upgrade for those alone unless you are already living in that stack. But together they point in the right direction. Storybook is trying to be less generic and more aware of the actual frontend toolchains people are using right now.

That matters because the old failure mode for Storybook was obvious: too much hand wiring, too many stale stories, and too much review noise after setup. Version 10.4 does not solve all of that, but it does hit the right pain points.

should you upgrade now?

If your team already uses Storybook during frontend review, yes. This is one of the easier yeses in a while.

If your team has Storybook installed but mostly ignores it, I would still test 10.4 on one active repo. Change-aware review is the first Storybook feature in a while that feels built for daily usage instead of conference demos.

I would not sell the upgrade internally as "we have AI now." I would sell it as this: on May 14, Storybook got better at showing reviewers what changed, which is the one job it should have been better at a long time ago.