AI Didn’t Remove Your Bottleneck, It Moved It to Code Review

Two founders, same call, same admission: their open pull request count tripled once AI started writing the code.

Neither of them ran out of code. They ran out of people to look at it.

This is the part of the AI coding story that doesn’t make it into the demos. The bottleneck didn’t disappear when agents started writing pull requests, it moved. Writing code got faster. Reviewing it didn’t. So the queue grows, and the queue is where the risk lives.

More software is shipped, so more bugs are shipped too. That’s not a hypothetical — it’s the direct consequence of generation speed outrunning review capacity, and it’s worth asking whether some of the downtime you’re seeing lately on sites you rely on has this shape.

The harder problem is that review isn’t just “the same work, more of it.“ It suits a different kind of person than creation does. Someone has to decide whether a rule an agent suggested adding to memory is actually correct, and revisit the ones that got blanket-approved early “because it was cool and nice“ — decisions that experience later contradicts once the code has moved somewhere else.

And there’s a hard ceiling on how many open agent tasks one person can actually track. Which means the fix isn’t more agents writing more code. It’s the same coordination problem teams have always had when they scale past what one person can hold in their head — you need something playing the team lead role, watching for health and quality across all those open flows. It might be a person. It might, increasingly, be another agent.

Either way, that’s a system redesign, not a productivity upgrade. Teams that just keep adding agents without adding a way to monitor what’s piling up aren’t shipping faster. They’re accumulating risk faster.

One solution we’ve seen to fix this is to use risk based review strategies. Parts of the code that are low risk: agent can submit without review. High risk part require two humans to review and sign off.