AI Coding Agents Productivity: 30% More Code, 0 More Shipped

Here is the headline from the biggest real-world study of AI coding agents ever run: after firms adopted tools like Claude Code, Cursor, and Devin, each developer produced 30% more code — roughly 1,500 extra lines per worker per month — yet the amount of finished software shipped did not move. The study rules out any output gain above 12%. If you have been wondering why your team feels busier but your release cadence looks the same, this is the most credible answer yet. The full story of the AI coding agents productivity gap is not about lazy developers or bad tools. It is about where the extra code goes once it leaves the editor: it piles up in code review.

Table of Contents

What the study actually measured

The paper is Artificial Intelligence in the Firm: Bottlenecks in Software Production, by Harvard economists Fiona Chen and James Stratton — a working paper (current version dated 4 August 2026) that was picked up by Ars Technica on 9 October. The data comes from Jellyfish, an engineering-analytics platform, and it is unusually rich:

718 software firms and 725,938 workers
~300 million work events: GitHub commits and pull requests plus Jira issues and epics
Observation window: January 2021 to March 2026
A staggered difference-in-differences design: firms adopted AI tools at different times, so the authors can compare before-and-after shifts while controlling for broader trends

Crucially, the authors distinguish two generations of tooling. AI coding assistants — autocomplete-style tools — raised lines of code by about 12%, with only the effect on commits reaching statistical significance. Fully agentic tools — which write and submit code with less human direction — are the ones that produce the headline numbers.

The headline numbers

Metric	Change after agent adoption	What it measures
Lines of code	+30%	Code generated per worker per month
Commits	+20%	Discrete changes pushed to version control
Pull requests opened	+23%	Changes submitted for review
Resolved Jira issues / epics	No significant change (gains above 12% ruled out)	The study’s proxy for shipped software
Overall employment	No significant change (cross-checked against LinkedIn data)	Headcount at adopting firms

Read the first three rows, then the fourth. That disconnect is the entire finding: more code entered the pipeline, but the rate at which work got marked done stayed flat. Size and complexity of the tickets did not change either, so teams were not simply closing smaller tasks.

Where the productivity actually went: the review bottleneck

The authors trace the missing productivity to one stage of the pipeline. After agent adoption:

Time from PR submission to merge rose 49% — about 3.45 days on average
The share of PRs sent back for changes nearly doubled
Comments per PR rose 35%
The share of workers doing code review rose 14% — firms literally reassigned people to soak up the review load

And the bottleneck held even where firms had already automated part of review: by March 2026, 80% of firms were running some form of AI code review, yet only 23.3% of review comments were AI-generated. Humans kept the final sign-off.

The authors put the diagnosis in unusually blunt terms: “Both technologies increase coding productivity. However, productivity gains do not fully pass through to changes in software output or employment.” Their prescription is just as direct: “Realizing the benefits of AI adoption requires complementary investments in downstream review capacity, rather than simply increasing code output.”

To corroborate the telemetry, the researchers interviewed 21 developers, product managers, and engineering leads. The pattern came through in human words too: engineers described how routine work gets a fast, mostly-correct draft from an agent, while the harder tasks generate more mistakes — and then the review time eats whatever the generation saved. One junior engineer summed it up as: commits can be made quickly, but code review was still the bottleneck.

What the study does not say

Before you forward this to your CTO, the caveats matter:

It is observational, not a randomized trial. It does not prove AI caused every change; it shows the before-and-after pattern across 718 firms.
The data ends in March 2026. Agent releases since then — and the review tooling catching up — are not in the dataset.
The 49% is elapsed submit-to-merge time, not 49% more active reviewing. Waiting in the queue counts the same as being read.
It does not show AI-generated code is worse. The paper reports no claim that agent-written code has more defects — the bottleneck is capacity, not necessarily quality.
Nobody got fired. There is “a precise zero effect on overall employment” — the gains went to review, not to layoffs.

