Saturday edition · 7 November 2026 · No. 311One considered edition. No endless feed.
SOTA WatchPractice Brief

Commits Up 240%, Releases Up 30%: What Coding Agents Did to Delivery on GitHub

Treat output volume as an input metric, not a delivery result.

1 October 2026·8 min read

Researched by an agentic pipeline. Reviewed and approved by the editor before publication.

What was done

Demirer, Musolff and Yang, of MIT and Wharton, compared developers who adopted AI coding tools with similar developers who had not. They used public GitHub histories and, for some tools, usage records held by Microsoft, which owns GitHub12. The September 2026 revision of their NBER working paper reports 521,329 adopters after screening, set against a control pool of 20.8 million GitHub accounts1. An earlier column summarising the work cites "more than 100,000" developers and lower headline figures; this brief uses the revised paper2.

Each adopter is matched to a control with near-identical activity in the same calendar week one year earlier. The authors chose that design because present-day non-adopters may be using AI privately12. Adoption is dated from traces: a Copilot subscription start, the first use of agent mode, a first commit of a CLAUDE.md file for Claude Code, or a first pull request by a coding-agent bot1.

The paper separates three generations of tool: autocomplete; synchronous agents that work alongside the developer, such as Claude Code; and asynchronous agents that take an assigned task, such as GitHub's coding agent or OpenAI's Codex. Because developers adopt newer tools on top of older ones, the headline effects are cumulative rather than clean per-tool comparisons12.

What was measured

The writing layer moved a great deal. Against matched controls, the cumulative effect on commits is +30% for autocomplete, +180% once synchronous agents are added and +240% with asynchronous agents1. Further down the chain the effect thins. The paper reports the same 240% commit gain falling to +80% for projects and +30% for releases1.

The per-layer picture for synchronous-agent users, in weeks 21 to 30 after adoption, shows the same attenuation. Standard errors are in the paper; the release estimate is the least precise1.

Output layerChange vs matched control, weeks 21-30
Lines of code+957.5%
Files+265.0%
Commits+153.2%
Pull requests+86.0%
Repositories touched+47.3%
Releases+19.8%

For autocomplete alone, the release effect is +9.0% with a standard error of 5.0, which is only marginally distinguishable from zero1. For Claude Code users taken alone, commits rise 295.5% (standard error 7.7) and releases 39.4% (standard error 6.8)1. The authors note that Claude Code's larger effect may reflect who adopts it1.

The commit gain is eight times the release gain: 240 against 30. The authors read this pattern through a model in which each stage of production is limited by the scarcest input. They estimate an elasticity of substitution of 0.23 between upstream output and human effort, which they describe as strong complementarity1.

The paper also looks past GitHub, at four software marketplaces. Monthly new iOS apps roughly doubled between early 2025 and April 2026. Usage of each monthly cohort of new apps in its first three months was flat or declining on every marketplace, and the share of new apps failing to reach even a modest audience rose2. The paper's introduction reports the same pattern: more new apps, no increase in total usage1.

What failed or remains unproven

The study is observational. Commits are a proxy for output, and the authors state that GitHub activity is a developer-side measure that does not show whether software reaches users2. Releases are rare events, which limits precision, and although placebo tests with non-AI tools are reported2, matching on past activity cannot rule out that adopters differ in ways the data do not capture.

Early weeks are inflated. Autocomplete's commit effect is 44.1% in weeks 1 to 10, 28.3% in weeks 11 to 20 and 30.2% in weeks 21 to 30; the authors prefer the later window and attribute the early excess to transitory experimentation1. Asynchronous agents show the same front-loading1.

Detection is incomplete. The public-repository measure identifies only 24.2% of asynchronous-agent users, though it captures 72.9% of their activity, and the authors say synchronous estimates may partly absorb asynchronous use1. Most AI use leaves no public trace2.

The paper looks for quality explanations and does not find them in its measures. The bug-fix share of commits stays stable after adoption, and lines and files per commit do not fall1. Both are crude proxies. The brief found no review-time, revert or defect outcome in the material it opened.

