DEV Community: Igor Luchenkov

Your coding agent can write the UI. It can't see that it broke it.

Igor Luchenkov — Sat, 05 Sep 2026 08:23:27 +0000

Give a coding agent a failing test and it fixes itself. Give it a stack trace, a type error, a red CI log, and it reads the signal, reasons about the cause, and corrects. That loop is the whole reason agents feel autonomous on the backend.

On the UI it falls apart.

The agent edits some CSS, sees nothing, and tells you it "looks great." It has no eyes on the result. A blind reviewer rubber-stamps everything, and an agent reviewing its own UI change with no picture of it is exactly that. So it ships, and you find the regression later: a button that shrank two pixels, a card that reflowed on mobile, a shadow that vanished in dark mode. Nothing your test suite asserts on. Nothing the agent could see.

I've been building visual testing for this exact gap, and the fix turned out to be boring. Give the agent the actual diff.

The missing piece was never a smarter model

Every team I talk to running agents at volume has built the ugly version of this by hand. They stand up a little server just to get a rendered image in front of the agent, because you can't hand a raw PNG to an agent through a pull request and image handling in the PR is painful. They end up maintaining, by hand, the exact review surface the agent needed all along.

The thing that actually closes the loop is unglamorous. Screenshot the UI in the cloud on every PR, diff it against the baseline, and post a check and comment right on the pull request, the same place your agent already looks when something goes red.

It starts on the PR: the comment lands with the changed stories already split, so you read the shape of the change without opening a dashboard.

Two details matter more than the model.

The diff is cropped to what moved. Not a full-page screenshot. Hand a vision model a 1440px-tall page and it will not reliably notice a button's padding shrank. Hand it the crop, baseline and candidate side by side, just the region that changed, and it catches it. That granularity is the difference between an agent that reviews and one that rubber-stamps.

The regression the judge caught: the Add-to-cart button flipped to a faint outline on a page the rating-badge PR never meant to touch.

The pixels come back inline. The agent's vision model looks at the actual crop, not a URL it can't open.

What the agent actually does

An AI judge labels each change against the PR's stated intent, intended or regression, with a reason, so the list is already triaged before the agent looks at a single pixel.

The build view: the judge sorts the changed stories into regressions and intended restyles before anyone opens a diff.

Once the MCP is connected (one command with your project key), the agent has a small set of tools that map onto the loop:

list_build_stories  { status: "changed" }              -> the stories that moved this build
render_diff_image   { storyId, which: "before_after" } -> before/after, cropped, inline pixels
get_diff            { storyId }                         -> the AI judge's verdict + reasoning + image URLs
accept_build        { ... }                             -> promote the intended changes to new baselines

Put together, the whole review runs without you in the middle:

The agent opens the PR and the visual check renders every affected story in the cloud.
It lists the changed stories and pulls the cropped before/after for each.
It classifies each one, intended change or real regression against what this PR set out to do, reading the judge's verdict alongside its own look at the pixels.
It fixes the regressions, accepts the intended changes as new baselines, and posts a summary comment. The required check flips green before a human opens anything.

Then it moves to the terminal: the agent runs get_diff over MCP, decides intended vs regression, fixes the real one, re-runs, and reports back ready to merge.

The step-by-step version, tool by tool, is in Triage visual changes from your coding agent.

The one rule I don't let the agent break

A changed story the diff cannot explain is not something to accept or wave off as flake. If a story moved that this branch had no business touching, that's a signal to stop and investigate the baseline, not to rubber-stamp it.

Accepting the intended changes is the easy 90 percent. Flagging the one that doesn't fit is the entire reason you gave the agent eyes in the first place. An agent that accepts everything is just a faster way to ship a regression.

Why I think this is where visual testing goes

Everything else in the agent loop already closes itself: tests, types, lint, CI. The UI was the one surface that still needed a human to look. Once agents write most of the UI, the reviewer has to reach the change the same way the author did, programmatically, in context, with no human ferrying screenshots between a dashboard and a terminal.

Give the agent eyes on the diff and that last open loop closes too.

If you want the ready-made version, the triage-visual-changes skill packages this whole review into one command your agent runs, and the full skills catalog has the rest.

I'm building UI Verify, visual testing shaped for coding agents: cloud render, an AI judge whose verdict travels with the diff, and an MCP the agent drives itself. I write about this stuff as I build it.

How I cut my Chromatic bill 10x (works on any visual testing tool)

Igor Luchenkov — Tue, 04 Aug 2026 21:00:58 +0000