None of this weakens the practical message. It sharpens it: the constraint moved, and most teams still manage as if generation were the scarce resource.

A second study says the same thing, louder

The Harvard paper is not alone. A developer-level study, Writing Code vs. Shipping Code by Mert Demirer (MIT), Leon Musolff (Wharton), and Liyuan Yang, tracked hundreds of thousands of GitHub developers across successive waves of AI tooling. It found the largest coding-activity gains for fully autonomous agents — then watched those gains attenuate across production stages: a huge lift in raw coding activity shrank step by step through commits and releases until little was left at the shipped end.

Worth knowing about that one: two of its three authors are disclosed as paid research consultants for Microsoft, which sells the Copilot tools it studies. That does not invalidate the work — the finding cuts against the AI-sells-itself narrative — but it is a disclosed interest you should hold in mind when you cite it.

Vendor data rhymes with the academics. LinearB’s 2026 benchmarks (vendor-reported, so treat as directional) found AI-generated PRs wait 4.6x longer before a human picks them up — but once picked up, they get reviewed 2x faster than manual work. The expensive part is not the reading. It is the waiting.

5 things to do about it this week

You do not need a new platform or a bigger budget. You need to move the bottleneck you actually have. Here is the practical response, sized for a small team:

1. Cap PR size — agents obey it if you tell them

Big AI diffs are where review dies. Set a rule: no PR over ~200 lines without splitting, and put the rule in the agent’s own instructions. Add this to your CLAUDE.md or agent rules file:

// Add to your agent instructions (CLAUDE.md / AGENTS.md / .muserules)
When producing code, split work into reviewable pull requests:
- Max ~200 changed lines per PR; split anything larger
- One logical change per PR; do not mix refactors with features
- Run tests and the linter before opening the PR
- Summarize the diff in the PR body: what changed, why, what you did NOT change

Smaller diffs get picked up faster and revised less. This one habit attacks the 49% directly.

2. Measure the wait separately from the review

Split your PR metrics into time-to-first-review and time-in-review. Most teams discover the queue is the problem, not the reading — and queueing is fixable with reviewer rotation and review office hours, not with faster models. If you use Jellyfish, LinearB, or GitHub’s built-in insights, the split is already in the data.

3. Put AI on the review side too — but make it earn trust

The study found AI review tools had only a marginal effect so far, largely because humans kept final sign-off and early tools were noisy. The fix is not a louder bot; it is a quieter one: run AI review on every PR as a first pass that only comments when it has verified a finding, keep the human as the merge authority, and track the false-positive rate as the metric that decides whether the bot survives. False positives are what get review bots muted — a pipeline that keeps them under ~6% is one engineers will actually read.

4. Write prompts for review-readiness, not just code

Every extra revision round is a round trip through the bottleneck. The patterns that make AI output cheaper to review — focused passes, adversarial self-checks, explicit stack context — are the same prompting patterns that catch bugs earlier. If you want the playbook, start with our guide to AI code-review prompts: seven copy-paste patterns designed so the code arrives closer to merge-ready.

5. Budget review capacity like headcount, not leftovers

The 14% of workers pulled into review in the study did not volunteer. Plan for it: name reviewers in CODEOWNERS, protect review time in the sprint, and treat “the queue is growing” as an incident worth paging on. If you are buying more agent seats, pair each purchase with an honest question — who is going to read what it writes? If you want a current read on which models produce the most review-friendly output, see our benchmark breakdown.

The takeaway

Your coding agent is not slow. It is fast — roughly 30%-more-code fast. The problem is that your pipeline was built for human-paced generation, and the scarcer resource now is judgement about what should ship. The teams that win this round will not be the ones with the most agent seats. They will be the ones that stopped optimizing the writing and started optimizing the reviewing.

Date-stamped: facts and figures in this post were verified against the original working paper and reporting on 13 October 2026. The paper is a working paper and figures may be revised in later versions.

AI Coding Agents Productivity: 30% More Code, Zero More Shipped (2026)