A firm that adopts AI coding agents gets about 30% more code. It does not get measurably more software out the door. In the firms that adopted, the average time to review a pull request rose 49%, the share of pull requests drawing change requests nearly doubled, and the share of workers performing code reviews rose 14%.

The figures come from Artificial Intelligence in the Firm: Bottlenecks in Software Production, a Harvard job market paper by Fiona Chen and James Stratton (PDF). The current version is dated 4 August 2026; a first version appeared on 7 January 2026. The data partner is Jellyfish, an engineering-analytics vendor whose clients agreed to let their records be used for research. The window runs from January 2021 to March 2026 and covers 718 firms, 725,938 workers and about 300 million work events, including 200.9 million commits and 49.1 million pull requests. The paper has not been peer reviewed.

Coding agents raised lines of code, commits and pull requests

The paper keeps coding assistants and coding agents apart. Assistants are the completion-style tools that reached firms from February 2023. Agents run multi-step tasks and became commercially available in November 2024 with Cursor’s agent tool. Both raise activity, at very different scales. The paper calls the agent results “large and significant” increases across all three output measures: 30% for lines of code, 20% for commits and 23% for pull requests. Assistants produce “small increases” of 12% for lines of code, 9% for commits and 5% for pull requests, with only the effect on commits statistically significant.

One caveat belongs with those numbers. The treatment is firm-level adoption, so the estimates average across employees who may have barely touched the tools. The authors say that puts their figures on the lower end of recent work on coding productivity, because they measure average take-up rather than the returns available to a heavy user.

Issues and epics resolved show no statistically significant change

Delivery looks different from activity. The paper’s measures for work actually completed are Jira-style issues and epics, and it finds “small positive, but statistically insignificant” effects on both. That is the honest form of this result: no statistically significant change. For agents, the estimates rule out an increase larger than 12% of the baseline mean, which the paper notes is well below the 30% gain it measured. Machine-learning estimates of engineer-hours and cycle time per issue also show “no evidence of an effect on the average predicted length” of each issue, so the null is not a shift toward smaller tickets. Writing code is only one stage of the process, and engineers spend 30% to 40% of their time on it.

The code review bottleneck absorbed the extra output

The clearest mechanism sits immediately after coding. Average time to review a pull request rises by 49%. The share of pull requests with changes requested nearly doubles. Comments per pull request increase by 35%. The share of workers performing code reviews increases by 14%, which the authors describe as firms reallocating labour toward review. That pressure survives the arrival of AI code review tooling: “This bottleneck persists following the adoption of AI code review tools,” the paper says, and human reviewers “continue to play a central role in the review process.” Ars Technica, reading the paper, reports AI-assisted code review in use at 80% of the firms by March 2026, with agents writing about 23% of review comments.

Employment: what the estimates do and do not rule out

The paper reports no statistically significant change in employment that it can attribute to AI adoption. Its overall employment estimate rules out a decline larger than 2.9%. The engineering employment estimate is noisier and rules out a decline larger than 13.8%, a wide bound that should not be read as strong evidence against cuts to engineering teams. For assistants, the engineering employment estimate is “more ambiguous due to differential pre-trends” and cannot be read causally. The authors conclude that their estimates “rule out a full pass-through of the coding productivity gain to cuts in employment.” What was tested is firm-level headcount at firms that adopted the tools, not junior hiring, job quality or the wider labour market.

Firms that adopted earlier, compared with firms that adopted later

The design is a staggered difference-in-differences. Firms that adopted earlier are compared with firms that adopted later and with firms that never adopted, before and after each firm’s adoption date, on the assumption that without adoption the groups would otherwise have moved along similar paths. The authors argue that adoption timing is close to arbitrary for this purpose, because procurement runs through information gathering, security and legal review and small-scale pilots whose lengths vary across firms. Adopting firms still chose to adopt, and nothing here is a randomised trial. Parallel trends fails in one specification, the assistants’ engineering employment result. Other changes in the same period, from funding cycles to hiring freezes, are not ruled out.

A vendor supplied the data, without a vendor’s conclusion

Jellyfish sells engineering analytics, including tooling to measure AI impact and to remove workflow bottlenecks, so the paper’s conclusion lands in its own product category. The sample is its clients who opted into research and had continuous data, which skews toward large, established firms: as of January 2023 the average firm had 1,652 total workers and 241 active engineers, at an average age of 19.3 years, and 52% were software-as-a-service businesses. Tool take-up is detected through enterprise APIs for GitHub Copilot, Cursor and Claude Code, plus bot accounts and commit or pull request signatures, so individual-licence use stays invisible; the paper says its take-up measurement is incomplete in three ways.

The findings themselves do not read as a vendor’s pitch. The disclosure states that Jellyfish reviewed the manuscript only to check that it does not disclose proprietary information, “not … for its scientific content”, and that the conclusions are the authors’. Funding comes from a Stripe Economics of AI fellowship, a Harvard Kennedy School program and Schmidt Sciences. Jellyfish published two earlier write-ups of smaller drafts, a September 2025 post co-authored by Chen and Stratton and a January 2026 post by its head of research, covering roughly 500 firms each; neither reported a review bottleneck, so neither is this paper.

The March 2026 cutoff bounds every estimate

The data stops in March 2026, about 16 months after agents reached the market commercially, and that exposure is concentrated at the end of the window. Every agent-era figure describes the tools available by then. The paper cannot speak to later models, or to how organisations adapt over longer stretches.

How the paper sits against other evidence from 2026

CEPR’s “Writing code versus shipping code” (Demirer, Musolff and Yang, NBER working paper 35275; VoxEU column, June 2026) uses different data and a different design, and finds a real output gain this paper does not: commit-level output roughly triples, with about 80% more projects, about 30% more shipped releases and no detectable gain in application usage.

Microsoft’s rollout study (Murphy-Hill, Butler and Savelieva, arXiv:2607.01418) found 24% more merged pull requests per engineer per day. Its authors warn that “a merged PR is not the same as the value it delivers”, and it says nothing about shipped software or employment.

METR’s 2025 trial, in which 16 experienced open-source maintainers worked on 246 issues, found AI use made tasks take 19% longer. METR has since said that design no longer measures current tools reliably and is rebuilding it, so the figure describes early-2025 tools.

The review pressure shows up in other datasets too. He and co-authors (arXiv:2607.01904) followed 802 developers and 196,212 pull requests at one company working to a “2x” mandate: per-capita throughput reached 2.09 times the pre-mandate baseline by April 2026, per-reviewer load roughly doubled, and automated review overtook human review while merge and revert rates held steady. A study of 567 Claude Code pull requests across 157 open-source projects (arXiv:2509.14745) found that 83.8% were eventually merged, and of those, 54.9% needed no further changes.

No independent replication of Chen and Stratton’s specific estimates exists yet. The agreement above is about the mechanism, which is weaker than replication.

What to measure now

If your team is running agentic coding tools, the paper suggests watching delivery rather than activity volume.

  • PR review time: median and worst-case time to first review and time to merge. Review time climbing alongside commit volume points at review capacity.
  • Change-request rate: the share of pull requests that come back for changes.
  • Comments per pull request, and the share of the team whose week goes into review.
  • Issue and epic throughput, measured over the same dates as the code metrics.
  • The falsifier: if issue and epic throughput rises roughly in step with commit and pull request volume, the bottleneck reading fails for your team and the constraint sits somewhere else.