The data are open-source only, with little enterprise coverage. The authors cite a separate study, Chen and Stratton (2026), as finding the same attenuation in enterprise software with considerably smaller effects, and as measuring longer review times directly1. This brief did not open that study and cannot confirm either claim.

Interested-party and independence points matter here. The cover page states that "at least one co-author has disclosed additional relationships of potential relevance"; the relationships are not specified in the text this brief read1. Part of the telemetry is Microsoft-internal and cannot be inspected by outsiders12. This brief found no independent replication of the headline ratios. Nor did it find a confidence interval for the 0.23 elasticity in the sections it read, so treat that figure as model-dependent.

The marketplace result cannot separate two explanations. The authors say their data cannot distinguish lower-quality marginal apps from a consumer-attention bottleneck2. The result is also described as cleanest for iOS2.

Other evidence is indirect and measures something different. A 2025 randomised trial by METR, with 16 experienced open-source developers and 246 tasks, found tasks took 19% longer with AI allowed (interval +2% to +39%); METR now marks that result out of date45. Its 2026 follow-up, with 57 developers and more than 800 tasks, found a speedup of 18% among returning developers (interval from a 38% speedup to a 9% slowdown) and 4% among new ones. METR calls that data an unreliable signal that likely biases the speedup estimate downwards, and very weak evidence on the size of the change5. Neither study measures shipping. A survey of 128,018 GitHub projects estimates that between 22.20% and 28.66% use coding agents, detected from traces that users can hide, in a snapshot taken in February 20263. The 2025 DORA report's landing page describes AI as an amplifier of existing organisational strengths and weaknesses, but gives no figures6.

What this proves, and what it does not

It supports a narrow claim. Among public GitHub developers who adopted agents, activity at the writing layer rose far more than activity at the delivery layer, and the gap widened at each step. The gap is large relative to the standard errors for commits, pull requests and repositories, and less precise for releases.

It does not show that human review is the binding constraint. The elasticity of 0.23 is the authors' model fitted to the attenuation pattern, not a measurement of review capacity. Low-value output, experimentation and weak consumer demand would all produce a similar shape, and the paper's data cannot separate them. It does not show an enterprise effect, a causal effect of the tools, or any change in quality. It says nothing about cost: no inference, licence or review-time data appear in the material this brief opened.

What a decision-maker should conclude

Treat output volume as an input metric, not a delivery result. A claim that agents raised commits, pull requests or lines of code by a large multiple tells a programme leader little about what reached customers. In this study, the multiple at the release layer was one-eighth the size of the multiple at the commit layer.

Before approving capacity plans built on agent-driven throughput, measure your own funnel from change written to change released, and read it layer by layer. If your commit rate has risen and your release rate has not, this study gives you a reason to look for the constraint, but not a finding that it sits in review. The test is local: pick the layer where work queues and find out whether it is waiting for people, for approval, for integration or for a reason to exist.

Hold any enterprise case to the same standard. The best available evidence on enterprise attenuation is a study this brief could not verify, and the public-repository evidence here is observational, partly based on a platform owner's telemetry, and unreplicated.

Sources
  1. Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools, Working Paper 35275 NBER (Demirer, Musolff, Yang) · May 2026, revised September 2026
  2. Writing code versus shipping code: Productivity effects across generations of AI coding tools CEPR VoxEU (Demirer, Musolff, Yang) · 21 June 2026
  3. Agentic Much? Adoption of Coding Agents on GitHub Robbes, Matricon, Degueule, Hora, Zacchiroli (arXiv 2601.18341v2, via alphaXiv) · 8 April 2026
  4. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity METR (Becker, Rush, Barnes, Rein) · 10 July 2025
  5. We are Changing our Developer Productivity Experiment Design METR (Becker, Rush, Cunningham, Rein, Mahamud) · 24 February 2026
  6. State of AI-assisted Software Development 2025 (landing page) DORA / Google Cloud · 2025
More from SOTA Watch

All of SOTA Watch →