Does AI coding increase productivity? Less than the code count says.

Does AI coding increase productivity? At the firm level, yes, by much less than the code count suggests. Fiona Chen and James Stratton of Harvard studied 720,542 workers at 655 firms from January 2021 to August 2026. Twelve months after firms adopted AI agents, pull requests opened per worker were up 35.7%. Resolved Jira issues were up 13.7%, and that estimate is not statistically significant. Review is where the gain gets stuck. A Reddit thread about the paper split into people who say this matches their job and people who say it stopped being true months ago. I checked both groups against the data.

Does AI coding increase productivity? The short answer

The Reddit summary said finished releases haven’t increased at all. That is stronger than the current paper. The authors write that adoption has “much smaller effects on final software output”, which leaves room for a real gain of moderate size. If you saw “30% more code, flat output, 718 firms” in a news story, that came from the August version, with data through March. The version I read is dated October 28, 2026, and the numbers below come from that PDF.

What did the Harvard study measure?

The data comes from Jellyfish, which sells an analytics platform for engineering teams. It connects to GitHub, Jira, Google Calendar and HR systems, and to usage data for Copilot, Cursor and Claude Code. The dataset holds 445 million work events. Because firms adopted the tools at different times, the authors compare earlier and later adopters.

The study covers the whole firm after adoption, whether or not each engineer used the tool. They count Jira issues, which close when the work is deployed, and Jira epics, which mark larger features or projects. They also tested the obvious objection that issues simply got bigger, and found no evidence of that.

Some limits matter. This is a job market paper and the data is proprietary. Jellyfish has a commercial interest in this debate, although the authors say it reviewed the manuscript only for disclosure of proprietary information. Teams may also track issues less carefully once code moves faster. The authors raise that concern themselves and point to epics as the safer measure. The sample leans toward established firms, with an average of 248.9 engineers, and leaves out smaller and newer startups.

Where did the extra code go?

Into a queue. The drop-off is easiest to see stage by stage, so the figure below plots the paper’s estimates for both tool generations.

Follow the agent numbers down. Opened pull requests rise 35.7%, merged pull requests rise 26.0%, and resolved issues rise 13.7%. About 62.7% of the additional pull requests get merged, against 86.1% of pull requests at baseline. Lines of code show the biggest number, +44.0%, but that estimate is marginally insignificant. I lead with pull requests because they are the firmer result, and because a line count can reflect verbose generated code. The authors raise the same concern.

Review got slower in two ways. Code waits 59.9% longer in the backlog before review starts, which fits a capacity limit. Active review also takes 58.5% longer, which fits weaker code reaching reviewers. Pull request size did not change significantly, so bigger diffs don’t explain it. Assistants show no significant effect on any of these review measures.

Part of the reason review can’t absorb the load sits in how reviewing works. In the data, 82.8% of reviews happen in a codebase where the reviewer has already worked. Random assignment would give 17.2%. You can’t move any free engineer onto any pull request. The paper’s interviews have a junior engineer describing one senior approver who could only review their code once a week. After outages from AI-generated commits, new rules sent even more code to senior engineers.

Several people in the thread described exactly this. One said reviews are the bottleneck and that their codebase is too large and dispersed for AI reviews to do much. Another wrote about waiting weeks for dependency teams, because verifying someone else’s change isn’t their priority. The data backs them up on complexity too. In the top third of firms by repository count, time to merge rises 69.7%, against 25.4% in the bottom third. I made a similar argument from the engineering side in writing code is cheap, verifying it is the bottleneck. This paper is the large-sample version of that argument.

Is AI-generated code lower quality?

The thread fought hardest here, and the paper gives a mixed answer. Reviewers do more work per pull request: 38.6% more comments, and longer active review. The authors read that as “a decline in the quality of submitted code”. Their calibrated model estimates that agents lower review productivity by 7.0%.

Quality after shipping looks different. Jira bug reports per worker show no significant change with either tool, and the point estimates are slightly negative. The paper can’t tell you whether that is good news or whether review caught the problems at a higher cost. Both readings fit a queue where reviewers now do more of the catching.

The thread gives both sides in anecdote form. One reviewer described a 300-line, Opus 5.5 generated change for exception handling. By their account it became about 100 lines when rewritten by hand with a middleware approach, and that rewrite laid groundwork for three planned updates. A lead developer with 13 years of experience replied that they haven’t written a significant pull request by hand in about a year, and that their team hasn’t seen a notable rise in production issues, with internal rules for usage, debugging and pull requests. These two accounts can both be true. The second one comes with process attached, which is the part people skip.

One commenter asked whether you would accept a 10% drop in code quality for a 2x gain in speed. Another answered with the study: you may be getting the quality drop without the 2x. That matches the firm-level numbers, with one correction. The paper doesn’t show a 10% quality drop. That figure was the commenter’s hypothetical.

Ownership came up as well. One commenter said that with AI writing the code, people may feel less responsible for it, and another saw devs say “LGTM” to Claude and open a pull request. Another pointed out that good practice breaks down inside companies, so a method that needs discipline to beat the old way may produce worse software on average. The paper doesn’t measure ownership, so treat this as a concern from practitioners and nothing more.

Isn’t the data too old to count?

This was the most repeated objection. People said the study misses the newest models, and that the last six months changed everything. Others replied that the productive model is always the one that hasn’t been studied yet, and that this answer has followed every version of the study.

