Code review is the new bottleneck
For most teams adopting agents, code review is now the bottleneck: AI-generated code arrives faster than humans can responsibly read it. Generation stopped being the constraint on delivery sometime in the last two years. Verification did not, and every process built on the old ratio (code is expensive to write, cheap to review) is quietly breaking.
You can see it in the delivery data before anyone names it. Cycle time stays flat while everyone swears they are faster. PRs sit for two days, then land in a batch on Thursday. And the pattern we look for first: review depth collapsing as volume grows, approvals arriving minutes after a four-hundred-line diff opens. Nobody reads four hundred lines in four minutes. That approval is a signature, not a review.
Why code review breaks under AI-generated volume
Three failure modes, usually together.
Rubber-stamping is the first. Reviewers facing double the volume with the same hours do not review twice as fast, they review half as deeply, and AI-written code punishes shallow reading: it is plausible by construction, well formatted, confidently wrong in ways sloppy human code is not. The signals reviewers used as heuristics (messy naming, odd structure) are gone, while the defects moved into logic and omission, exactly where skimming cannot see.
Fatigue is the second. Reviewing is more draining than writing, and a day spent reading machine-generated diffs is a special kind of tiring: no narrative, no author to model, no "I see what they were trying". Teams that shifted volume onto agents without redesigning review report the same thing: writing got easier, work got worse.
The senior choke point is the third. Review concentrates on the people with the most judgment, who are also the people orchestrating agents, mentoring, and on the architecture hook. The queue forms behind two staff engineers, and the org’s delivery speed becomes their calendar. Ironically these are the same people the agent shift benefits most, which is the argument for putting seniors at the center of it rather than at the end of its conveyor belt.
Shrink the diffs before anything else
The cheapest fix is also the least popular with agents left to their defaults: cap the size of a reviewable change. Review quality falls off a cliff with diff size; a task split into four coherent two-hundred-line PRs gets genuinely reviewed, the same work in one nine-hundred-line PR gets skimmed. Since agents do not mind the overhead of splitting work, and can be instructed to structure it that way, this is nearly free. Make the cap explicit, and make exceptions visible rather than silent.
Let machines review first
Human attention is the scarce resource, so spend none of it on what machines catch. The first tier is guardrails in CI: tests, static analysis, security scans, conventions as lint rules, all green before a human looks. The second tier is agent pre-review: an agent reads the diff against the team’s own checklist (error handling, permissions, the invariants this codebase cares about) and either fixes or flags before the PR reaches a person. Pre-review does not replace human judgment. It cleans the input to it, so the human reviews design and intent instead of hunting for a missing null check, and the tests that ship with the change do the first round of arguing about whether it works.
Tier review by risk, not by habit
Uniform review is a relic of uniform risk. A change to payment logic and a change to an internal dashboard do not deserve the same process, and pretending they do is how teams end up giving both fifteen distracted minutes. Write the tiers down: sensitive paths (auth, money, data deletion, public APIs) get a required named reviewer, no self-approval, no time pressure. Routine product code gets one reviewer plus the machine tiers. Low-stakes internal tooling can ship on green CI and agent pre-review with humans sampling after the fact. The point is not less rigor. It is rigor placed where it pays, deliberately, instead of diluted everywhere evenly.
Watch the queue like a delivery metric
Whatever you change, instrument it: time to first review, queue depth, review depth on sensitive paths, and defect escape rate to check the whole system against reality. These belong on the same dashboard as cycle time, because review load is the leading indicator of AI-era delivery health, the place where trouble shows up weeks before the incident review. If review time is growing while everything else improves, you are not seeing a bottleneck forming. It has formed.
Redesigning review, tiers, pre-review, diff budgets and the metrics to keep it honest, is core work in our agentic engineering engagements, and it is usually where the delivery numbers finally move: teams do not feel the speed of agents until reviewing stops being the place where speed goes to wait.