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.