One commenter read the data as ending in 2025. The current version runs through August 2026, although commenters note that still leaves out Opus 5.5. Later data did move the result: the August version reported about 0.12 additional issues per worker-month on a 3.67 baseline, and the October version reports 13.7%. That favors the commenter who bet on measurable but modest improvement. I wouldn’t read too much into it, because the sample also changed from 718 firms to 655.

The paper also tested for improvement over time, per adopting worker. It found no clear time pattern, and the code gain per adopter stays roughly flat over the twelve months after agent adoption. The rise in the firm-level effect is explained by more people taking up the tool. The authors add two warnings: different dynamics may cancel out, and the estimates may be too noisy to show them. Neither side of the thread gets a clean win from this.

The argument over “exponential” improvement is a separate one. One side pointed to benchmarks. The other said they only judge what they get on their own work. This paper can’t settle that, because it measures firms and doesn’t test models.

Why do individual developers feel so much faster?

Because they may be. One commenter put it well: a firm-level average doesn’t contradict their own experience, and their experience doesn’t overturn the average. The numbers support that. Twelve months after agent adoption, measured take-up is 35.30% of baseline coders, and the authors treat that as a lower bound. Per adopting worker, the lines-of-code gain lies somewhere between 44.0% and 172.1%. Firms with the highest take-up see pull requests per worker rise 67.0%, against 21.4% in the lowest tercile.

The other half of the explanation is time. Engineers spend 40.8% of their time coding according to the Jellyfish signals, and 30.8% according to a survey of 100 engineers. One commenter, an engineering manager, said AI cuts the coding part by 90% and that it accentuates the strengths and weaknesses of your process. Even a huge speedup on a third of the job leaves the other two-thirds where they were.

A few people in the thread described gains this study may undercount. One said the team now takes on work that would have been declined as too much dev effort. Another said releases still run on the same cycle, and each one is more complete. A count of issues won’t catch a release that does more, although the paper did find no change in predicted issue size. Others described clearing their Jira queue faster than product can fill it. One commenter worries the work will run out, and another expects the dev to PM ratio to collapse. The paper finds no detectable employment effect so far, with noisy estimates.

Can AI review fix the bottleneck?

So far the data says no. By July 2026, 79.1% of firms had used AI tools in code review. Only 23.3% of review comments were AI-generated, and only 10.8% of pull requests received an AI comment. Humans still hold the gate, and for now that seems reasonable given what bad code costs. One senior engineer in the paper’s interviews says AI tools lack “the comprehension of the overview of the entire feature”.

AI in the review chain can also add work. One commenter said security teams run AI scanners on repos and open high-severity tickets without business context, and that this eats about 30% of their time. That is a single anecdote and the paper doesn’t measure it. It does show the risk of automating the finding step while the fixing and the exceptions stay with people. If this is your problem, I went through the capacity math for AI pull requests in a separate guide.

Is review the real bottleneck, or is it deciding what to build?

Several people in the thread said the paper’s model is too simple. One, a senior developer, wrote that the slowest part of the work is aligning on what to build and who builds it. Another said judgment limits output as much as review does. A third said AI lets people skip the questions “is this a good idea” and “does anybody actually want this”. Someone else pointed out that this is the theory of constraints: speed up one step and the next slowest one sets the pace.

The paper partly agrees. It says managers plan and scope work upstream, and it focuses on review because that is where its data is most detailed. Meeting counts didn’t change after adoption, so there is no sign of extra coordination in calendars, but that says little about how hard the decisions got.

The thread also split software from product. One commenter said coding was always about quality and scale, and that project managers value the wrong thing. Another replied that product managers care about the product and many people don’t care about the software behind it. A third cited new WordPress plugins, Chrome extensions and open source releases as proof that software is shipping. The reply was that a repo nobody uses isn’t productivity. Firm data can’t settle that either. It measures completed tickets, and a completed ticket can still be a feature nobody wanted.

Do small teams and solo developers benefit more?

The thread says yes, and this paper can’t confirm it. One commenter argued that human communication is the bottleneck, that four or more people with LLMs can’t keep up with each other, and that one person who understands the whole system can move extremely fast. That fits the review data, because a solo developer has no queue. The sample leaves out smaller and newer startups, and within the sample firm size shows no consistent difference across assistants and agents. Treat this claim as untested here.

What does the model predict next?

The authors calibrate a model to these results and run it forward. Their estimate is that agents raise coding productivity by 73.7%, and firms respond by moving labor from coding (down 22.7%) to review (up 43.4%). The next two scenarios run to 2031 and differ on one assumption.

These are simulations and depend on the model’s assumptions. They still show which question matters. Everyone in the thread argued about how good coding models are, and the paper’s largest swing comes from review. A commenter also worried about what juniors learn when seniors stop writing code. If review needs people who know the codebase, that could shrink the supply of reviewers.

So, does AI coding increase productivity?

Yes for code, and probably for finished work, by a much smaller amount. In 655 firms through August 2026, agents raised pull requests opened by 35.7% and pull requests merged by 26.0%, and the estimated rise in resolved issues was 13.7%, not statistically significant and capped at 30.7%. Review time rose 56.1%. If you run an engineering team, measure the path from pull request opened to issue resolved before you buy more seats. In my 2x post I argued the real gain is modest and depends on the system around the model, and this data points the same way. The open question is whether review can speed up as fast as coding did.