If your team works with coding agents, it almost certainly writes more code. The question you will be asked at the next budget review is a different one: does it deliver more?
This insight argues a point that makes both camps uncomfortable: if the team writes more code and delivers the same, review is not the problem, it is where the problem shows. Review receives work that nobody defined beforehand, and the reviewer has to reconstruct what was wanted before being able to approve it. Reviewing faster, or not reviewing at all, only moves the bottleneck into production.
What the 718-firm study found
Fiona Chen, of Harvard University, and James Stratton have studied 300 million work events across 718 firms with a staggered difference-in-differences design: they compare how each firm evolves before and after adopting AI coding assistants and agents, using the fact that each one adopted them at a different time. Their abstract says three things:
- Both technologies, assistants and agents, increase coding productivity.
- That gain does not fully pass through to software output or to employment.
- For agents, the shortfall is explained by a code review bottleneck: reviews take longer, more changes need revisions and each review receives more comments.
Put another way: the code is written sooner, but it waits longer to get in.
Risk It is an academic paper in its August 2026 version and there is no indication that it has been peer reviewed. We have not been able to read the full text: we only cite what the public abstract on the author's website says, and we give no percentages from the study. The study does not say AI is useless; it says where part of what it brings gets lost.
Not the first time this has been seen
Faros AI, a company that sells engineering analytics, published a report in July 2025 with telemetry from over 10,000 developers across 1,255 teams. In teams with high AI adoption it found this:
Above all, it observed no significant correlation between AI adoption and improvements at the company level. This is vendor data, with the bias of its own customer base, but it points to the same place as the Harvard study using a different method and different data: volume rises much more than what comes out the other side.
A correction to what we wrote before
In reviewing AI-generated code we argued that review is almost never a team's throughput constraint, and that if you want to deliver sooner you should look at deployment. With agents, the 718-firm study says otherwise: review is indeed where the gain gets stuck. We say so here so that one insight is not read against the other.
Our reading, and this is no longer the study's, is that both ideas fit once you look at what review receives. When an agent produces a large change from a vague request, the reviewer has nothing to compare it against. They have to guess what was wanted, read the whole thing and argue it out in comments. That explains longer reviews, more revisions and more comments. The bottleneck shows up in review, but it is built earlier.
A fast review is not one that reads quickly. It is one that compares the change with something written before the code.
What reaches review and how to change it
Each of the three signals the study describes has a likely cause before the review. The table is ours, not the study's:
| What shows up in review | Likely cause before review | What to change |
|---|---|---|
| Reviews take longer | Large changes that mix several things | Small batches: one change, one purpose |
| More changes need revisions | What the change had to meet was not written down | Acceptance criteria written before the code |
| More comments per review | The reviewer also checks the mechanical part: style, missing tests, conventions | An automated check on every change before human review |
onext's own work, based on the three signals described in Chen and Stratton's abstract (2026)
The first row has independent support. In its capabilities model for teams using AI, DORA says that working in small batches amplifies the positive influence of AI on product performance and reduces friction for development teams.
The second is the basis of Spec-Driven Development (SDD): what has to be met is written first, so the review becomes a comparison. We explain it in Spec-Driven Development with AI, along with how those criteria become the merge gate.
The third leaves to the person what only a person can do: judge intent, design and risk. Where the risk is high, a person decides. These are the same practices that protect stability, as we explain in with AI your team ships faster, but not more stable; here we look at them from the reviewer's seat. And approving without being able to explain what was approved has a cost that arrives later: comprehension debt.
What to say when you are asked about the budget
If the team measures lines of code, commits or pull requests, AI almost always wins, which is why those numbers do not answer the question. What answers it is resolved work reaching production, compared with what the team delivered before agents. Next to it, two numbers that show where the difference is lost: how long a change takes from requesting review to being merged, and how many come back with revisions.
Which indicators to choose is in KPIs for AI development teams, and how to frame the spend as a bet that can be checked, in the value thesis worth asking of the team. If changes pile up waiting for review, buying more licences does not speed up delivery on its own: it adds queue.
If you can only change one thing this quarter, make it this: no change from the agent reaches review without acceptance criteria written beforehand. In our view, it is what most reduces the guessing in review, and it is the starting point of the safety net worth building before the agent.
A second look
If you want to see with someone from outside where your team's work stalls today between the agent and production, the diagnostic is free, and if the diagnostic shows no difference, there is no Quick-start. What the rest of the path looks like is in AI-Accelerated Development.
Frequently asked questions
Do coding agents increase a development team's productivity?
When writing code, yes. Fiona Chen and James Stratton's study with data from 718 firms concludes that AI coding assistants and agents increase coding productivity. What it does not find is that this gain carries through in full to the software delivered or to employment. The useful question is not whether the team codes more, but whether it delivers more.
Where is the gain from coding agents lost?
According to the study's abstract, for agents the shortfall is explained by a code review bottleneck: reviews take longer, more changes need revisions and each review receives more comments. The code is written sooner, but it waits longer to get in.
Should we review faster, or stop reviewing the agent's code?
Neither. Reviewing the same thing faster turns review into a formality, and not reviewing moves the problem into production. What we propose is changing what reaches review: small changes, with acceptance criteria written before the code and with the mechanical part already checked by continuous integration.
Why is code generated by an agent harder to review?
Because the reviewer often has nothing to compare it against. If what the change was supposed to do is not written down anywhere, the reviewer first has to reconstruct the intent and only then judge the code. This is onext's reading of the bottleneck the study describes, not a conclusion of the study.
What should we measure to know whether AI improves delivery?
Resolved work that reaches production, not lines of code or pull requests. Alongside it, how long a change takes from requesting review to being merged, and how many come back with revisions. If you only measure lines or pull requests, AI almost always seems to win.
How reliable is the 718-firm study?
It is a recent academic paper by Fiona Chen, of Harvard University, and James Stratton (August 2026 version) with 300 million work events and a staggered difference-in-differences design, but there is no indication that it has been peer reviewed. In this insight we only cite what its public abstract says and we give no percentages we have not been able to read in the original.
Sources
- Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production", August 2026 version. Abstract on Fiona Chen's website (Harvard University), accessed 24 October 2026; the full text could not be read.
- Faros AI, "The AI Productivity Paradox Report 2025", 23 July 2025 (over 10,000 developers across 1,255 teams).
- Kevin M. Storer and Derek DeBellis, "Introducing the DORA AI Capabilities Model", Google Cloud Blog, 23 September 2025.
- The reading of the bottleneck, the table and the way of measuring are onext's own work.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →