AI Coding Agents Nearly Tripled Commits. Releases Rose 30%.

In one week, four independent sources said the same thing. A Hacker News thread arguing AI is removing the middle class of software engineering climbed past 970 points. Geoffrey Litt's essay on understanding as the new bottleneck resurfaced to the front page. A position paper from CMU, Stanford, Princeton and UIUC argued the field is studying the wrong constraint.^[2]

Three of the four are arguments. The fourth is a measurement, and it does not say quite what the other three say.

How Good Are AI Coding Agents, Measured?

Very good at the part they touch, and the honest answer needs two cuts through one dataset. Economists Mert Demirer, Leon Musolff and Liyuan Yang studied more than 100,000 GitHub developers combined with their AI usage telemetry, in a matched event study, for an NBER working paper issued in May.^[1]

The first cut compares three generations of tools on a single outcome, commits. Autocomplete raised commits by a cumulative 40 percent. Interactive coding agents, 140. Autonomous coding agents, 180. Read plainly: the best tooling nearly tripled the rate at which code got committed. That number is real, and it is enormous.

The second cut is perpendicular to the first, and it is the one everyone will get wrong. Take the autonomous-agent arm alone and follow that same 180 percent effect down the production chain. It falls to 50 percent for the number of projects. It falls to 30 percent for actual releases.

Same developers. Same tool. Three stages. The further the outcome sits from typing, the smaller the effect.

Where Did the Bottleneck Actually Move?

Downstream of the code, which is not where this week's essays put it. The essays locate the constraint at the front of the chain: understanding, ideas, deciding what to build. We made the qualitative version of that argument ourselves in June, and it stands.

But the measurement is more specific. The loss compounds at every stage after authorship: review, integration, the release decision, the question of whether the thing deserves to ship at all.

The essayists are right that the bottleneck moved to the human. The data says which human step it moved to, and it is not only the one holding the product vision. It is everything between "the code exists" and "someone is using it."

The mechanism has a name and a parameter. The authors call it the weak-link hypothesis, and they estimate an elasticity of substitution of 0.25 between AI and human effort.^[1] In plain terms: an elasticity that far below one means AI effort and human effort are strong complements. You cannot fix a weak link by pouring more of the strong thing into it.

That parameter is the measured version of a thesis we published in January: the tools and the people bottleneck on each other, they do not trade off.

Is This Just the Productivity Paradox Again?

No, and the difference is the whole post. The paradox piece we published in July explained a modest aggregate gain by coverage: AI reaches most jobs but touches roughly a fifth of the tasks inside them, so the average comes out small.

This is the opposite situation. Here the effect where the tool lands is huge, commits nearly tripling, and it still shrinks stage by stage. Two different mechanisms, both measured, producing the same complaint. Both are true at once, and together they are the complete answer to why the revolution feels smaller than the demos.

Then the authors leave GitHub entirely, and this is where it gets uncomfortable. Across four major app marketplaces they find a moderate increase in the number of new apps and no increase in total usage.^[1]

More software got built. No more software got used.

Didn't Fred Brooks Call This in 1986?

Almost exactly, and the study reads like the test he never got to run. Brooks separated the essential difficulty of software, deciding what to build and what it should mean, from the accidental difficulty of constructing it, and argued that no attack on the accidental kind produces an order-of-magnitude win.^[3]

Four decades later, construction collapsed toward free. The stage that did not improve is the one he named.

The same gap shows up at organizational scale in one line. A study of ChatGPT Enterprise records covering 1,764 organizations and 17,446,551 messages, written by authors at or contracted to OpenAI on OpenAI's own telemetry, concludes flatly: "Adoption is only the beginning of deployment."^[4]

A vendor's own researchers finding that buying the tool is the easy part is worth the sentence precisely because it runs against the vendor's interest.

What Should a Team Do With the 180-to-30 Gap?

Stop speeding up the code step, which is already the fastest part of the chain, and name your own narrowest link. For most teams that is review capacity, integration, release confidence, or the decision about what deserves to ship.

Those steps run at exactly the speed they ran before agents arrived. And as long as they do, 180 percent at the keyboard turns into 30 percent where it counts, precisely as measured. The production-readiness question is this same arithmetic applied to a single app: the distance between built and shippable is the part the tools did not compress.

One honest hedge, stated once: this is a working paper, not yet peer reviewed, and the verified findings are the abstract's. It is also the only measurement in a week of essays, at a sample size the essays cannot answer.

The Map, Not the Failure

Commits are the easiest thing in software to count and the least connected to whether anyone is better off. That is not a new insight. What is new is having the drop measured stage by stage, with a mechanism and a parameter attached.

The distance between 180 and 30 is not a failure of the tools. It is a map of where the work actually lives, and it has been pointing at the same place since 1986.