Visual testing with Claude Code

Claude Code closes almost every loop it opens. Hand it a failing test, a type error, or a red CI log and it reads the signal, reasons about the cause, and fixes itself. The one surface where that self-correction stalls is the UI: Claude Code edits some CSS, has no picture of the result, and reports that it "looks great" on its way to opening the pull request. The fix is not a smarter model. It is making the screenshot the thing Claude Code has to pass before the change counts as done.

Visual testing with Claude Code means screenshotting your UI on every pull request Claude Code opens, diffing each screenshot against a known-good baseline, and handing the diffs plus an AI judge's verdict back to Claude Code over MCP so it can triage its own visual changes. Claude Code writes the UI, UI Verify renders and diffs it in the cloud, the judge labels each change a regression or an intended change, and Claude Code reads those verdicts in the terminal where it already works. It is the same visual regression testing your team does by hand, wired so the agent that made the change is also the one that checks the pixels.

When a human wrote three pull requests a day, "looks great" from the author was a reasonable claim and a reviewer glancing at the diff was enough. When Claude Code writes thirty, the author's self-report stops being evidence. You stop trusting the sentence and start requiring the artifact: render the component, show the before and after, and let a check decide whether the change was the point of the PR or a regression that rode along with it.

That is what "acceptance gate" means here. A green visual check is the condition for the change being finished, the same way a passing test suite is. Claude Code cannot mark a UI task done on its own assertion that the pixels are fine, because it never looked at the pixels. It has to produce a screenshot that either matches the baseline or gets an explicit verdict on why it moved. The gate turns an untrustworthy claim into a checkable fact.

A coding agent's autonomy on the backend comes from a tight feedback loop: it acts, the system reports back in text it can read, and it corrects. A stack trace, a failing assertion, a lint error - all of it arrives as tokens. The UI breaks that loop because the result is an image, and an agent editing CSS gets no readable signal about how the rendered frame changed. So it certifies its own work without ever seeing it, which is not a review at all.

This is why a UI regression written by an agent tends to surface late, from a human, after merge. The agent moved a shared component's padding, saw nothing, and shipped. Nothing in its loop flagged it, because nothing in its loop could see it. Closing that gap means giving Claude Code the one input it was missing - the actual diff - in a form it can parse. The longer version of why agents are blind on the UI is in Close the loop: let your agent triage visual diffs over MCP.

Put the pieces in order and the review runs where Claude Code already lives, without you in the middle:

1. Claude Code writes the UI change and opens the pull request.
2. UI Verify renders every affected story in the cloud and diffs each screenshot against its baseline.
3. The AI judge labels each change a regression or an intended change, with a reason, and holds the PR when it flags a regression. See the AI judge.
4. Claude Code pulls the build's changed stories over MCP, looks at each cropped before and after, reads the judge's verdict, fixes the real regressions, and accepts the intended ones as new baselines.
5. The required check flips green and a human reviews decisions, not raw diffs.

The judge is what keeps step four from collapsing back into work. A raw pixel diff tells Claude Code that something moved; it does not say whether it should have. A verdict does, so the agent triages against its own PR intent instead of eyeballing a delta. And the diff it pulls is cropped to the region that changed, so a vision model reviews the button that moved rather than scanning a full page and finding nothing. Why that granularity is what makes the review trustworthy is its own post.

UI Verify exposes each build - the per-story diffs and the judge's verdicts - over the Model Context Protocol, so Claude Code can review a build from the terminal. You add the server once with claude mcp add; your project setup page has the full command with the key already filled in, and the key is prefixed uv_proj_.

Once it is connected, Claude Code has a small set of tools that map straight onto the loop above: it lists the changed stories, pulls each cropped before and after as inline pixels its vision model reads directly (which is why it needs a native client that renders image content, and Claude Code does), reads the judge's verdict, and links the presigned image URLs into a pull-request comment before accepting the intended baselines. The exact tool-by-tool call sequence lives in the MCP triage walkthrough, and the docs version is Triage visual changes from your coding agent.

The MCP gives Claude Code the tools; a skill gives it the playbook. UI Verify publishes a skills plugin for Claude Code so you do not have to teach the agent the review flow every time. Install the whole bundle from the marketplace, and the triage skill turns the loop above into one command:

With it installed, /triage-visual-changes runs the review from the terminal: it buckets the changed stories into real regressions, cosmetic reflow, and rendering noise, looks at the pixels when a number is ambiguous, summarizes the real regressions for a PR comment, and accepts the intended baselines in bulk. Prefer just the one skill without the plugin? npx skills add uiverify/uiverify --skill triage-visual-changes grabs it for any MCP-capable agent. The full playbook is the triage visual changes skill, and the rest of the catalog is at all the visual-testing skills.

One lead engineer I talked to runs his entire ship pipeline through Claude Code in the terminal, one tab per ticket, no dashboard on top. Nearly every step self-heals: an agent watches the CI logs and sorts a real failure from a flaky one, and a final pass turns any correction he made during the run into a new lint rule so the mistake cannot recur. The one step that stubbornly stayed manual was the visual check. He was booting the environment, screenshotting the UI, and handling the images by hand, because there was no clean way to get a screenshot back into the terminal where his agents live and act. Everything in his loop closed itself except the one surface that produces an image instead of text.

That gap is exactly what the MCP fills. When the diff and the verdict arrive as something Claude Code can read, the visual step joins the rest of the self-correcting loop instead of dropping the agent back to a human dragging PNGs around. The screenshot becomes another signal the agent reasons over, not a detour out of the terminal.

Agent-native visual review is where the whole category is heading, not a UI Verify quirk. Once a machine writes most of the UI, the reviewer has to reach the change the same way the author did - programmatically, in context, without a human ferrying screenshots between a dashboard and a terminal. The incumbents are building the same shape into their roadmaps: Percy's Visual Review Agent, Applitools' Visual AI, and Argos' MCP approve all point in this direction, so the open question is execution, not whose idea it was. UI Verify's bet is to build the loop around the agent from the ground up: cloud render so Claude Code screenshots once and never runs your environment twice, an AI judge whose verdict travels with the diff, and crops shaped for a vision model instead of a human's scroll.

If you drive Cursor instead of Claude Code, the same MCP and skills work there too - see Visual testing with Cursor. Either way, the move is the same: stop trusting the agent's "it works" and make it render the component and show the diff. The UI was the last open loop in an otherwise autonomous workflow. Give the agent eyes on the diff and it closes.