A QA loop your agents can run

An agent that just finished writing code will tell you, with full confidence, that it works. That confidence is not evidence, and treating it as evidence is how a broken layout or a silently failing form ends up in production. Asking the agent to be more careful does not fix this; refusing to accept a claim that was never checked does, so the loop checks it for you every time instead of taking anyone's word for it.

This is the actual loop we run before anything visual ships from our own agents, described plainly enough that you can set up a version of it for your own team this week. It has three parts: a screenshot loop that catches visual breakage, a set of mechanical gates that catch everything else, and a standing rule about which of those a claim from the agent is ever allowed to replace.

Screenshot, critique, iterate

For any change that touches what a user sees, the agent starts the real, running app and takes an actual screenshot of the actual page, no mockups involved. Then it looks at that screenshot against a written standard (a design reference, a spacing rule, a rule about what counts as broken) and writes down what is wrong. Then it fixes what it found and screenshots again. The loop keeps running until the screenshot passes; the agent's own sense that it is probably done does not end the loop.

• 01Take the screenshot at more than one size. A layout that looks right at desktop width and breaks at phone width is still broken; catching that requires actually looking at both.
• 02Critique against a written standard rather than a feeling. "Does this match the spacing scale and type system we already committed to" is checkable. "Does this look good" is a matter of taste, and an agent grading its own vague sense of good will grade itself generously.
• 03Fix and reshoot in the same pass. A critique that isn't followed by another screenshot is just a list of complaints nobody acted on.

The screenshot is the part that matters most. It is the difference between an agent describing what it believes it built and an agent looking at what it actually built, and those two things diverge more often than you would expect.

Gates before anything merges

Visual review is one gate among several, and none of them are optional or skippable because a change seems small. Before a pull request opens, the code runs through the mechanical checks a computer can verify without judgment. Small changes go through the same sequence as large ones, because the size of a change has little to do with whether it introduced a bug, and the whole point of a gate is that it does not ask for a judgment call about which changes deserve it.

1. Lint and type check the full change.
2. Run the test suite; a failing test blocks the PR.
3. Visual work clears the screenshot loop above.
4. A second AI review reads the diff independently.
5. Only then does the PR open for a human to merge.

That second AI review step matters more than it sounds like it should. An agent reviewing its own work shares its own blind spots; a second pass, run separately against the diff rather than the agent's memory of writing it, catches a different set of mistakes. It is the same reason a second pair of human eyes catches things the author missed, and it costs almost nothing to run.

Building your own version, without our tooling

None of this requires the exact setup we run. If your team is starting from nothing, a small script beats no script. A tool like Playwright or Puppeteer can drive a real browser against your running app, capture a screenshot at a couple of viewport widths, and save it somewhere the agent, or you, can look at it. Wire that script into whatever your agent already runs before it calls a task finished, even if the first version is just a shell command that saves two PNGs to a folder.

The written standard can start just as small: a short list of rules in a markdown file the agent reads before it critiques its own screenshot. Spacing values, the type scale, what an obviously broken layout looks like. It does not need to be sophisticated on day one. It needs to exist, because a rule written down is something an agent can check itself against, and a rule that only lives in your head is something it can only guess at.

Once the screenshot loop runs locally, the last step is making it run automatically on every pull request through your CI system, so a human reviewer opens the PR and finds the evidence already attached rather than having to ask for it.

Why evidence beats confidence

Every rule in this loop exists because a specific shortcut failed once. An agent will report a task complete before checking it because completing the task is what it was asked to do, and stopping to verify feels like an extra step rather than part of the job. Left alone, that habit compounds: a fleet of agents each skipping verification once a day adds up to a lot of quiet breakage nobody caught in real time.

The failures are rarely dramatic. A screenshot taken at one width that hides an overflow problem at another. A form that submits fine in the happy path and silently drops an error on a bad one. A test suite run once, early in the session, that nobody reran after three more files changed. None of those show up in a confident summary. All of them show up in a screenshot taken again, right before the PR opens, against the code as it actually stands.

The rule we hold agents to is simple: for anything that can be checked by running a command, checking it is not optional, and a sentence claiming success is worth nothing next to a passing gate. That sounds strict until you have watched a fleet of agents work for a few weeks. Then it just looks like the same discipline you would want from a human team, applied consistently instead of only when someone remembers to ask.

Nothing about this loop requires exotic tooling. A screenshot tool, a written standard to check against, a test suite, and a rule that nothing merges until all four have actually run gets you most of the way there, on any stack, whether your team is one person and a handful of agents or a larger group running several projects at once.

The loop also changes how you review agent work day to day. Instead of reading a summary and deciding whether to trust it, you open the attached screenshot and the passing gates and make the call from what actually ran. Once the habit sets in, that review actually gets faster: a passing gate answers a question in one glance that a paragraph of self-reported confidence never quite settles.

We run a fuller version of this loop across every client site and every internal tool we ship. If you want it built into your own team's workflow, that is part of our AI consulting work, and the membership includes the full playbook with the exact checks we run at each gate.