When Most of Your Code Comes From an Agent, the Review Bottleneck Doesn’t Disappear. It Moves.
Executive Summary. Most of the conversation about AI coding agents is about speed: how much faster a team can move once an agent is writing a meaningful share of the code. Speed is real, and it’s not the hard problem. The hard problem is that the thing which used to catch a bad change before it shipped — a human reading the diff, understanding why it exists, and deciding whether it belongs — was already the slowest part of software delivery before agents arrived, and it has not gotten faster just because the code arrived faster. The review bottleneck doesn’t disappear when an agent starts writing most of the code. It moves somewhere, and if an organization hasn’t decided where on purpose, it moves to the worst possible place: nowhere, until something breaks.
The Part of the Pipeline That Didn’t Get Faster
Code generation sped up first, and it sped up the most. Review didn’t, for a reason that has nothing to do with tooling: review is a judgment task, not a throughput task. A reviewer isn’t scanning for syntax errors — a compiler does that for free. A reviewer is asking whether this specific change does what it claims to do, whether it introduces a dependency the team didn’t choose, whether it quietly reaches into a system it shouldn’t touch, and whether the reasoning behind it would survive being explained out loud to someone who wasn’t in the room when it was written. That kind of judgment doesn’t compress the way generation does. A senior engineer can review faster with practice, but not ten times faster, and definitely not as fast as an agent can produce the next ten pull requests.
The result is a capacity mismatch that most organizations haven’t named yet, because it doesn’t show up as a single dramatic failure. It shows up as drift: review comments that get shorter and more perfunctory as volume rises, a reviewer who starts skimming the diff instead of reading it, “looks fine” standing in for “I checked this.” None of that is a decision anyone made. It’s what happens to a fixed-capacity task when its input volume changes and nothing about the task itself does.
Three Risks That Were Always There, Now Harder to Catch
None of what agent-authored code actually risks is new. What’s new is that the old safety net — a human reading every line before it merges — is the thing that’s failing to scale, which means these risks stop being caught by default and start requiring a deliberate system to catch them instead.
Provenance and license exposure. An agent trained on a wide corpus of public code can reproduce a pattern, a function shape, or in rarer cases something close to a verbatim block, without flagging that it came from anywhere. A human engineer writing the same code from memory carries the same theoretical risk, but in practice writes less code per hour and recognizes more of what they’re drawing on. An agent generating at volume has neither constraint. The organization that never asks where a given block of logic actually originated is the organization that finds out during due diligence, not before.
Defect ownership that nobody assigned. When a human writes a bug, the blame — fairly or not — attaches to a person, and that person can explain the reasoning that led to the mistake. When an agent writes a bug inside a change a human merged after a thirty-second skim, the reasoning doesn’t exist in a form anyone can interrogate. “The agent suggested it and it looked right” is not an incident post-mortem; it’s the absence of one. Defect ownership was never really about punishment — it’s about having someone who can explain why the system behaved the way it did, so the next instance of the same mistake gets caught earlier. Agent-authored defects quietly remove that explainability unless something was designed to preserve it.
Security holes introduced by the path of least resistance. An agent optimizing to complete a task will often find the shortest route to “done,” and the shortest route is not reliably the most secure one. A credential handled slightly too loosely, an input left unvalidated because the happy path didn’t need it, a dependency pulled in because it was the fastest way to solve a sub-problem — these are exactly the kinds of issues a careful human reviewer catches by habit, because they’ve seen the failure mode before. An agent has seen the failure mode in its training data too, but “has seen it” and “reliably avoids it under this specific task pressure” are not the same property, and nothing about agent-generated code makes that gap visible unless a system is built to surface it.
Why “Just Review It More Carefully” Doesn’t Survive Contact With Volume
The obvious answer — tell reviewers to be more careful — fails for the same reason most capacity problems resist being solved by effort alone. Asking a fixed number of reviewers to maintain fixed-quality judgment over a rising volume of changes is asking for a different outcome from the same inputs. Something gives, and it’s never announced; it’s just quietly true one review at a time until a defect, a license problem, or a security hole surfaces in a way nobody can trace back to a specific decision, because no decision was actually made. The organizations that avoid this don’t review harder. They change what gets reviewed, how, and by what — moving the bottleneck on purpose instead of discovering where it relocated after something goes wrong.
Where the Bottleneck Actually Needs to Move
Three moves show up consistently in organizations that have made this work, and none of them is “review less.”
Tier the review, don’t flatten it. Not every agent-authored change carries the same risk. A change touching authentication, payment logic, or a regulated data path deserves the full human read it would have gotten anyway. A change to an internal reporting query or a test fixture doesn’t need the same scrutiny an auth change needs, and treating them identically is how reviewer attention gets spent on the wrong things. The organizations managing this well have an explicit tiering rule, decided in advance, not inferred by whichever reviewer happens to be fastest that week.
Make provenance and risk category part of the artifact, not an afterthought. A change that touches a dependency, a credential path, or a data boundary should carry that fact with it into review — flagged automatically, not discovered by a reviewer who happens to notice. The goal isn’t to slow generation down; it’s to make the risk category of a change visible at the moment someone has to decide how carefully to read it, instead of requiring a human to reconstruct that context from scratch every time.
Assign ownership before the defect exists, not after. The team that merges an agent-authored change is the team that owns what it does in production, exactly as if a person had written it — that has to be explicit, agreed in advance, and understood by everyone merging code, not a conclusion reached for the first time during an incident review. Ownership that’s only ever discussed after something breaks isn’t ownership; it’s blame assignment with extra steps.
The Question This Reframes
The question most organizations are asking is “how do we review agent-authored code as carefully as we used to review human-authored code.” That question has no good answer, because the premise — that careful review scales with volume if people just try harder — was never true even before agents arrived. The better question is: given that review capacity is fixed and generation volume isn’t, what has to be true about which changes get full scrutiny, what risk information travels with a change automatically, and who’s accountable for what ships, for the resulting system to be trustworthy rather than merely fast. That’s not a review-process tweak. It’s a deliberate register of the risks a delivery process now carries that it didn’t carry before — which categories of change need what kind of check, and who owns the answer when one of them goes wrong. Our own AI-DLC Risk & Compliance Register exists for exactly that: a pre-seeded accounting of the risk categories this shift introduces, built to be filled in with an organization’s own answers rather than discovered one incident at a time.
What to Check Before the Next Sprint Where an Agent Writes Most of the Diff
Three questions are worth asking honestly, not rhetorically, before the volume of agent-authored code outpaces the team’s ability to answer them under pressure: Does every change already carry a visible flag for whether it touches a regulated or high-risk path, or does a reviewer have to notice that for themselves? Is there a named owner — a person, not “the team” — for what an agent-authored change does once it’s live? And if a license or provenance question came up in due diligence tomorrow, is there an actual record to point to, or would the answer be reconstructed from memory? An organization that can answer all three has moved its review bottleneck on purpose. One that can’t has simply not found out yet where it moved.