Agents write 30% more code. Finished work did not grow

What was measured

Fiona Chen and James Stratton of Harvard worked with data from an engineering analytics platform: roughly 300 million work events from about 700,000 people across 718 firms, from January 2021 to March 2026. It covers GitHub activity, Jira issues and calendars.

The method is a staggered difference-in-differences design, using the fact that firms adopted these tools at different times. So the comparison is the same firm before and after, against firms that adopted nothing in that window.

The study keeps apart two things that usually get merged in conversation: assistants (Copilot and the like, completing code as you type) and agents (given a task, opening a pull request on their own). The numbers below differ by which one is meant.

Code went up

Measure	Agents	Assistants
Lines of code	+30%	+12%
Commits	+20%	+9%
Pull requests	+23%	+5%

For agents all three increases are statistically significant. For assistants only the middle one is; the rest cannot be reliably told apart from zero.

That is the part that gets quoted. Now the other one.

Finished work did not

As output, meaning finished work, the study takes resolved Jira issues and, above them, epics — whole features and projects. Neither shows a significant effect, for agents or for assistants.

On its own that proves little, since "we found no effect" can also mean "the measurement was too coarse". So the authors state what their data rules out: for agents, the confidence interval rules out an increase in output larger than 12% of the baseline. Even if some effect exists, it is far below the 30% rise in code volume.

You might think the mix of tasks changed — that people took on bigger things and a count of issues would not show it. The authors tested that with two measures of issue size and it did not hold.

Where the bottleneck moved

This part interests us most, because it does not merely say "nothing improved" — it shows where the work went.

• Time from pull request to merge: +49%. On a baseline of 7.03 days, 3.45 days were added. For assistants it did not change.
• Sent back for changes: nearly double. The share of pull requests where review requested changes roughly doubled from a baseline of 0.13.
• Comments per pull request: +35%. On a baseline of 1.66, another 0.58 comments per pull request.
• People doing reviews: +14%. Firms moved part of their staff from writing to reviewing.

Together that is a picture familiar to anyone who has reviewed someone else's code in a hurry: writing sped up, checking did not, and a queue forms in between.

Speeding up one step of a production line raises output only if that step was the bottleneck. Otherwise the queue just moves one step along.

What follows for us

Let us be precise, because it is easy to read this study as confirming something it does not say.

It did not measure a review gate. It measured agents that write code and what happens to them in review. An agent that writes nothing and only watches the diff was not observed here. So what we wrote in the previous article still holds: for that specific role we have no measured data.

What the study does give is a measurement of the problem we recommend that role for. When review is the bottleneck, starting by sending more material into it is an odd plan. Starting at the other end is the sensible one.

The second thing we take from it: if the return on agents can be shown anywhere, it is here. Cutting one day from review for a team merging fifty pull requests a month is a calculable saving. Writing 30% faster is not, if finished work does not move.

What limits the study

A few things need saying out loud, or this would look stronger than it is.

• It is a working paper, not yet peer reviewed. The version we read is dated 4 August 2026, the first one January 2026.
• Adoption is measured at firm level, not per person. The authors say themselves this likely lowers the estimates, since people who never used the tool are in the average.
• Output is measured through Jira. A resolved issue is a weak stand-in for delivered value. A firm that runs Jira differently would come out differently.
• The data comes from one platform and only from firms that agreed to its research use.

None of that voids the numbers. It means they can carry an argument, not a certainty.

What to do with it

If agents write code for you and you see no more finished work at the end, this study says you are not alone and suggests where to look. Measure two numbers you already have in your own repository: median time from pull request to merge and the share of pull requests sent back for changes. If both grew after you adopted agents, you have the same problem as the average in that study, and the answer is not another agent that writes.

We build and run our own systems, so we know these queues from both sides. The rest of the group is at independency.cz.

Source

Fiona Chen, James Stratton: Artificial Intelligence in the Firm: Bottlenecks in Software Production, Harvard University, version of 4 August 2026. The figures here are taken from the paper itself, not from secondary coverage.