Do AI coding agents increase productivity?

They increase coding output, but not shipped software. In a Harvard working paper by Fiona Chen and James Stratton covering 718 firms, adopting AI coding agents raised lines of code by 30%, commits by 20% and pull requests by 23%. Resolved Jira issues and epics, the measure of work actually deployed, showed small positive but statistically insignificant changes, and the estimates rule out an output increase larger than 12% of the baseline. The gain was absorbed by code review.

What is the code review bottleneck?

It is what happens when AI speeds up writing code but the step after it, human review, keeps its old capacity. In the Chen and Stratton data, after firms adopted coding agents the average time to review a pull request rose 49%, the share of pull requests with changes requested nearly doubled, and comments per pull request rose 35%. Firms moved people toward review: the share of workers doing code reviews rose 14%.

AI coding assistants vs AI coding agents: what's the difference?

An AI coding assistant suggests code while a person writes it, through autocomplete or a chat window. An AI coding agent semi-autonomously completes longer tasks and submits the code itself. In the Chen and Stratton study, assistants produced small gains (12% more lines of code, 9% more commits, 5% more pull requests, with only commits statistically significant). Agents produced large ones, and they also produced the review bottleneck.

How do you find the bottleneck before rolling out AI coding agents?

Measure the whole path from issue to deployed change, not lines of code or commits. Count how many people are allowed to approve changes in each part of the codebase and how many hours a week they actually spend reviewing. Look at how long pull requests already wait for review and how often they come back with changes requested. If review is already the slowest step, more code will queue there, so add review capacity and tighten what a reviewable change looks like before adding agents.

AI coding agents raise productivity. The code review queue absorbs it.

AI coding agents do increase productivity, if productivity means code. They don’t increase shipped software, at least not yet, and not across the 718 companies in the biggest firm-level study of the question I’ve seen. The extra code goes into the review queue and waits there.

TL;DR: AI coding agents raise coding productivity by roughly a fifth to a third, but firms don’t ship measurably more software, because code review becomes the bottleneck. A Harvard working paper by Fiona Chen and James Stratton, built on Jellyfish data from 718 firms, found 30% more lines of code and 23% more pull requests after agent adoption, while resolved work stayed statistically flat and review time rose 49%. The constraint moved. It didn’t disappear.

What the study measured

The paper is “Artificial Intelligence in the Firm: Bottlenecks in Software Production,” a job market paper from Harvard. Its current version is dated 4 August 2026 and the first version January 2026. Ars Technica covered it on 9 October. It is a working paper, not a peer-reviewed publication, and it should be read that way.

The data is unusually good. Jellyfish is an engineering analytics platform, and its clients who consented to research use cover 725,938 workers across 718 firms, about 300 million work events from January 2021 to March 2026. That includes GitHub activity, Jira issues, calendar data and usage logs for GitHub Copilot, Cursor and Claude Code. The authors use a staggered difference-in-differences design: firms adopted AI tools at different times, which the authors argue mostly reflects how long procurement, security and legal approval took, and the paper compares firms before and after adoption against firms that hadn’t adopted yet.

The study separates two kinds of tools. An AI coding assistant suggests code while a person writes it. An AI coding agent completes longer tasks semi-autonomously. Take-up of agents went from near zero in October 2024 to over 95% of firms in the sample by January 2026.

The output measure is what makes it worth reading. A Jira issue gets marked resolved once the code behind it is deployed to production. An epic resolves when the whole feature does. That’s a count of finished work, not activity.

The numbers

Measure (after AI coding agent adoption)	Effect
Lines of code	+30%
Commits	+20%
Pull requests	+23%
Resolved Jira issues and epics (firm output)	Small positive, not statistically significant; rules out a gain above 12% of baseline
Average time to review a pull request	+49%
Share of pull requests with changes requested	Nearly doubles
Comments per pull request	+35%
Share of workers doing code review	+14%
Overall employment	Precise zero; rules out a decline larger than 2.9%

