You approve PRs from your team because you trust the process: someone wrote the change for a reason, sized it to what they could defend, and you can ask them why. None of that holds when the author is an agent. The diff looks the same. The reasons you trust it don't apply.

Most teams keep reviewing agent-authored frontend PRs the same way anyway, because nothing about the tooling forces a different habit. That's how rubber-stamping starts: not from carelessness, but from applying a human-scale process to a diff that was never produced at human scale.

Volume breaks scrutiny

A person paces their output to what they can defend line by line. An agent doesn't pace itself at all: instructed to "clean up the settings page," it might touch fifteen files in the time a teammate would have touched three. Review time doesn't scale with diff size the way agent output does, so the same 20-minute review slot now covers a fraction of the surface it used to.

The fix isn't reading faster. It's reading differently: spend your fixed review budget on the elements the diff touches, not the lines it changes. A renamed CSS class and a removed keyboard handler cost the same one line in a diff and nothing close to the same risk.

The diff shows intent, not behavior

A teammate's PR description usually tells you why. An agent's summary tells you what it did, and the two aren't the same thing. "Refactored the modal component" is accurate and useless — it says nothing about whether the modal still closes on Escape, whether focus still returns to the trigger element, or whether a toast that used to queue behind it now overlaps it.

Agents are reliable narrators of their own mechanism and unreliable predictors of its consequences. Read the description as a claim about what changed, not evidence about what still works.

The failure mode is plausible, not broken

Reviewing for bugs means looking for things that are obviously wrong: a null reference, a missing await, a state update that can't fire. Behavioral regressions in agent-authored code are rarely obviously wrong. The page renders. The button is still there. Nothing throws.

What's different is one click became two, or a dropdown that used to remember the last selection now resets, or a form that auto-advanced on Tab now requires a click. Every one of those ships clean through a diff, a type checker, and a green test suite, because none of them were built to notice that the interaction changed while the code got no more incorrect.

It ships clean through a visual regression pass too, which is the counterintuitive part — the pixels can be exactly right while the interaction is wrong. What tests don't catch when AI rewrites your interface names this failure category and walks through why none of the standard checks are built to catch it.

What to actually do differently

  • Review the interaction, not just the diff. Pull the branch and open the before and after side by side. A change to a form's submit handler reads as three lines moved; using it tells you in ten seconds whether the tab order still makes sense.
  • Ask explicitly what changed beyond the ask. Prompt the agent, or yourself, with "what interactive behavior does this touch that the ticket didn't mention?" Agents are good at the literal task and bad at volunteering side effects unless something makes them look for them.
  • Treat a passing test suite as a floor, not a signal. It tells you the agent didn't break what your tests were written to catch, which is a statement about your test coverage, not about the change. Most frontend test suites weren't written to catch a changed default, a reordered field, or a removed shortcut — they were written for the bugs someone already knew to guard against.
  • Weight scrutiny by how often the surface is actually used. A cosmetic change to a settings page nobody opens carries different risk than a rename in the checkout flow. If you only have twenty minutes, spend eighteen of them on the high-traffic surface.
  • Look for what's missing, not just what's different. Diffs are built to show you additions and edits. They are bad at making you notice the affordance that quietly disappeared — the secondary button that used to be there, the empty state that used to explain what to do next.
  • Don't let a passing visual regression check stand in for this. A pixel diff and a behavioral regression are answering two different questions; see visual regression vs. behavioral regression for where the two diverge.

If you're doing this for the first time on a PR that's already open, start with the pre-merge checklist in how to test Claude Code frontend changes before you merge — it walks through the same diff from the angle of what to manually verify before you approve, rather than what to weight as a reviewer.

Why review process hasn't caught up

None of this is a knock on the reviewers. Code review as a discipline was built around a human rate of output, and the assumptions underneath it — that the diff size roughly tracks the author's own scrutiny, that the PR description is a reasonable proxy for intent, that a passing test suite plus a careful read catches most of what matters — held up fine for a decade of human-paced PRs. They don't transfer to a PR an agent wrote in ninety seconds.

The gap has a name: unclaimed surface. It's everything a change touches that the author never explicitly claimed responsibility for — the tooltip that referenced the button that moved, the keyboard shortcut nobody wrote a test for, the muscle memory a returning user built up over six months. An agent has no way to see that surface, because seeing it requires knowing how people actually use the page, not just what the code does. A reviewer skimming a large diff under time pressure usually can't see it either.

That's the part a checklist and a careful reviewer can't fully close on their own — not because the process is wrong, but because "does this still behave the way our users expect" is a question about real usage, and a diff has no access to real usage. It's why UXSense checks every pull request against a Behavioral Load Map built from actual recorded sessions, and flags exactly which interactive elements a change touches that carry real behavioral weight, before you approve it rather than after a user notices.