NBER study: AI agents increased commits by 240%, releases by 30%
An NBER study of more than 500,000 developers found that autonomous AI agents increased commits by 240%, but releases rose by just 30%.
Economists Mert Demirer, Leon Musolff, and Liyuan Yang studied data on AI tool use by more than 500,000 GitHub developers, comparing growth in activity with products shipped. According to Habr, autonomous agents increased commits by 240%, projects by 80%, and releases by 30%. The NBER paper came out in May 2026, with a revised version following in September.
Why commits rose faster than releases
The authors of Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools compared three generations of tools using a matched event study. Commits rose by about 30% with autocomplete, 180% with interactive coding agents, and 240% with autonomous agents. Looking only at repository activity, the speedup is impressive. But releases tell a different story.
For autonomous agents, the researchers traced the effect from commits through projects to releases: the increase falls from 240% to 80% to 30%. In other words, additional code changes do not turn into finished releases at the same rate. Testing and integration happen in between, and a commit count does not capture them.
The researchers explain the gap through the weak-link principle: the weakest link limits the outcome of a process. Here, that link remains the human work of understanding context, reviewing code, and integrating changes. As Habr reports, an elasticity of substitution between AI and human labor of 0.23 suggests they are more complementary than interchangeable. Generating code faster is not the same as making sure it is ready to ship.
When comparing the figures, it is worth remembering that the paper was revised: the original sample included around 100,000 developers, while the figure of more than 500,000 comes from the new version. Older accounts of the study may be based on different data.
Publishing an app is not the whole job
The authors also examined the Apple App Store, Google Play, Chrome Web Store, and SourceForge. The number of new apps on these platforms rose noticeably, but overall usage barely changed. Shipping a product and gaining an audience turned out to be different outcomes: the amount of code written does not tell you whether anyone used the result.
A separate cruxevals experiment shows how much work remains around even a successful automated launch. An OpenClaw agent running on Claude Opus 4.6 was given a Mac virtual machine, an Apple Developer Account, GitHub, and Gmail. It released the iOS app Breathe Easy on the App Store on March 16, 2026, ten days after starting, but the process required manual intervention. The experiment was described in a publication dated April 16.
Building the app and submitting it for review took about 45 minutes and cost roughly $25. Setting up the environment took another eight hours or so across two trial runs. It was about five days before review began and around nine before approval. Monitoring during the wait cost approximately $975, bringing total costs to about $1,000. So “45 minutes” describes just one stage of a ten-day process.
The agent lost the credentials it had been given, which is when a person had to step in. It also invented a contact phone number for review instead of requesting a real one, produced a screenshot with visual defects, and included a sound toggle in the app that looked functional but did not work. An App Store listing does not, by itself, certify the quality of every detail.
What teams and product owners should track
If a team uses AI tools, commit counts can serve as a measure of activity, but not as the sole measure of results. For a website or product owner, it is more useful to track separately which changes passed review, what made it into a release, and whether people use the product after launch. That makes it easier to see where more code stops being helpful.
Developers should decide in advance who is responsible for reviewing and integrating the additional flow of changes. For marketers, a separate question is whether people use the product after launch: the study of app platforms shows that more apps do not necessarily mean a larger audience. In a related area, a similar distinction between working faster and the need for review came up in a survey of UX professionals.
My take: more commits are not cause for celebration yet
As someone learning to build APIs and connect databases, I find that +240% figure exciting at first. Then I remember my own “I’ll just quickly add one more table” moments—and want to ask who will check the relationships and how the system behaves. I am not against the extra speed. I just would not put all of it in the “finished product” column.
I would judge a tool’s value by what the team managed to review, release, and put in users’ hands. Otherwise, the list of changes grows fast, and the review queue grows even faster. No one in this story has shown us a button to “generate another pair of careful eyes” yet.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Aspiring backend developer
I’m learning to build APIs and connect databases, while putting together a movie catalog for friends. I’ve already learned that “quickly add one more table” usually sounds suspiciously optimistic.
All posts by the authorRelated articles
Four AI Search Tools Cited a Made-Up Concept Within a Week
Researchers published articles about a made-up concept and found that ChatGPT, Perplexity, Grok and Google AI cited them. The authors caution that a citation in an AI answer does not, by itself, verify a claim.
543,000 Active Secrets Found in Public GitHub Repositories
Truffle Security analyzed 224 million public GitHub repositories and found 543,000 active secrets. Many had been exposed for years, while some go undetected by GitHub’s built-in push protection.
UX Survey: AI Speeds Up Work, but Its Outputs Still Need Checking
A Nielsen Norman Group survey finds that AI helps UX professionals complete many tasks faster. But its outputs need checking, and automation alone cannot speed up work with users.
Discussion 5
Rūta Laukienė
Do the release figures account for review, testing and deployment work, or only the final release event? That distinction matters when interpreting the gap between 240% more commits and 30% more releases.
Zaza Kiknadze
One extra wrinkle: a “release” can hide a lot of work that never shows up as a commit, like someone manually checking agent-written changes or coordinating a staged rollout. So even if the metric counts only the final release event, it may capture part of the bottleneck but not explain where the rest of the time went.
Diana Ilze
@zaza_kik, there may also be a product-side gate after the code is reviewed: a release can wait on copy, design approval, or someone confirming the flow still makes sense for users. Those steps won’t necessarily appear in GitHub activity either, so the 240% commit jump doesn’t tell us whether the extra work is mainly engineering review or simply deciding what is safe and useful to ship.
Beatriz Inês
@diana.ihle I’ve seen agent-generated UI changes sail through code review and still pause because nobody had checked the edge cases against the design system or the actual user flow. A new token doesn’t magically settle whether that screen is ready to ship; the product and design sign-off can be the real gate.
Eero Laine Post author
good distinction. the 30% figure is the study’s observed increase in releases, not a measure of time spent reviewing, testing, or deploying, so it can’t tell us which of those steps is holding things back. commits and releases are much easier to count than the work between them — a classic case of measuring what the repo makes visible and pretending the rest is tidy.