More than 40% of pull requests on GitHub in September 2026 started with an agent’s first draft, up from 17% in March, according to GitHub’s Octoverse report, published on 28 October. Those pull requests also merged more often than the rest: 90% within two weeks, against about 86% for pull requests with no agent detected. The second number is easy to read as a verdict on agent code. It is a measure of acceptance, and acceptance is decided by review.
What GitHub published
The report covers 1 October 2025 to 30 September 2026, and its figures include public and private repositories unless it says otherwise.
- Share: “By September 2026, more than 40% of pull requests on GitHub started with an agent’s first draft, up from 17% in March.”
- Volume: 110 million agent-started pull requests in September alone, about six times March’s figure.
- Merge rate: in February, 83% of agent pull requests merged within two weeks, against about 86% of the rest. By September the agents’ figure was 90%, and the rest were still at about 86%.
- Spread: about 87% of agent-started pull requests change more than one file, against 79% of those without a detected agent.
- Totals: 1.3 billion pull requests merged over the year, about 3.5 million a day.
GitHub defines an agent-started pull request as one “whose first draft came from a coding agent that we can detect”, and says of its agent signals that each “is a floor, since not all agent use may be detected”. The real share is probably higher.
A merge rate measures the reviewers too
A pull request merges when someone approves it. Its merge rate is therefore a fact about the review process as much as about the code: it goes up when the code gets better, and it goes up when review gets lighter. The report cannot tell those apart, and does not try.
There is a recent case where review did get lighter. A study by researchers at Carnegie Mellon and Stanford followed one company through an AI mandate: output per developer nearly doubled, the share of pull requests with any human review fell from 89% to 68%, and the merge rate stayed essentially flat. We went through it in detail. The authors’ warning applies here as well: “once review becomes lenient or automated, the gate itself has changed.”
The agents’ pull requests are also, on GitHub’s own figures, more often spread across several files. More of them, touching more of the codebase, merging more often: that combination deserves a second look before it gets a celebration.
What the numbers do not show
The report says nothing about whether agent code is correct, secure or understood. It has no figures on defects, incidents or reverted changes, and none on review depth or review time. GitHub’s own line on it is the honest one: “And someone still has to decide whether it works, whether it belongs, and whether it’s good.”
Evidence from elsewhere is thin. A survey of 300 senior engineering leaders in the US and UK, run in July and August 2026, found that 81% said their organisation had had a production incident or outage linked to AI coding tools in the previous six months, and put the share of AI-generated code that reaches production before their teams fully understand it at 35%. It was commissioned by Undo, which sells debugging tools, and its respondents mostly work on large C and C++ systems, so read it as a signal from one corner of the industry rather than a measurement of it.
So the state of knowledge is this: agents now start a large share of pull requests, those pull requests are accepted at least as readily as anyone else’s, and nobody has published good data on whether the people accepting them understood them.
What a team can do
- Measure your own share. Count the pull requests your agents start, by repository, and compare their merge rate and time to merge with everyone else’s. GitHub’s figure is an average over millions of repositories, and yours will differ.
- Measure review, not just merges. Track the share of merged pull requests with a human review, and the share with a human-written comment. If agent pull requests merge faster with fewer comments, find out whether they are easier to review or less reviewed.
- Make agent pull requests easier to read. Ask your agents, in their instruction files, for smaller changes and a description that says what changed and why. Stacked pull requests, in preview on GitHub since 30 July, split related work into smaller changes reviewed in order.
- Decide what a person must read. Put sensitive paths behind a required human review from code owners, and give every agent pull request a named person who answers for it.
Where Deslopping fits, and where it does not
Deslopping works at the point this report cannot see: the approval. Every pull request gets a risk score from what it changes. Over your threshold, a required check waits until the reviewer has answered two or three questions generated from the diff, each about specific lines. Which tool wrote the code, whether Claude Code, Cursor, Copilot or another, is recorded and never moves the score. The reviewers’ ratings of the AI’s code then add up by tool and by module, so you can see which agent writes code your team cannot follow, and where.
It does not detect agents better than GitHub does, review the code for you, or reduce the number of pull requests. It adds a few minutes of reading to each gated one. If your agents open pull requests faster than your team can read them, it will show you that rather than fix it.
The first two measurements above take an afternoon with GitHub’s API. Start there, and you will know which of your merges the merge rate is vouching for.
Find out which agent pull requests your team can explain
Deslopping gates risky pull requests on two or three questions about their lines, records which tool wrote them, and shows by module and by tool where the AI’s code is hard to follow.