More Code Is Not More Software: Review Is the Bottleneck
A Harvard study of 718 firms found that adopting AI agents increased code by 30% but didn't increase finished work. What to do when the bottleneck moves to review.
A Harvard study of 718 firms found that adopting AI agents increased code by 30% but didn't increase finished work. What to do when the bottleneck moves to review.
A recent Harvard working paper put a number on something many engineering teams already suspected. Economists Fiona Chen and James Stratton combined data from the Jellyfish analytics platform with GitHub activity across 718 software firms: roughly 300 million work events, more than 700,000 people, from January 2021 through March 2026. The result: after adopting AI coding agents, lines of code per worker rose about 30%, commits about 20%, and pull requests about 23%. The number of finished issues and epics showed no statistically significant increase.
If teams produce more code and more pull requests, you would expect them to resolve more problems. The fact that this is not happening forces the question of where that extra volume of work is going.
It is worth being precise about what was measured: the study counts resolved Jira issues as finished work, and an issue counts as complete once its code is deployed to production. This is not a measure of activity but of delivery.
The most consistent answer is simple: a team’s capacity to review code with judgment did not grow at the same rate as AI-assisted code generation. More lines and more pull requests do not automatically mean more delivered value if every one of those changes still has to be read, understood and validated by a person.
The study measured this in detail, and the numbers on the far side of the funnel are as telling as the generation figures: average pull request review time rose 49%, comments per PR rose 53%, and the share of pull requests requiring changes doubled. The share of people doing reviews grew only 14%. The extra work did not disappear — it piled up in the review queue.
There is a structural reason why reviewing agent-generated code costs more than reviewing a colleague’s. When you review a teammate, you can assume they understood the problem, tested the obvious edge cases, and wrote something that reflects an intent. With an agent’s output, all of that has to be verified from scratch: whether it solves the stated problem, whether it introduced a subtle security flaw, whether it duplicates logic that already exists elsewhere, and whether it follows the team’s conventions closely enough not to become a maintenance burden six months from now.
The natural reaction is to look for an AI-assisted review tool. The study anticipates that move with its most uncomfortable figure: by March 2026, 80% of the firms analyzed already had AI review tooling in place, and even so only 23% of review comments were AI-generated.
Put differently: companies already bought the solution and the bottleneck is still there. Review capacity with judgment is not acquired through a license; it is built with practices, allocated time, and people who know the system.
For engineering teams already using AI agents day to day, some concrete recommendations: measure business and quality outcomes, not volume of generated code; add static analysis targeted specifically at AI-produced code; and set differentiated review rules for agent-originated pull requests, focused more on understanding the why behind each change than on approving quickly.
To that, add an allocation decision the study hands you: if the real constraint is review capacity, buying more generation seats does not improve delivery. What improves it is assigning senior time to review, and treating that capacity as part of the adoption project rather than a cost that absorbs itself.
The conclusion is not to stop using AI to generate code, but to understand that the bottleneck has moved: it is no longer in writing; it is in reviewing with judgment. Teams that invest in strengthening that capacity will get more real value from AI than those that only measure how much code gets produced.
The finding deserves a precise reading: no statistically significant increase is not the same as no gain at all. What the data rules out are large improvements, of the 20% to 30% order visible in code activity. The margin that remains is far smaller than the tooling promises, and that is the point.
At Sagant, we support engineering teams through this kind of mature AI adoption, focused on solid review processes rather than generation speed alone.
