A National Bureau of Economic Research working paper tracked more than 100,000 GitHub developers and measured how AI coding tools affect output across the full production chain — from commit to release. The finding is more precise than most AI productivity research: autonomous coding agents increase commit activity by 180%. They increase releases by 30%.
The gap between those two numbers is not measurement noise. It is where developer productivity goes missing.
What the Production Hierarchy Shows
The paper, by Demirer, Musolff, and Yang (NBER WP 35275), compared three generations of AI tools across the same developer population: autocomplete-style suggestions, interactive coding agents, and fully autonomous agents. Each generation is measurably more capable than the last. Each shows the same pattern when you track output through what the authors call the production hierarchy.
Autocomplete: commits up 40%. Interactive agents: up 140%. Autonomous agents: up 180%.
But releases — actual software reaching users — tell a different story. Autonomous agents, which move the commit needle the most, move the release needle by 30%. For the number of distinct projects, the figure comes in at 50%. The attenuation from commit to project is roughly 3-to-1. From commit to release, it is 6-to-1.
Every six extra commits from autonomous AI agents produce approximately one extra release. Five of the six go somewhere else.
Where the Five Go
The paper frames this around what they call the weak-link hypothesis. Software production is a chain with multiple steps, and you cannot speed up the chain by speeding up one link. The elasticity of substitution they estimate between AI and human effort is 0.25 — a technical way of saying that doubling AI output increases total output by roughly 18%, not 100%, because human steps downstream are not scaling proportionally.
The steps AI skips are the ones that have always been hard: getting code reviewed and merged, getting the feature aligned with what users actually need, managing the release pipeline, getting the thing deployed and monitored. Commits are upstream of all of this. Releases require surviving it.
This is not a new dynamic that AI created. Developers also produce commits that never become releases — through churn, through code that fails review, through features that get deprioritized. The difference is scale. Before AI agents, the gap between commit rate and release rate was limited by how fast humans could write code. Now it is limited by how fast the downstream chain can absorb what the agent generates. That limit is lower than the agent's generation rate.
The App Store Validation
The most striking finding in the paper is not the GitHub data. It is what happens when you look at the actual end of the chain.
Demirer and colleagues tracked output across four major app marketplaces. Developers using autonomous AI agents were shipping more apps — the count of new submissions went up. But total usage, downloads, active users, the metric that measures whether anyone wanted what got built, did not increase.
More apps. Same users.
That is the measurement trap at scale. If you counted new submissions, you would conclude AI was driving a productivity boom in the app economy. If you counted people using the apps, you would reach a different conclusion: AI helped developers build more things that nobody downloads.
I don't think this means AI-built software is inherently worse at finding users. It means the constraint on app success was never development speed. Finding a problem people care about, building something they can understand, getting it in front of the right people — none of those steps got faster because the commit rate tripled.
The Metrics Problem
Most teams tracking AI's productivity impact are measuring the part of the chain AI visibly accelerated. Commit frequency. Lines of code. PRs opened. Tasks closed. These are real numbers that genuinely moved. A developer using autonomous agents produces more of all of them.
But these are intermediate goods. The question is whether intermediate goods are converting to the thing that actually matters: shipped software that reaches users and does something they want. The NBER data suggests that conversion rate dropped when commit rate tripled. Not collapsed — 30% more releases from 180% more commits is worse conversion than before AI agents existed, but it is still positive.
For teams reporting AI productivity wins to leadership, this is a gap worth monitoring. The reports use commit-level metrics because they're available, because they moved in a favorable direction, and because release-level impact is harder to attribute cleanly. That is exactly the dynamic the paper describes: the data you're collecting is upstream of where the attenuation is happening.
Which Link Is Actually Weak
The production hierarchy framing is useful because the weak link is not the same for everyone. If code review on your team is fast, reviewers are available, and your release pipeline is automated, the attenuation from commit to release might be smaller than the population average. If you're shipping into a crowded market where distribution is the real constraint, the attenuation might be larger.
The 6-to-1 ratio is an average across 100,000 developers. Your number could be better or worse. But the direction is consistent: more commits are easier to generate than more releases, and more releases are easier to produce than more usage.
What AI did is move the bottleneck. Before agents, the binding constraint was often at the commit stage — the limiting factor was how fast the human could write code. Now that constraint has shifted upstream of review, deployment, and distribution, and those stages have not gotten faster to compensate.
This is not a pessimistic story about AI. It is a structural story about chains. A 30% increase in releases from a tool that costs roughly the same per month as an editor subscription is real value. The question is whether you are measuring it correctly — or whether you are looking at a 180% metric and expecting a 180% business impact.
What the Right Measurement Would Look Like
If the goal is understanding whether AI is making you more productive, the only metric that tells the complete story is at the bottom of the hierarchy: what shipped, and whether it reached people.
Commits give you the wrong answer because they are upstream of too many filters. PRs are better but stop before deployment. Release count is closer. User adoption is the full chain.
The useful discipline is tracking backwards from output and asking at each upstream step how much of what you generated there is surviving to the next one. If 180% more commits are producing 30% more releases, you are losing roughly 83% somewhere between the two. Where you lose it determines what to fix.
Most developers don't have this picture because the tools that report activity — editors, CI, issue trackers — are organized by activity type, not by chain position. You see everything that happened in each layer, but not the conversion rate between layers.
The 6-to-1 number is a population average. Your version of it is something you can know if you track from first commit through to release, and connect that to who actually uses what shipped. That is a harder instrument to build than a commit counter. But it is the instrument that tells you whether the work is landing — not whether the work is happening.