Gergely Orosz talked to an engineer who used to review every line of AI-generated code. Then a new coding tool arrived, and the engineer stopped reviewing all of it — except the parts of the product that mattered most (AgentConn). That's not laziness. It's a resource allocation decision made under pressure, and it's the same decision every engineering manager is now making whether they've named it or not.
For years, the code review conversation had two settings: strict (everything gets a careful human pass) or loose (trust your senior engineers, move fast). AI-generated code broke that dial. When an agent can produce a plausible pull request in minutes, the bottleneck doesn't disappear — it moves. LeadDev puts it plainly: pull requests now accumulate faster than engineers can understand, test, and approve them. The scarce resource was never typing speed. It was always judgment, and judgment doesn't scale the way code generation does.
Rigor and speed were never actually opposed. Attention and volume are.
The mistake managers make when they frame this as "how strict should our review process be" is treating rigor as a single knob. Anthropic's Claude Code team ran into this at a scale most teams haven't yet: daily changes to their monorepo went from roughly 2,500 in May to more than 30,000 in September (claude.dev). Manual, line-by-line review at that volume isn't a staffing problem you can solve by hiring more reviewers. So they didn't try to make review faster — they changed what review was for.
Their six-layer pipeline runs automated checks before a PR even exists, during CI, through a security pass, through a risk-based approval classifier, inside a merge queue, and again after merge behind feature flags (Tech Bytes). Most of that path has no human in it. The goal they set wasn't "review everything thoroughly" or "review nothing and trust the model" — it was that most PRs merge with at most one human in the loop, and that the revert rate doesn't rise. Between June and September, merged PRs more than doubled while reverts fell by over 40 percent (claude.dev). That's not a story about relaxing standards. It's a story about deciding, deliberately, which 10 percent of changes deserve a human's full attention and routing the other 90 percent through checks that don't require it.
This is the real variable you're setting when you write a code review standard: not "how careful are we," but "which changes get routed to a human, and on what basis."
The "stop reading code" take skips the part that doesn't compress
There's a louder argument going around that code review is becoming obsolete entirely — that AI output should be verified by tests and behavior the way compiler output is, and nobody needs to read it (AgentConn). I'd push back on that framing, because it collapses two different kinds of work into one.
A sharp piece on DEV Community makes the distinction I keep coming back to: CI is embarrassingly parallel — you can throw more test shards and faster runners at it and the problem compresses. Review is serial reasoning across an entire change, where the claims in one file depend on a contract in another. Two reviewers don't halve that time; they add surface for disagreement. That's why sampling PRs for review, or waving through everything that passes an LLM check, doesn't buy you the same safety margin that parallelizing CI does — you end up skipping exactly the PR that breaks an authorization path. Separate research on agent-authored pull requests backs this up from another angle: generated changes can be integrated faster and still receive lower merge rates overall, and documentation fixes are far easier to verify than behavior-changing contributions (Netizen). Treating every AI-authored PR identically is the actual mistake — not insufficient AI trust, but insufficient differentiation by risk.
What tells you the standard is working
Two signals matter more than "are we shipping faster." First, revert and incident rates relative to volume — if PRs are climbing but reverts are flat or falling, your routing is sound; if both climb together, you've cut corners somewhere real. Second, and easier to miss: whether reviewers are still reconstructing authors' logic from scratch on a regular basis. LeadDev flags this as a trust cost, not just a time cost — a reviewer who keeps hitting obvious errors stops trusting the pipeline that produced them, and that erosion doesn't show up in your metrics until it's already expensive.
Set your standard around where human judgment actually changes the outcome, not around how much code gets read.
