Harvard Study of 718 Firms: AI Coding Agents Added 30% More Code and 49% Longer Reviews. Issues Resolved Showed No Significant Change.

Firms that adopted AI coding agents wrote about 30% more lines of code per worker and opened about 23% more pull requests, according to a Harvard working paper released in August 2026. They also waited 3.45 days longer for each pull request to be reviewed and merged, a 49% increase on a baseline of 7.03 days. The number of Jira issues each worker resolved did not change by an amount the authors could distinguish from zero. The paper, by Fiona Chen and James Stratton, is a job-market paper that has not been peer reviewed, and it is worth reading closely because the pattern it reports is a pipeline pattern: more input at the coding stage, and a slower stage further downstream.

What the paper measured

The paper, titled 'Artificial Intelligence in the Firm: Bottlenecks in Software Production', uses data from Jellyfish, an engineering analytics platform, covering 718 firms and 725,938 workers between January 2021 and March 2026, roughly 300 million work events. It links commits, pull requests, Jira issues and code review activity at the firm and month level. The data partner reviewed the manuscript only to check for proprietary disclosures, not for scientific content, a detail the authors state themselves. Firms in the sample are not a random draw: they are Jellyfish customers who consented to the research, with an average of about 1,650 workers and 241 active engineers in January 2023.

The design is a staggered difference-in-differences event study. Each firm is treated at the month it first shows a signal of adopting a tool, and its later outcomes are compared with firms that had not yet adopted. The paper separates two kinds of tools. Assistants, meaning GitHub Copilot and Cursor, offer suggestions inside the editor and do not act on their own. Agents, meaning Cursor Agent, Claude Code and similar tools, take a high-level task, plan multi-step work across files, run tests and hand the result to a human to review. The agent coefficient is the effect beyond whatever assistants already did. That distinction matters because the two tools move different parts of the pipeline.

Where the extra code went

For agents, the paper's pooled estimates (baseline in brackets) are: lines of code added per worker-month up 1,494 (from 5,017), about 30%; commits up 4.57 (from 22.58), about 20%; and pull requests up 1.22 (from 5.34), about 23%. Pull request size did not change significantly, at 1,168 lines on average before and a change of minus 68 lines with a standard error of 127. So the extra output arrived as more pull requests of similar size, not as bigger ones.

Each of those pull requests needs a human reader, and the review measures all moved the wrong way. Review time, from submission to merge, rose by 3.45 days (standard error 1.60) from 7.03 days. Review comments per pull request rose by 0.58 (from 1.66), about 35%. The share of pull requests where reviewers requested changes rose from 0.13 to roughly 0.25, nearly doubling. The share of workers who do any reviewing rose by 4 percentage points from 29%, about 14%.

A comparison the headline coverage did not make: pull requests per worker rose 23% while the share of workers reviewing rose 14%. Dividing the baseline 5.34 pull requests per worker by the 0.29 reviewing share gives about 18.4 pull requests per reviewer per month; the post-adoption figures, 6.56 divided by 0.33, give about 19.9, an increase of roughly 8%. This is our own back-of-envelope arithmetic mixing two firm-level ratios, so treat it as an illustration of direction, not an estimate. It shows why review time can climb even though firms added reviewers: output per worker grew faster than the pool of people reading it.

Why issue resolution did not move

Jira issues resolved per worker-month rose by 0.12 from a baseline of 3.67, with a standard error of 0.17, which is not statistically distinguishable from zero. Epics resolved, a coarser measure, moved by 0.01 from 0.16, also not significant. The authors read this as a bottleneck: coding is one stage in a pipeline, and when one stage speeds up the throughput of the whole line is set by the slowest stage, which they argue is review. A restaurant that doubles its cooking capacity but keeps one waiter does not serve twice as many tables.

