Once autonomous coding agents are added, the cumulative effect on commits is 240%. Releases rose only 30%.
Both numbers come from an NBER working paper that tracked more than 500,000 GitHub developers. The gap between them is the most useful thing I've read about coding agents in a while, because the extra code didn't vanish. Most of it is waiting somewhere between a commit and a release.
Everybody wants the same outcome here: agent-generated code merged sooner with fewer rollbacks. So I walked the path from commit to release and wrote down where the paper, plus a second 2026 study and a talk by Christian Bird, say the work stalls.
The paper is "Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools" by Mert Demirer, Leon Musolff and Liyuan Yang, NBER Working Paper 35275. The first version came out in May 2026, and the PDF was revised in September.
The authors combined public GitHub data from January 2020 to May 2026 with internal Microsoft telemetry on GitHub Copilot usage. A matched event study compared each developer who adopted a tool with a similarly active developer from the same week a year earlier.
Three generations of tools get measured, and the effects stack because people add newer tools on top of older ones:
| Tool generation | Cumulative effect on commits |
|---|---|
| Autocomplete | about 30% |
| Plus interactive ("sync") agents | about 180% |
| Plus autonomous ("async") agents | about 240% |
In the abstract's words, "the 240% cumulative effect falls to 80% for the number of projects, and to 30% for actual releases." A quick note on the title: +240% works out to 3.4 times the baseline, so "tripled" is my arithmetic, not the paper's word.
One more caveat on the 30%. The paper's detailed table gives no separate release number for autonomous agents, because releases "cannot be split into agent- and human-authored components." For interactive agents alone, releases rose 19.8%.
Demirer and Musolff each "previously held a postdoctoral research position at Microsoft and now works as a paid research consultant for the company," per NBER's disclosure. The study also relies on confidential Microsoft data, and NBER working papers aren't peer-reviewed.
I'd still take the pattern seriously, for a simple reason. A separate team using a different dataset, covered below, found the same shape inside companies.
The paper tests two explanations. One is scope: maybe each release just got bigger. The other is experimentation: developers start more work at the cheap stages, and much of it never reaches the end. The authors find scope "accounts for only a small fraction" and most of the gap "reflects experimentation."
They also name the human stages that limit what moves up: "integrating changes across files, reviewing and merging pull requests, managing releases," plus "quality control, and release capacity." Review is on that list, but it's one item among several.
The pull request layer shows the pile-up clearly. Interactive agents raised pull requests 86% but releases about 20%, so more changes enter review than leave it as releases. For autonomous agents, pull requests rose 68.5%, slightly more than commits at 60.7%, and the paper reports no separate release figure to compare.
The question is why the gap between writing and shipping is so wide, as Christian Bird puts it in "Why aren't we shipping faster now?", a talk drawn from interviews and surveys. In the Hacker News thread, Bird clarified that his point isn't that teams don't ship faster than before.
After adopting interactive agents, developers in the NBER sample added 7.0 times as many lines of code but deleted 12.2 times as many. A lot of generated code is draft material that gets replaced.
The authors are careful here: abandoned work isn't necessarily low quality. Trying three versions and keeping one can be a fine way to work. The cost shows up later, when someone has to tell the kept version from the drafts.
Developers in the sample created 79% more branches after adopting interactive agents, "exploring features that are often later abandoned," per the paper.
Stale branches are cheap to create and expensive to reason about. A branch with a half-finished agent change carries context nobody reviewed, and sooner or later someone asks whether it's safe to merge or delete.
Review is the stall with the most direct measurement, and the numbers come from outside the NBER paper. Fiona Chen and James Stratton of Harvard studied 720,542 workers at 655 firms in "Artificial Intelligence in the Firm: Bottlenecks in Software Production" (current version November 9, 2026).
Their data came from Jellyfish, an engineering analytics platform. After firms adopted AI agents, the time from submitting code for review to its approval rose 56.1%, or 1.99 days on a 3.56-day average. Time waiting in the backlog rose 59.9%, and time in active review rose 58.5%.
Both are standard code review metrics, so a team can track its own. Reviewers also worked harder per change. The share of code changes with at least one review comment went up 13.1%, and comments per change went up 38.6%. AI assistants, the earlier generation, had no significant effect on any of those measures.
Tools haven't erased the queue yet. Chen and Stratton report that 79.1% of firms had adopted AI code review tools, but humans still write the overwhelming majority of reviews and comments. The NBER paper cites their work as finding "code review as the binding constraint" inside firms.
Bird's interviews put a face on the numbers. A senior engineer in the interviews said: "The pace at which we have to review is fast outpacing our ability to review."
Reviewing a batch of agent PRs as a single unit is one response, covered in Your Agent Opened 15 PRs: How to Review AI-Generated Code as One Work Package.
Quality control is human-limited capacity too. Bird and colleagues benchmarked review agents on real bugs in "(When) Should a Software Factory be Lights-off?", with 1,000 open-source review tasks plus 800 from one company's private repositories.
The best agent setup caught 71.9% of known bugs within its top five comments, up from 47.7% five months earlier. Performance dropped on the proprietary repositories and on bugs that needed reasoning beyond the diff. The authors conclude "lights-off" operation fits only "narrowly scoped, low-consequence PRs."
A disclosure for balance: the benchmark's authors list Microsoft or Microsoft Research affiliations, and the best setup ran through Copilot CLI. The takeaway I'd draw is modest. Agents catch more bugs than they did in spring, and plenty still get through to a person.
Code from different people and agents still has to fit together. Bird's talk draws on 30 interviews from a paper still in submission, so the quotes below come from his handout.
One participant put the problem neatly: "If we used to take a year to get a feature done that we can now do in a month, in some senses, a year's worth of collaboration has to happen in that month."
Another, who owns a decades-old product, described "code that is under my management being changed by people I've never heard of before, that I was not included on the PR for." Coordination doesn't compress just because typing did.
At the far end, the NBER paper tracks projects. The share of new repositories with no activity after their first month rose from 60% in 2021 to 69% in 2026. More ideas begin; a bigger share stops early.
Beyond GitHub, the authors looked at four software marketplaces and found "a sharp increase in the number of new apps but no increase in total usage." Bird's interviewees describe the same drag from the inside: "If you can do the code in one day, you're still talking 30 days before it actually gets deployed."
A few limits, so nobody over-reads the headline. The NBER sample is public GitHub activity from developers with Copilot telemetry, and "releases" means GitHub release counts, not production deploys. Both papers are working papers.
Your own team's data is the closer test, and 5 numbers worth pulling from your own coding-agent sessions lists where to start.
Firm-level estimates of agents' effect on commits, including Chen and Stratton's, are smaller than the NBER open-source estimates. The NBER authors say the gap likely reflects organizational inertia. Neither paper evaluated any specific review product, and neither says a single fix closes the gap.
Qodo, the AI code review platform, works on the review queue. Qodo in your Git runs context-aware review on every pull request and applies the custom instructions your team writes in the Qodo portal or in .pr_agent.toml, so agent-generated PRs get a consistent first pass before a person opens them.
Bird's benchmark suggests a sensible split. Narrow, low-consequence changes need less human time; consequential ones need more. Consistent findings on every PR help reviewers spend their limited hours on the second group. Qodo flags; your team decides.
For high-velocity teams, those instructions, or a pr_compliance_checklist.yaml file at the repository root, get checked on every PR, with no new process. Enterprise engineering teams can apply the same custom instructions once at organization level, which matters when agents open PRs faster than any one team can track.
Rewrites, abandoned branches and release capacity sit outside this review pass, and neither study measured Qodo's effect. Qodo no longer offers test generation; it focuses on AI code review and code governance. In my experience, the review queue is where agent output waits longest, so that's where a consistent first pass helps.
Which review decisions should stay with a person is a separate question, covered in How to Review AI-Generated Code in 2026: The 5 Decisions I Keep Human.
The September 2026 paper reports a 240% cumulative increase in commits once autonomous agents are added, which is 3.4 times the baseline. The paper itself doesn't use the word "tripled."
AI coding tools raised commits a lot, and the effect grew with each tool generation. The gains shrank sharply further along: 240% for commits became 80% for projects and 30% for releases.
Releases are measured per repository, so the paper can't split them into agent-authored and human-authored parts. The 30% figure is the abstract's cumulative number.
No. The NBER data is public GitHub activity. Chen and Stratton's study covers 655 firms and finds a similar pattern, with code review as the measured bottleneck.
Not entirely. Two of the three NBER authors are paid research consultants for Microsoft, per NBER's disclosure, and the study uses Microsoft data.
No. The NBER authors list integration, review and merging, quality control and release capacity, and say most of the gap reflects experimentation. Review is the stall with the most direct measurement so far.