Two Studies Find AI Coding Agents Raise Commits Far More Than Releases

Autonomous coding agents raise a developer's commit count by about 240 percent and their count of shipped releases by about 30 percent, according to an NBER working paper revised in September 2026. A second study, from Harvard, finds that firms adopting agents write more code and still resolve the same share of their Jira issues.

The two papers use different data and different methods, and they land in the same place. Writing code got faster; getting software out the door barely did.

What the NBER paper measured

The paper, "Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools" (NBER Working Paper 35275), is by Mert Demirer, Leon Musolff and Liyuan Yang. It combines more than 500,000 GitHub developers with telemetry on their use of AI tools, and it uses a matched event study, which compares developers who adopt a tool against similar developers who have not yet done so.

The cumulative effect on commits grows with each generation of tool, and the gain shrinks as you move down the production chain:

1. Commits240 %
2. Projects80 %
3. Releases30 %

Source: NBER Working Paper 35275, abstract page, accessed 2026-10-13

For earlier tools the commit effect was about 30 percent for autocomplete and about 180 percent for interactive coding agents, per the abstract. The authors read the pattern through the weak-link hypothesis, the idea that human bottlenecks cap what faster machine output can deliver. They estimate an elasticity of substitution between AI and human effort of 0.23, which they interpret as strong complementarity: more machine effort does not replace the human steps that remain.

The abstract adds one more data point from outside GitHub. Across four major software marketplaces, it reports a sharp increase in new apps and no increase in total usage. The authors' summary is that task-level gains "have therefore translated only partially into shipped and used software thus far."

One disclosure sits on the NBER page: Demirer and Musolff previously held postdoctoral positions at Microsoft and now work as paid research consultants for it. The page lists no disclosure for Yang, and The Terminal has not read the full paper beyond the abstract page.

What the Harvard study found at firm level

The second study is by Harvard researchers Fiona Chen and James Stratton, who used analytics from Jellyfish, a tool that measures engineering team output. The Terminal could not extract text from the 78-page PDF of the paper. The figures below come from a republication of Ars Technica's report, which links the paper, and should be checked against it.

Per that report, the data cover about 300 million work events such as commits and pull requests, from more than 700,000 employees at over 700 software firms, from 2021 through March 2026. The authors dated each firm's adoption of AI assistants and agents, then ran a difference-in-differences comparison, which measures how outcomes changed at adopting firms against firms that had not yet adopted.

Measure at firms adopting agents	Reported change
Lines of code generated	Up 30 percent
Commits	Up 20 percent
Pull requests	Up 23 percent
Jira issue and epic resolution rate	No statistically significant change

The report quotes the authors as finding "little evidence that firms increase software output or reduce employment," and says coding-phase efficiency gains are "absorbed by downstream constraints in the production process." As review takes longer, it adds, "pull requests are more likely to require revisions, and reviewers leave more comments." The republished text is internally inconsistent about scale, calling the sample "hundreds of firms" in the introduction and 700-plus in the methods, so the sample size is the first number to verify.

Where the two papers disagree

The size of the commit effect differs by a wide margin: 240 percent in the NBER developer-level data against 20 percent in the Harvard firm-level data. Both can be true. One measures a developer who adopted an agent, and the other averages across a whole firm, where many engineers may use the tools lightly or not at all. The NBER abstract page and the republished Harvard report do not reconcile the two figures, and The Terminal has not read either full text.

What they share is the shape. Commits move first and most. Anything that needs another person, whether a reviewer, a release manager or a customer, moves least. Maintainers are already dealing with the output end of that pipeline, as in Linus Torvalds' use of Claude Code on kernel page-cache patches and the QGIS moratorium on AI-assisted contributions, both covered earlier on this site.

What would change the reading

Both studies are observational. Adoption was not randomised, and firms or developers that adopt early may differ in ways the matching does not catch. Commits and lines are also poor proxies for work: an agent that splits a change into five commits raises the count without raising the output.

The NBER paper's own revision date, September 2026, is a reminder that its numbers are still moving, and the Harvard paper's sample size is unresolved in the coverage. The next check is the full text of each: the NBER paper's identification section and the Jellyfish PDF's firm count.