That is the authors' framing, and the data are consistent with it, but the same numbers allow other readings. Lines of code and commits are activity measures, and a tool can inflate them without adding value, for example by generating verbose code. A Jira issue is a unit of planned work, not a unit of customer value, and teams may use the freed time on work that is not tracked as issues. Review time could also rise because reviewers are scrutinising agent-written code more carefully, which would show up as more comments and more change requests, as the paper finds. In that case slower review is the price of catching more problems, not pure waste. The paper cannot separate these stories, and it says so by reporting what moved rather than why.

The confidence interval is informative here. The authors report that the 95% interval for agents rules out an increase in issue output above about 12% of baseline. Our arithmetic on their figures (0.12 plus or minus 1.96 times 0.17, over 3.67) gives roughly minus 6% to plus 12%. That is a statement that large gains are unlikely at the firm level in this sample, not a finding that the true effect is zero. A modest gain, or a modest loss, fits inside it.

Agents and assistants behave differently

For assistants the picture is much quieter. Lines of code rose by 420 with a standard error of 371, and pull requests by 0.19 with a standard error of 0.17; neither is significant. Review time changed by minus 0.38 days, also not significant, from a longer baseline of 9.34 days. Commits did rise, by 1.40 or about 9%, and that effect is significant. In other words, the review burden in this paper is tied to agents, which produce whole changes for a human to approve, and not to autocomplete-style assistants. Teams that read the headline as being about all AI coding tools are reading more into it than the paper supports.

One further detail complicates the timing story. The paper reports that about 95% of the sampled firms had adopted an agent by January 2026, against roughly 45% adopting an assistant by April 2024. With so few untreated firms late in the sample, the later estimates lean on comparisons with a small group of holdouts, and the authors acknowledge that identification rests on the assumption that treated and untreated firms would have followed parallel trends. If unobserved factors, such as a firm launching a major project at the same time as it adopts a tool, are at work, the authors say the effects would likely be biased upward.

What the paper does and does not show about jobs

Because the debate over coding agents is often really about headcount, it is worth recording the paper's employment results. Overall employment moved by 0.01 in logs with a standard error of 0.02 after agent adoption, and engineering employment by minus 0.04 with a standard error of 0.05, neither significant. The authors say they can rule out an overall employment decline larger than about 2.9% and an engineering decline larger than about 13.8%. They also note the effects are short-run, that LinkedIn-based data may be slow to reflect layoffs, and that firm-level estimates may mask effects between firms. So the sentence the evidence supports is 'no detectable short-run change in employment in this sample', not 'agents do not affect jobs'.

How far to trust it

Four limits deserve weight. First, the data are one vendor's customers, who chose to integrate their tools with an analytics product, so they probably skew toward measurement-minded engineering organisations. Second, treatment is defined at the firm level from the first detected signal, so a firm where three engineers try Claude Code counts the same as one where everyone uses it. The authors argue this makes their coding estimates conservative relative to individual-level studies, since the average user effect is diluted. Third, take-up is measured incompletely: individual licences and tools outside Jellyfish's integrations are not observed. Fourth, the paper is a working paper, and its qualitative evidence comes from 17 interviews.

None of this makes the findings wrong, and the direction of the review results is plausible on mechanism alone. But it does mean an engineering leader should not import the specific percentages as forecasts for their own team. The useful thing to take is the question the paper raises: when output at one stage rises, where does the extra work queue up?

What a team can measure itself

A team considering coding agents can test the bottleneck argument cheaply with data it already has. Track the time from pull request opened to first review, and from first review to merge, separately, because the paper's review-time number lumps waiting and reviewing together. Track the number of pull requests each reviewer handles per week, and the share of pull requests that need a second round. Compare lines of code with something closer to value, such as issues closed, customer-facing changes shipped or incidents caused. If code output and review queues rise together while shipped changes stay flat, the team is reproducing the paper's pattern, and the next purchase may be reviewer capacity or review tooling rather than another seat.

The paper also tracks AI code-review tools separately, noting that nearly 80% of sampled firms had used AI in code review by March 2026, which is where a natural follow-up question sits: whether automating the review stage relieves the bottleneck or just moves it again. That is not something this study answers, and readers should be wary of any account that says it does.