You check Slack on a Tuesday morning. It’s 8:47am. Five AI coding agents ran overnight tasks. There are 23 new pull requests waiting. Every single one has a green CI badge. The timer on two of them says “merged 4 hours ago.” No review comments. Just a thumbs-up emoji from one teammate, timestamped 4:12am, before they went to bed.
You click into one. It’s 340 lines across 11 files. It passes all the tests. The agent followed the ticket to the letter.
And you have no idea if it’s actually right.
The Fleet Gets Bigger. The Humans Don’t.
For most teams, the move to AI coding agents followed a predictable arc. One developer starts using Cursor or Claude Code to write boilerplate faster. Then the whole team adopts it. Then someone on leadership notices the velocity numbers and suggests running agents in parallel, overnight, for the repetitive tasks. Two agents become five. Five become ten.
The output goes up. The number of engineers does not.
Here is what the research says is actually happening at teams running high volumes of AI-generated code. Faros AI studied 1,255 development teams with over 10,000 developers. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. That sounds like a win.
PR review time also rose 91%. And 31% of PRs merged with no human review at all.
That last number is the one nobody puts in the board deck.
What 400 Lines Per Hour Looks Like in Practice
A competent human reviewer processes roughly 400 lines of code per hour, and attention degrades sharply after about 60 minutes of focused review. That is not an opinion. That is a cognitive load constraint backed by software engineering research going back decades.
Your five overnight agents can produce somewhere between 500 and 2,500 lines of code. In a single night. Across however many PRs they felt like opening.
Which means a single developer showing up to review the previous night’s agent work is immediately behind before they have opened their laptop. If they read carefully, they might get through two PRs before the morning standup. The other 21 get a skim, or a “LGTM”, or a merge because the tests passed and nobody wants to be the bottleneck.
This is not a failure of individual developers. It is an arithmetic problem. And the teams that solve it as a discipline problem rather than a structural one are the ones that end up with production incidents they cannot trace.
Approval Theater Is Quiet
The thing about review slipping is that it doesn’t announce itself. The repo stays green. The CI passes. The sprint velocity looks great. Everyone technically “reviewed” everything, if you count opening a PR and scrolling through it in thirty seconds.
What you lose, quietly, is the thing code review was always actually for. Not formatting. Not test coverage. Those are automated. Code review is for the moment a human notices that the agent correctly implemented the ticket but the ticket was wrong. Or that the function now works in isolation but breaks a contract four layers up. Or that this is the third time a similar pattern appeared in the codebase and someone should probably write a utility instead.
An agent cannot spot those things reliably. A tired developer racing through twelve PRs at 9am cannot spot them either. The only person who catches them is a reviewer with enough context, time, and care to actually read what changed and think about it.
When you scale to ten agents and two reviewers, you don’t have two reviewers anymore. You have two people signing off.
There is also something specific happening to ownership. When a human writes a feature, there is a person who understands it. When five agents write five features overnight, nobody understood any of them deeply. The reviewer glanced. The agent is not on-call. Six weeks later, when that feature breaks at 2am, the first question in the incident channel is “who wrote this?” And the honest answer is: nobody, really. The agent wrote it, someone approved it, and nobody owns it.
The Bottleneck Moved, Not Disappeared
The interesting thing about this failure mode is that it was predictable. The logic was there.
AI generation is fast. Human review is slow and linear. If you scale one without scaling the other, you will hit a ceiling. The ceiling just isn’t visible in the usual productivity metrics, because every number you track improves right up until the incident.
Velocity? Up. Features shipped? Up. Open bug count? Fine. Then something breaks in production at 11pm on a Friday. You trace it back through the logs. It’s a service that was modified three weeks ago in a PR that got one comment: “looks good.”
LinearB studied 4,800 teams and 8.1 million pull requests and found that AI-generated code waits 4.6 times longer for review than human-written code. That wait exists because reviewers, consciously or not, know that AI-generated code requires more scrutiny. It often passes the obvious checks while doing something unexpected in the edge cases. So they push the review to later. And later becomes “let’s just merge it, we need to ship.”
The 4.6x wait is the system trying to signal something. The 31% no-review merge rate is what happens when the signal gets ignored long enough.
The Fix Is Not More Reviewers
More reviewers helps, but it misses the structural point. The structural point is that your team’s effective throughput is not how many PRs your agents can open. It is how many PRs your humans can actually review, carefully, in a given sprint.
If that number is eight per day across your team, then running 20 agents and generating 40 PRs does not give you 40 features. It gives you eight reviewed features and 32 gambles.
The teams getting this right are the ones who size their agent fleet to their review capacity rather than to the limit of what they can spin up. They set limits on how many parallel agents run at once. They assign PRs to specific reviewers with explicit context, not just “whoever is available.” They treat unreviewed PRs as open work, not complete work, and they count them in their WIP limits.
Some teams are going further and building what amounts to a review layer into their agentic workflow: a secondary agent pass that flags potential issues before the PR reaches a human, reducing the cognitive load at review time. This can help. But it introduces its own failure mode, because trusting an agent to review another agent’s work still requires a human to understand what the reviewing agent flagged and why. You have not removed the judgment step. You have just moved it.
Our work at Agively on AI-powered development consistently shows that the teams shipping well with AI agents are not the ones running the most agents. They are the ones who have thought carefully about where human judgment is irreplaceable and built their process to protect that step.
What Good Actually Looks Like
The workflow automation isn’t the problem. Generation capacity isn’t the problem. The problem is treating automation as a reason to reduce the quality of human oversight rather than a reason to direct it more carefully.
A team running three agents with strong review discipline will consistently outperform a team running ten agents with approval theater. Not because they ship more features. Because they ship features that hold.
The specific work looks like this: you cap parallel agents at the number your team can review in a day. You make review assignments explicit, not optional. You build in a standing question before any PR merges – “did a human who understands this system actually look at this?” – and you make the answer checkable, not assumed.
If you are considering bringing in additional engineering capacity to manage an agentic workflow at scale, the right framing for that resource is not “more generation capacity.” It is “more qualified review capacity.” Generation is cheap now. Understanding what was generated is still expensive in human time, and it always will be.
The number you should be tracking is not PRs merged. It is reviewed PRs merged. If those two numbers have drifted far apart, you already know what the next production incident is going to feel like.
You just don’t know yet which PR it came from.