When review throughput becomes the bottleneck AI just created

A VP of engineering at a media company told me their adoption of AI coding tools went great for about a month, and then the pull-request queue started backing up in a way it never had. Individual engineers were producing more changes, faster, and they were happy about it. But the changes piled up waiting for review, because review had not gotten any faster. The same senior people were still reading every diff, and now there were far more diffs, each one arriving with less context because the author had spent less time in the code. The bottleneck had not disappeared. It had moved to the few people whose attention could not be multiplied.

Production sped up, verification did not

AI coding tools accelerate one specific part of the pipeline, the writing. They do very little for the parts that depend on human judgment, and review is the biggest of those. A reviewer still has to load the change into their head, follow the logic, and decide whether to trust it. That work takes the time it takes, and it does not shrink because the code was generated quickly.

So the shape of the pipeline changes. Before, writing and reviewing were roughly balanced, and a team’s throughput was limited by both. After, writing is cheap and review is not, which means review becomes the single constraint on how much the team can actually ship. You can generate ten changes in the time it used to take to write three, but if your senior engineers can only review three well, the other seven sit in a queue, aging, accumulating merge conflicts, losing the context that was fresh when they were written.

There is a second, quieter effect. Because the author spent less time in the code, they carry it less well, so the reviewer has to supply more of the understanding. Each review costs more attention than it used to, at exactly the moment there are more of them. The team feels faster and ships slower, and nobody can quite say why, because everyone is busier than ever.

Rebalance around the new constraint

The lesson is that a team adopting AI coding tools has to treat review capacity as the thing that now limits throughput, and manage it deliberately. Producing more code that cannot be reviewed is not velocity. It is inventory.

What teams do when review becomes the bottleneck.

Keep changes small, so each review is cheap and the queue moves, rather than letting agents produce large diffs that clog it.
Spread review load beyond the two senior people, and grow more reviewers, since review is now the scarce resource.
Ask authors to carry their changes well enough to explain them, so the reviewer is not reconstructing understanding from scratch.
Measure the pipeline end to end, including time in review, so the queue that forms after the keyboard is visible.
Resist the temptation to loosen review to clear the backlog, because a fast queue of weak reviews is the expensive kind of fast.

The tool gave you more supply. Your constraint is now demand for review attention, and you cannot generate that the way you generate code.

How we think about it at Density Labs

When a team tells us AI tools made them faster but somehow things feel stuck, we almost always find the jam in review. The writing got cheap, the reviewing did not, and nobody rebalanced. The senior engineers who were the constraint before are still the constraint, only now they are drowning, because the tool multiplied everything upstream of them and nothing about them.

We help teams design the workflow around the real bottleneck instead of the one they used to have. Sometimes that means smaller changes, sometimes more reviewers, sometimes a hard look at whether all that extra code was worth generating. The goal is a pipeline where the speed at the keyboard actually reaches production, instead of pooling in a queue in front of the people who have to understand it.

Writing code faster only helps if someone can still review it. Otherwise you built a faster way to make a longer line.