I have been a huge Storybook and Chromatic fan for years. But at some point the bill got my attention, and when I looked into why, the fix turned out to be simple. This is the write-up of what I changed. It works on any per-snapshot tool, not just Chromatic.

First, some backstory on how I got here, because it explains why the cost crept up in the first place.

How I ended up paying for a lot of snapshots

In the past I would build a gigantic end-to-end pipeline that was flaky as hell and made me spend time every week fixing it. It took 40 minutes to run, and when it went red someone would assume it was just flaky, merge the change anyway, and then find out it truly did break the system.

So I stopped writing lots of E2Es and moved to Storybook for interaction and visual testing. Much better. But because I was rendering every state of every component as its own story to get the screenshots in place, I was generating a lot of screenshots. And every snapshot tool, Chromatic, Percy, Playwright screenshots, UI Verify, renders and bills per story. So the number of stories is the cost, and it is also the noise surface: more stories means more places for a diff to flake.

I ended up paying a lot, which made me think about whether there were ways to optimise it. There were. Here they are.

The core idea: combine states into one story

The naive pattern is one story per variant times state times theme. A component with 5 sizes, 3 states, and 2 themes is 30 snapshots the naive way. The whole idea below is to collapse that matrix into a handful of stories while keeping full coverage.

Move 1: one gallery story, not N stories

For something like a Button, there is no need to have separate Primary, Secondary, and Tertiary stories. I prefer one AllVariants story that maps through the prop combinations and renders them in a grid. One snapshot then covers the entire matrix. As a bonus you get a nice grid that shows every permutation at a glance, with no extra clicks to see the variations.

// Button.stories.tsx
// ONE story covers every size x variant
export const AllVariants = () => (
  <div style={{ display: 'grid', gap: 16, gridTemplateColumns: 'repeat(3, max-content)' }}>
    {(['sm', 'md', 'lg'] as const).flatMap((size) =>
      (['primary', 'secondary', 'danger'] as const).map((variant) => (
        <Button key={`${size}-${variant}`} size={size} variant={variant}>
          {size}/{variant}
        </Button>
      )),
    )}
  </div>
);
// 9 buttons, 1 snapshot instead of 9.

Move 2: drive states from data, not from N stories

Same idea for a component that loads data. Instead of a Loading, Empty, and Error story each, I add an optional prop like storybookData and pass the response shape straight in. Then one AllStates story maps through the shapes and renders the component in each state. Deterministic input in, deterministic pixels out, many states, few shots.

// List.stories.tsx
const CASES = [
  { label: 'empty', items: [] },
  { label: 'one',   items: [fixtures.one] },
  { label: 'many',  items: fixtures.many },
  { label: 'error', error: 'Failed to load' },
];

export const AllStates = () => (
  <div style={{ display: 'grid', gap: 24 }}>
    {CASES.map((c) => (
      <section key={c.label}>
        <h4>{c.label}</h4>
        <List items={c.items} error={c.error} />
      </section>
    ))}
  </div>
);

The tradeoff: say it out loud

Consolidating into one snapshot is coarser granularity. A diff anywhere in the gallery flags the whole story, and you lose the per-variant baseline and accept. So this is a balance, not merge everything.

Merge variants that change together and share one component: the size, state, and theme matrix of one Button. This is where consolidation wins cleanly.
Keep separate genuinely independent surfaces: different pages, different flows, things that evolve on their own timelines. Collapsing those just couples unrelated diffs.

Rule of thumb: merge a single component's own matrix, keep independent pages and flows apart. A tool with per-region diffing softens the coarseness because it can tell you which cell in the gallery moved.

The result

Applying these two moves across the codebase easily reduced the number of stories I had by roughly 10x. On the components with the worst explosion the win is even bigger: a size times variant times theme matrix plus four data states can go from 28 stories to 2 snapshots, about 93% fewer billed shots, with the same coverage.

Same pixels under test, a fraction of the bill, and fewer places to flake. If you are actively writing stories and do not want to burn money, this is the cheapest change you can make.

Make it automatic

I got tired of remembering to do this by hand, so I packaged the whole pattern as a coding-agent skill. Install it and your agent writes stories the economical way from the start, and refactors the exploding ones for you. It is free, and it is tool-agnostic: it helps whether you are on Chromatic, Percy, Playwright screenshots, or UI Verify.

Grab it here: Write economical visual tests.

I write about visual testing while building UI Verify. This post was originally published on my blog.