Assistants, the earlier generation, moved less: 12% more lines of code, 9% more commits, 5% more pull requests, with only the commits effect statistically significant. The authors also checked whether issues simply got bigger after adoption, which would hide real output growth behind a flat count. Using a model that predicts how long each issue would take to resolve, they found no effect on average issue size.

So the engineers wrote nearly a third more code, the firm shipped about the same, and headcount didn’t measurably change. Where did the 30% go?

The gain went into the review queue

Writing code is one stage of software production. Someone scopes the work first. Someone reviews and tests it after. Using the Jellyfish data and a survey of 100 engineers on Prolific, the authors estimate engineers spend 30 to 40% of their time writing code. Speed up a step that takes a third of the time, and the other two-thirds decide what ships.

Review is where it shows. Pull requests take 49% longer to get through review. Nearly twice as many come back with changes requested. Reviewers leave 35% more comments. The model in the paper explains why this isn’t only a volume problem: AI changes how much code arrives for review and also how much effort each unit of code needs to verify. More drafts, and drafts that need more checking.

One engineer the authors interviewed put it in a sentence: “there is only one bottleneck at a time.” Another described a project where a single senior engineer was the only person allowed to approve changes, and could review the interviewee’s code only once a week. No agent fixes that. It’s an approval rule, written down somewhere or not, and it sets the throughput of the whole team.

AI code review hasn’t closed the gap

The obvious response is to point AI at the review too. Firms are doing it: by March 2026, nearly 80% of firms in the sample had used AI tools in code review. But AI generated only 23.3% of review comments, and only 10.8% of pull requests got even one AI-generated comment. The bottleneck persisted after firms adopted AI code review tools. Humans still do the part that matters, which is deciding whether a change is safe to merge into a codebase they’re accountable for.

That isn’t a tooling failure. It’s the same pattern I wrote about in human-in-the-loop approval: the reviewer’s attention is fixed, and the arrival rate is what changed. Adding a second machine in front of the human doesn’t change who signs off.

This isn’t a software story

Software is one of the few places anyone can measure it this cleanly, because every step leaves a timestamp in GitHub or Jira.

The same shape shows up everywhere AI gets applied to one station of a multi-step process. An AI drafts claim decisions faster, and the adjuster’s approval queue grows. An agent codes invoices faster, and the exceptions pile up with the one AP specialist who can resolve a three-way match. An AI drafts RFIs in a click, and the architect or engineer who has to answer them gets a longer queue, which is why construction RFI automation made RFIs cheap to write, not cheap to answer. Agents amplify what’s already there, including the queue.

The paper’s own conclusion for managers says it plainly: measuring returns to AI means evaluating the entire production process, and changing one stage may shift the bottleneck to another. That’s an operations finding, and it’s older than AI. Find the constraint first. Then decide whether speeding up anything else is worth paying for.

What to do before you roll out coding agents

Most of this is measurement and rules, not tooling.

Stop reporting lines of code, commits and pull request counts as the return on AI. They went up 20 to 30% in this study while finished work didn’t move. Report issues resolved in production, and cycle time from issue opened to change deployed.

Measure review capacity like you’d measure any other station. How many people can approve changes to each part of the codebase? Check the CODEOWNERS file. A billing module with one listed owner is a single-server queue, and it’ll be the first thing agents saturate. How many hours a week do those people actually review, and how long do pull requests already wait?

Then change the inputs to review before you increase them. Set a size limit on what an agent can submit as one pull request. Require tests that state what the change is supposed to do, so the reviewer checks a contract instead of reading every line. Decide in writing which kinds of changes can merge on automated checks and which need a named human. Those are process decisions, and they’re the ones the study’s firms were making reactively, by moving 14% more of their people into review.

That’s the order workflow redesign before AI agents argues for in general. Coding agents are just the case with the best data.

The operator read

Same engineers. Same review rules. A third more code. The firms in this study got exactly what that setup produces: a longer queue in front of the same approvers. The fix isn’t a better model or a second AI reviewer. It’s knowing which step is the constraint, and redesigning that step before you flood it. That mapping is where my process and automation work usually starts. If your team adopted coding agents and your delivery dates haven’t moved, that’s worth a conversation.