The pitch for Opus 5 was that the model checks its own work now. Anthropic's Opus 5 guidance says as much: the model verifies by default, and the verify and double-check lines you used to write now only make it over-verify. Checking its own work as it writes is one job; reviewing the finished diff is another. Opus 5 got better at the first, and that quietly excuses you from the second: the four-hundred-line change it just produced lands on your branch behind a green check nobody actually read.
If you run Claude Code with a few agents at once, you know the shape of it. One developer on Hacker News put the volume plainly: "Once AI starts generating code, it flows out like water through a burst dam. It's impossible for any human to fully understand it all." Another, running the same setup I do: "I also fire off tons of parallel agents, and review is hands down the biggest bottleneck." (Hacker News)
Opus 5 was supposed to make this faster. What it did was move the work. You write less and review more, and reviewing what a machine wrote is harder than reviewing your own, because none of the context is already in your head. Robert Laszczak said it cleanly this month: "Reviewing code written by an agent is much harder than reviewing code that you have written by hand." You reached for a faster writer. You got a full-time reviewer of code you cannot fully hold in your head.
The green check is not a review
When the queue backs up, the review stops being a review. Shmulik Cohen has a name for what replaces it: vibe merging, "where developers, overwhelmed by the volume of AI-generated code, simply skim the diff or hit Approve based on a gut feeling." The tell they point to is the one you have already done: "the LGTM speedrun, approving a 300+ line diff in under three minutes." The green check did the reviewing. You just signed it.
None of this is new. Developers skimmed diffs and waved through a quick LGTM long before agents wrote code. But a fifty-line changeset you skimmed, you mostly still caught; the skim was cheap because the change was small. The skim has not changed. The changeset has. Four hundred lines written in two minutes and approved in three, and the same gut-feel pass now lands on a fraction of what it used to cover. AI did not invent the rubber stamp. It multiplied what rides on it.
This is not a private feeling, either. The industry instrumented it. Faros AI read two years of telemetry from 22,000 developers and found median time in code review up 441.5%, and pull requests merged with no review at all up 31.3%. LinearB, across 8.1 million pull requests, found AI-assisted PRs run 2.6 times larger than hand-written ones and sit more than five times longer before a reviewer even picks them up. The code arrives faster; the reading does not. And the quality gap underneath it is one developers can feel: in Stack Overflow's 2025 survey, 46% now distrust the accuracy of AI output against 33% who trust it, only 3% highly, and the single biggest frustration, cited by 66%, is the answer that is "almost right, but not quite." That is precisely the kind of bug that survives a three-minute skim.
The reflex is to point a model at the model
So the obvious move is to automate the reading. If a model wrote the code, have a model review the code. Opus 5 will tell you to do exactly this. Ask it how to keep its own mistakes out of main and it will happily offer to review its own diffs, the guess volunteering to grade the guess. That is the recommendation to distrust first. Every code host now ships an AI reviewer that leaves comments on the diff, and for the mechanical layer it genuinely helps, the way a linter helps: it "generates the same sort of local, mechanical feedback a linter does, all the stuff that might bog down a human reviewer and keep them from handling the big-picture items." (Hacker News)
The trouble starts when you ask that reviewer to be the thing standing between a four-hundred-line AI diff and your main branch. Now you have a model checking a model, and its verdict is the same kind of stochastic guess that wrote the code, made on a question that gets harder, not easier, the more code you hand it. Across a large change the odds of being right on every call multiply down: a per-line accuracy that looks fine on one function collapses across a hundred of them.
A stronger base model does not rescue you
It is still a guess, and the number of guesses is what grows. The argument is the same one from Opus 5: Delete your CLAUDE.md?, where the model grades its own instruction rules: a stochastic judge run many times over gets less reliable exactly where you leaned on it hardest.
What actually holds the line
The thing that scales with the model is not a faster reader but a gate that does not read at all. A deterministic check refuses an action outright: a test that fails, a lint rule that blocks, a hook that denies a write to a path the change was never supposed to touch, a schema that rejects a malformed file. It forms no opinion about the diff, so it does not get less reliable as the diff gets bigger, and it returns the same verdict on the hundredth file as on the first. Prompts steer, hooks enforce: steering is advice the model can weigh and set aside, a gate is a floor it cannot. We run gates like this on our own agents, and they catch what a tired reviewer at 6pm does not.
Bryan Finster, who has argued for years that code review was always the weak point, lands in the same place: "The answer is to automate all the things that can be automated, and reserve human judgment for what genuinely requires it."
What a gate cannot do
It is worth being exact about the boundary, because this is easy to oversell. Judging whether this is the right feature, whether the architecture will still hold in six months, whether the code does what the ticket actually meant: each of those needs a model of the world the change lives in, the product, the people using it, where the whole thing is headed. A gate has none of that. It checks the diff against a rule, never against reality, so that call stays human.
And some of the pushback on the whole "review is the new bottleneck" framing is warranted. One developer's flat response to the panic was "was anyone claiming it is the bottleneck? Seems like a straw man," and they are right that review was always a constraint. What changed is the ratio. When you wrote the code, your judgment went mostly into writing and a little into review. Now the writing is nearly free and the judgment is the whole job, so the mechanical load that used to hide inside your review has to move somewhere the model cannot talk its way past. That somewhere is a gate.
Read the rules once, gate the rest
You reached for Opus 5 to write more and decide less. The way to actually get that is to stop spending human attention on the parts a check can settle, format, conflicts, a forbidden call, a write outside the blast radius, and spend it on the one thing a model cannot hand you, which is whether this was worth building at all. Pointing a second model at the first one feels like progress and quietly rebuilds the problem one guess at a time. A gate the model cannot argue with is the boring answer, and it is the one still standing on the hundredth pull request of the day.
I work on Reporails, deterministic diagnostics and governance for the instruction files, rules, and prompts that steer coding agents. It reads the steering surface you wrote down and tells you, with measured evidence, which instructions couple to behavior and which are text the model can ignore. It does not run your model, and it does not vote; it measures the file.
