For two years the pitch has been that AI removes the bottleneck. Type an intent, get a diff, ship faster. And the writing part genuinely got faster. But work doesn't disappear when you speed up one station on the line — it piles up at the next one. That next station is review, and it did not get an agent.
So here's the state of a lot of teams right now: three engineers, each running a coding agent, each opening two or three PRs a day, each PR bigger and touching more surface area than the hand-written ones used to. The reviewers are the same humans, with the same hours, and the same finite attention. The queue grows. And the way humans cope with a growing review queue is the worst possible way — they skim.
An LGTM skim is worse than no review
A skim that catches nothing is worse than skipping the review altogether, because it launders risk. A diff that got a rubber-stamp "LGTM" now carries a signal to everyone downstream (a human looked at this) that happens to be false, and the next person trusts it more than an un-reviewed diff precisely because it has a green check and an approver's name on it. That misplaced trust is exactly where regressions slip into main.
The volume makes this inevitable. Agent-generated changes are larger and land more often, and the churn shows up in the data: GitClear's analysis of millions of commits found code churn and duplicated code blocks rising sharply as AI assistants took over, with more code moving and more of it copy-pasted rather than refactored. That is precisely the input that overwhelms line-by-line review. You were never going to read your way out of it; reading was already the slow path, and ten times the diff makes it slower, not faster.
The instinct to "just review more carefully" is a trap. Careful line reading does not scale with diff volume, and pretending it does is how you end up with reviewers who are simultaneously exhausted and ineffective.
Review intent, not lines
The move is to change the unit of review. You cannot read every line an agent produces, but you can assert that every user-visible behavior still works, and that turns out to be a bounded problem: the number of behaviors your product has is far smaller and far more stable than the number of lines that implement them.
An agent can rewrite a checkout flow across fourteen files, and the behaviors sitting under it stay the same four they always were: guest can check out, invalid card shows an error, totals include tax, empty cart blocks the button. Those are reviewable. They're finite, they're stable, and they map directly to what a user would notice if the diff broke something.
So the review question stops being "is this code correct?", which never scaled, and becomes "which behaviors does this diff touch, and do they all still pass?" That question has a mechanical answer a machine can produce. A human reviewer, freed from pretending to have read 600 lines of agent output, can then spend their judgment on the one thing only a human can judge: is this the behavior we actually wanted?
This is the same trust-allocation argument that applies to tests an AI wrote: execution proves the mechanics, humans own the intent. It just applies one level up, to the diff.
The playbook
Here's the concrete version. Four moving parts, each of which you can stand up incrementally.
1. Map the behaviors that matter. You can't assert behaviors you haven't enumerated, and the hardest part of enumerating them is knowing what you're missing. Coverage mapping does this by deriving your app's areas from the source and lining them up against what your tests actually exercise, so the gaps are visible instead of assumed. The goal is a named list of user-visible behaviors per area, ranked by what breaks a customer's day if it fails, and that list is your review checklist. See coverage mapping in practice for how the app-area-to-coverage view works.
2. Run a full regression every night. Not every behavior needs to gate every PR. Some flows are slow, and running the entire suite on each push would throttle your merge rate right back down to the speed you were trying to escape, so push the exhaustive pass to a scheduled nightly run against a stable environment. The whole behavior set gets exercised once a day regardless of what merged. The nightly regression playbook covers the scheduling, environment, and triage-in-the-morning workflow.
3. Smoke the critical paths on every PR. The subset that must never break, meaning sign-up, login, checkout, and whichever one flow is your actual business, gets asserted per-PR, in CI, as a merge gate. Keep it small and fast enough that it never becomes the reason people skip it. This is the layer that catches the agent that confidently refactored auth and broke the redirect. Wire it into your pipeline so a red behavior blocks the merge the same way a failed unit test does, and CI/CD integration shows the hook points.
4. Make "which behaviors does this diff touch?" the review question. With coverage mapping telling you which areas a change lands in, the reviewer's job becomes tractable: confirm the touched behaviors are covered, confirm the smoke run went green, and spend the saved attention on intent. The line reading becomes a spot check, not the whole job.
Notice what this does to the reviewer's day. They stop trying to hold fourteen files in their head. They look at four behavior results and one question: did we want this? That's a job a human can actually do well at ten diffs a day.
Why generated tests are the enabling condition
This playbook has an obvious dependency: it only works if writing the behavior assertions is cheap. If standing up a smoke test for every critical path costs you a day of Playwright plumbing per flow, you'll never keep pace with the agents flooding the queue. The tests become their own bottleneck, and you're back where you started.
That's the real reason describe-it-in-plain-language test generation matters here, and it goes deeper than the usual pitch about writing tests being tedious. The review bottleneck only clears if the behavior-assertion layer scales at the same rate as the code-generation layer. Agents write the code fast; you need something that writes the behavior checks just as fast, runs them in a clean environment, and reports pass/fail per behavior. Otherwise the two halves are mismatched and the queue backs up again.
None of this replaces judgment. A green behavior suite tells you the app still does what it did. It can't tell you whether what it does is right, or whether the agent's diff introduced a subtle security or data-model problem that no user-visible behavior surfaces, and that part is still yours. What it does collapse is the part of review that was never a good use of human attention, the did this large, plausible-looking diff break something a user would notice? question, into a signal you can read in seconds. If you're rethinking how your team reviews AI-authored changes end to end, the 2026 e2e strategy piece frames where this layer sits in the larger picture.
When you approve on a skim and trust a green check you didn't earn, the speed you gained from agents comes back to you as regressions in production. Review at the altitude where the problem is tractable instead: enumerate the behaviors a diff touches, confirm they still pass, and spend your real attention on whether the change was one you wanted. That is a review you can actually run at ten diffs a day without lying about it.
Want to see which behaviors your suite already covers, and assert the critical ones on every PR? Get early access, or read how coverage mapping turns your source into a reviewable behavior list.