You've had the moment. The PR passed CI. Every assertion held. The reviewer approved it, the deploy went out clean, and twenty minutes later someone on support is asking why three customers in a row couldn't find the button they use every day.
Nothing broke, technically. That's what makes it disorienting. If something had broken, a test would have caught it — that's the whole point of writing tests. So when the suite is green and users still struggle, the instinct is to blame the reviewer, or the ticket, or the AI agent that wrote the diff. Usually none of them are at fault. There's a specific, recurring failure shape teams are running into as coding agents take on more frontend work, and it has a name: a behavioral regression. It's a different category from the bugs your tooling was built to catch, and it's worth naming precisely, because you can't fix with more tests a problem that isn't a testing problem.
Visual regression and behavioral regression are not the same thing
Visual regression tooling diffs pixels. It tells you a button moved, changed color, or resized. It cannot tell you that the button now requires two clicks instead of one, that a form field that used to autofill no longer does, or that a keyboard shortcut a power user relied on got silently remapped. The screenshot can be pixel-identical and the interaction can still be broken — and just as often, the reverse: the screenshot changes a lot, exactly as the ticket asked, while the one interaction that mattered moved somewhere a returning user won't think to look.
That's the gap. Tests confirm the code does what a test expects. Code review confirms the diff does what the ticket asked. Visual regression confirms the pixels match what was intended. None of the three were ever built to answer a fourth, different question: will this still work for someone who already knows how to use it. Visual regression vs. behavioral regression breaks down that third check specifically — the quadrant where the pixels don't move and the interaction breaks anyway.
Why this specifically happens with AI-authored changes
An agent optimizes for the literal instruction and for not breaking anything your tests check. It has no model of how your actual users behave on that page — which elements they touch in sequence, what they expect a click to do based on six months of using the old version. A human engineer who's used the product for a while might catch "wait, this will annoy people" on instinct, even without being told to look for it. An agent has no instinct to draw on unless you give it one, and "don't break the tests" isn't that instinct — it's a different, narrower promise that happens to look similar from the outside.
This isn't a claim that agents write worse code. Often the opposite: the diff is small, well-typed, and does exactly what was asked, in a way a tired human reviewer at 4pm on a Friday might not have bothered to. That's precisely what makes the failure mode hard to catch. Nothing about the change looks wrong, because nothing about it is wrong, in the sense your tooling checks for.
What actually catches it, and what doesn't
| Check | Catches |
|---|---|
| Unit / integration tests | Logic errors, broken function contracts |
| Type checking | Wrong shapes and types |
| Code review | Obvious bugs, code smell, spec mismatches |
| Visual regression | Pixel and layout changes |
| Behavioral regression check | Changed interaction patterns against real usage history |
The first four are necessary, and none of them are built to answer "will this break what people already know how to do here." That question requires knowing how the page is actually used — which is session evidence, not static analysis. It's not a coverage gap you close by writing more assertions, because you can't pre-write a test for a habit you don't know exists until a redesign contradicts it.
What this looks like when it's not hypothetical
Everything above is easy to nod along to and hard to picture, so here's what it looks like run for real: a real coding agent, a real redesign ticket, against a page with real recorded user behavior behind it — published in full, tests and review and visual diff included, alongside what all three missed. Every check passed. The button 28 real users had learned to reach for without looking still moved 428 pixels, and nothing in CI had a way to know that mattered. Read the full experiment — diff, test output, and the behavioral data included, not just the argument.
If you're the one about to merge an agent-authored frontend change and want the practical version of this before it happens to you, here's a pre-merge checklist for exactly that. If you're the one reviewing someone else's agent-authored PR instead, reviewing AI-generated frontend PRs covers the same blind spot from the reviewer's seat.
The gap this leaves
None of this means AI coding agents are unsafe to use on frontend work, or that your review process is broken. It means the four checks most teams already run were built to answer "is this correct," and none of them were built to answer "does this still work for the person who already knows how to use it." That's not a gap you close by trying harder at code review. It requires evidence about how the page is actually used, checked against the change, instead of a reviewer's instinct for what might annoy someone.
Your agents can't see your users. Tests check the code; nothing checks the behavior — until something does.