GitHub's 40% agent pull request figure is a floor, not a verdict

Yes, by GitHub’s own count, and with conditions that matter. GitHub’s Octoverse 2026 report says that by September 2026 more than 40% of pull requests on GitHub started with an agent’s first draft, up from 17% in March. The figure covers one month, counts only agents GitHub can detect, and measures who produced the first draft of a pull request, not who wrote the code that eventually shipped. Read that way, it is a credible lower bound. Read as “agents now do 40% of software development,” it is not supported.

The report, published by GitHub on October 28, 2026 and updated on November 6, also compares how often agent pull requests merge within two weeks. Agent pull requests rose from 83% in February to 90% in September while the comparison group stayed near 86%. That comparison is the part most likely to be over-read. It does not show that agent work is better, and the report does not define its denominator precisely enough to say exactly what it shows.

The Frontier Wire has not run its own analysis of GitHub data, which is not public at this level. This article reads the Octoverse 2026 post in full, including its glossary and methodology, alongside the 2025 report, GitHub’s documentation for its cloud agent and an independent 2025 study of agent pull requests. Every number below is GitHub’s unless the text says otherwise. Where a figure is our own arithmetic on GitHub’s numbers, it is labeled.

The short version

• GitHub counts a pull request as agent-started when its first draft came from “a coding agent that we can detect.” It names neither the agents nor the detection method.
• As a share of all September pull requests, the 40% is a reasonable floor: undetected agent work lowers the numerator but not the denominator.
• The floor property does not carry over to the rise from 17% to 40%, or to the merge-rate comparison.
• The merge numbers show speed or frequency of acceptance in an unmatched comparison. They are not evidence of quality.

What GitHub actually published

The headline claim appears twice in the report, in two slightly different forms. The opening summary says: “As of September, developers start more than 40% of pull requests with an agent. In March, it was 17%.” The workflow section says: “By September 2026, more than 40% of pull requests on GitHub started with an agent’s first draft, up from 17% in March. That is 110 million in September alone, about 6x March’s volume.”

The two sentences carry different subjects. In the first, developers start pull requests using an agent. In the second, pull requests started with an agent’s draft. Both appear to describe the same measurement, but the first framing keeps the human as the actor, consistent with GitHub’s argument that “review is how developers shape what comes back.” Neither version claims that agents act without human direction.

The glossary supplies the definition that matters: an agent-started pull request is “a pull request whose first draft came from a coding agent that we can detect.” A related entry defines an agent signal as “an observed sign of agent involvement in telemetry, such as an agent-opened pull request,” and adds: “It is a floor, since not all agent use may be detected.”

The surrounding scope is set in the methodology. The Octoverse year runs from October 1, 2025 to September 30, 2026, inclusive. “Unless noted, metrics include public and private repositories.” Industry figures are public only. Prior-year figures were recalculated on the new definitions and window, so they may differ from earlier reports, which used public activity and a September-to-August year.

Three things are not in the report. It does not list which agents count, though its rankings of fast-growing repositories include several coding-agent projects. It does not describe the detection method. And it does not say whether “pull requests on GitHub” in the denominator means pull requests opened in the month, whether drafts and bot-opened pull requests are included, or whether spam filtering applies. The methodology says contributor and contribution counts “exclude spam-flagged accounts, staff, and bots where identifiable,” but that sentence is about contributors and contributions, not pull request shares.

Six labels for agent activity

The report uses several related terms. They are easy to read as synonyms, and they are not obviously the same measurement. The table collects each label as GitHub uses it, with the scope the report attaches. It is our compilation from the post’s text.

Two practical consequences follow. First, the merge-rate figures are attached to “agent-involved” and “agent pull requests,” not to “agent-started.” Involvement could be broader than starting: a pull request a human drafted and an agent later revised might count as involved without counting as started. The report does not say whether the groups are the same. Second, the language chart counts AI involvement in merged pull requests, a different denominator from the 40% figure, which counts pull requests regardless of outcome. That is why TypeScript, Python and Rust can sit at “about 40% to 44% of merged pull requests” without that being the same statistic as the September platform share.

The report also uses a seventh, repository-level signal: the agent configuration file, “a repository file that sets up or directs an AI coding agent.” GitHub reports that among repositories created this year, the average one with such a file logged eight times as many commits as the average new repository without one. The glossary itself notes that “repositories without one may still use AI.” That is a correlation between a file’s presence and activity, not a measured effect of the file.

Why the 40% is a floor, and where that logic stops

The floor argument is straightforward for the headline share. The numerator is pull requests where GitHub detected an agent first draft. The denominator is all pull requests. If an agent drafts a pull request without leaving a signal GitHub recognizes, the pull request still enters the denominator but not the numerator. Missed detections can only push the measured share down. So the true share of agent-started pull requests in September is at least the measured share, provided one condition holds: the detector rarely labels human-drafted pull requests as agent-started. GitHub does not publish a false-positive estimate.

How might detection miss agents? GitHub does not explain its method, so the following is illustration, not a description of GitHub’s pipeline. Agents leave signals of very different strength. GitHub’s documentation for Copilot cloud agent says the agent’s commits “are authored by Copilot,” with the requesting developer marked as co-author, and that each commit message links to the agent’s session logs. That is a strong, platform-native signal. A terminal agent that opens a pull request through the developer’s own credentials leaves weaker evidence. Claude Code, for example, adds a Co-Authored-By trailer to commits and plain attribution text to pull request descriptions by default, and its settings reference documents how to change or hide both. When a developer turns attribution off, a detector reading those markers would see an ordinary human pull request.

An independent study shows the same problem from outside GitHub. The AIDev paper by Hao Li, Haoxiang Zhang and Ahmed E. Hassan, submitted to arXiv on July 20, 2025, built a dataset of over 456,000 agent pull requests from five agents using public search signals: branch prefixes such as codex/, copilot/ and cursor/, the Devin bot account, and the “Co-Authored-By: Claude” text in pull request bodies. The authors note that Claude Code’s default attribution message “can be disabled,” that OpenAI Codex “provides no attribution at all,” and that because Cursor and Claude Code “are mainly used locally,” their behavior would be better understood from local environments than from GitHub data alone. Any signal-based count, inside or outside GitHub, inherits those gaps.

The floor logic stops at three points.

The trend row is the important one. If detection coverage was 70% in March and 90% in September, perhaps because more pull requests came through platform-native agents with strong signals, part of the measured rise would be a change in visibility rather than in behavior. If coverage fell, because more work moved to local agents with attribution switched off, the real rise would be larger than reported. The report does not say whether the detection method was held constant across the year, so neither direction can be excluded.

A worksheet on the denominator

GitHub gives enough numbers to estimate the size of the denominator, with explicit assumptions. The following is our arithmetic, not GitHub’s, and the inputs carry rounding: “more than 40%,” “about 6x,” “17%.”

Assume “about 6x March’s volume” compares agent-started pull requests in September with agent-started pull requests in March. The sentence is ambiguous, but that is its most natural reading.

On these assumptions, the total denominator grew roughly two to two and a half times between March and September, and pull requests without detected agent involvement grew too, by roughly half to four-fifths. The share rose from 17% to 40% because detected agent pull requests grew about sixfold, not because the other group shrank.

That matters for interpretation. The 40% figure is sometimes read as substitution: agents taking over pull requests that people would otherwise have written. The worksheet is more consistent with addition, a large new volume of agent pull requests arriving on top of a non-agent volume that also grew. Two caveats limit that reading. Undetected agent work sits inside the “without detected agents” group, so some of its growth could be agent work GitHub could not see. And a pull request is a unit of review, not a unit of effort. A single human pull request can represent more work than several agent ones, or the reverse.

The report’s broader context points the same way. GitHub says activity climbed from January and surged around June, that from June onwards about 55% of all commits came from brand-new repositories, and that merged pull requests across the year reached 1.3 billion, “an average of 3.5 million a day.” Those are figures for the whole year and all repositories. They suggest that a meaningful part of the agent volume arrived in new projects, though the report does not break the September pull request share down by repository age.

What the merge-rate numbers say

The full passage reads: “In February, 83% of agent-involved pull requests merged within two weeks, a touch behind the roughly 86% for pull requests without detected agent involvement. By September, agent pull requests were at 90%, while the comparison group held at about 86%.”

The sentence supports a narrow, real finding. Between February and September, by GitHub’s measurement, agent pull requests went from slightly less likely to slightly more likely than the comparison group to reach a merge within fourteen days. The comparison group stayed flat over the same period, which rules out a simple platform-wide change in merge speed as the whole explanation.

The sentence leaves at least four definitional questions open.

The denominator is ambiguous. “83% of agent-involved pull requests merged within two weeks” can be read two ways. Under one reading, 83% of agent pull requests opened in February had merged within fourteen days of opening, so the remaining 17% were closed unmerged, still open or merged later. Under the other, of the agent pull requests that merged, 83% did so within two weeks. The first reading combines acceptance and speed. The second is about speed alone, conditional on acceptance, and says nothing about how many agent pull requests were rejected. The report does not specify which.

The cohort is not defined. It is not stated whether “September” means pull requests opened in September or merged in September. A two-week window for pull requests opened on September 30 runs to mid-October, after the Octoverse year ends. The report was published on October 28, so the data could cover the full window, but the methodology does not say how late-month pull requests were handled.

The groups may not match the headline. As the terminology table shows, the merge figures use “agent-involved” and “agent pull requests,” not “agent-started.” If those are broader groups, the 90% describes a different population from the 40%.

Bots may sit in the comparison group. The report says developers merged more than 30 million Dependabot pull requests during the year. Dependabot is an automated dependency tool, not a coding agent. If its pull requests are in the “without detected agent involvement” group, they shape the baseline. Against 1.3 billion merged pull requests, 30 million is roughly 2%, so the effect is probably small, but the report does not say whether bots were excluded from these figures.

Sampling noise is probably not the issue. GitHub does not publish group sizes for these months, but the worksheet’s rough figures put March at about 18 million agent-started pull requests and some 90 million others. At volumes anywhere near that, a four-point gap is far outside random variation. That is the opposite of the problem in small agent benchmarks, where, as our analysis of benchmark sizes and statistical noise shows, a few hundred tasks cannot separate close scores. Here the uncertainty is about what is being compared, which no sample size resolves.

Why a merge-rate gap does not establish quality

Suppose the definitions were all settled. A merge rate would still measure a decision, not an outcome. A pull request merges when a person with permission decides it should, or when an automated rule allows it. That decision depends on the repository’s review rules, the reviewer’s workload, the size of the change and who opened it. It does not record whether the change was later reverted, caused a defect or needed a follow-up fix. Octoverse 2026 reports none of those downstream measures for agent or non-agent pull requests.

The platform rules themselves differ by author. GitHub’s documentation for Copilot cloud agent says its draft pull requests “must be reviewed and merged by a human,” that the agent “cannot approve or merge a pull request,” and that GitHub “prevents the user who asked Copilot cloud agent to create a pull request from approving it.” When the agent opens a pull request under its own app identity in a repository that already requires at least one approval, one more approval is required before merging. Those safeguards are reasonable. They also mean that merge rates for at least one class of agent pull requests are produced under different review constraints from the rest, depending on how each repository is configured.

The larger problem is composition. The report does not say the two groups were matched by repository, author or task. GitHub has made the case for matching itself: its Octoverse 2025 report, published October 28, 2025, compared public repositories with at least one Copilot coding agent pull request against a random sample without one and found “strong selection effects,” with agent activity “skewed toward repositories with more stars, larger size, and greater age.” The same report invited the community to run “within-repository experiments (A/B or stepped-wedge) and matched analyses conditioned on size, stars, age, and complexity proxies.” The 2026 merge comparison does not report any such matching.

A hypothetical: the whole gap from mix alone

The following example uses invented inputs to show how composition alone can produce GitHub’s pattern. It is not a claim about GitHub’s actual data.

Imagine two kinds of repositories. In personal and new projects, where the author usually merges their own work, 96% of pull requests merge within two weeks. In established team repositories with required reviews, 76% do. Assume that within each kind of repository, agent and non-agent pull requests merge at exactly the same rate. There is no agent effect at all.

In this example, the agent rate climbs from 83% to 90% and overtakes a steady 86% baseline, matching the shape of GitHub’s numbers, purely because agent pull requests moved toward repositories where everything merges quickly. The reverse is equally possible. If agent pull requests had moved toward demanding team repositories, a real improvement in agent quality could be hidden behind a flat or falling merge rate.

Which direction applies is not known. The 2025 report found Copilot coding agent activity skewed toward larger, older, more-starred public repositories. If review in those projects is slower, that mix would work against fast merges. The 2026 report’s observation that 55% of commits since June came from brand-new repositories hints that the mix may have shifted toward new projects, but it concerns commits, not the pull request cohort. The comparison as published cannot separate a change in agents from a change in where agents are used.

There is a competing explanation that the report itself offers for the period. It describes “better underlying models, the harnesses and tools built around them, and the agents running on both” arriving around June, and agents moving “from single-session tools to persistent ones.” Better agents producing more mergeable pull requests is entirely plausible. It is one of several explanations the data fits, not the one the data establishes.

How this compares with outside evidence

The most useful outside reference is the AIDev study, because it measures something similar on public data with a published method. Its conditions differ from GitHub’s in almost every respect, so the comparison below illustrates why the numbers cannot be lined up directly.

AIDev found agent pull requests accepted less often than human ones in popular repositories in mid-2025, with GitHub Copilot at 38.2% and OpenAI Codex at 65.3% in its Table 5, and the human comparison at 76.8%. The authors caution that their results were captured soon after many of these agents’ public release and “should not be interpreted as a sign of failure.” The samples for Cursor and Claude Code were small, at 144 and 101 pull requests.

The gap between AIDev’s numbers and GitHub’s is wide, and there are several candidate reasons. A year of model and tooling changes separates them. AIDev’s comparison set is popular public projects, where review by people other than the author is plausibly more common; GitHub’s figure includes private and personal repositories. The metrics differ, as do identification methods. It would be wrong to conclude that one source refutes the other. It would also be wrong to treat GitHub’s 90% as settling the question AIDev raised, since the two do not measure the same population.

Timeline of the evidence

The dates are easy to confuse because the report covers a data year that ended a month before publication. This is our reconstruction from the sources listed.

The November 6 update matters for readers checking whether the agent figures were revised. According to the edit note, the change concerned the methodology language for open-source rankings, not the pull request or merge-rate numbers.

Context from the same report

Several other figures in Octoverse 2026 bear on how much weight the 40% can carry.

GitHub reports that among Copilot’s monthly active users, 55% now use agentic features, up from 35% a year earlier, and that Copilot cloud agent usage grew 230% year over year against 85% for agent chat. Those are Copilot-only figures from GitHub’s own product telemetry. They support the general claim that delegation of whole tasks is increasing among Copilot users, without saying what share of the 40% came from Copilot rather than other agents.

The industry analysis is a useful contrast. Classifying random samples of public repositories created from 2022 to 2026 by industry, GitHub found that in administrative and support services, mining, health care and agriculture, agent-opened pull requests appear in fewer than 3% of repositories. Construction had the highest share, about 9%. Those are repository shares in sampled public projects, not pull request shares across the platform, so they cannot be set directly against the 40%. Taken together, though, they suggest agent pull requests are concentrated: a large share of pull requests can come from agents while most sampled repositories in a sector have never received one.

GitHub also reports that about 87% of agent-started pull requests changed multiple files, against 79% of pull requests without detected agents. That rebuts the assumption that agent pull requests are mostly trivial one-file edits. It does not measure size or difficulty, since a two-file change can be minor and a one-file change can be substantial.

The broader productivity question is beyond what these numbers settle. Our editorial on why coding-agent productivity needs a systems denominator argues that activity counts such as pull requests are intermediate artifacts, and that review effort, infrastructure and correction costs belong in the accounting. Octoverse 2026 points in that direction too: it reports that more than 264,000 developers had used stacked pull requests by September and that AI-assisted code review usage grew more than 90% year over year. Rising review tooling is consistent with review becoming the constraint. A parallel argument for research documents, rather than code, runs through our survey of the verification bottleneck in AI review.

What remains unknown

The open questions fall into three groups.

Measurement. Which agents GitHub detects, by what signals, with what false-positive rate, and whether the method changed during the year. Whether the 40% denominator includes drafts, bot-opened pull requests and spam. Whether “agent-involved,” “agent-started” and “agent pull requests” are the same group.

Composition. How agent pull requests are distributed across repository age, size, visibility and ownership. What share come from Copilot cloud agent and what share from other tools. Whether a small number of accounts or automated workflows produce a large fraction of the volume. The report cites one developer who made more than 1 million contributions across his public repositories, using agentic workflows to keep a machine-readable catalog of public API information current, which shows that heavy concentration is possible at the level of individual accounts.

Outcomes. How many agent pull requests were closed without merging. Revert rates, follow-up fix rates and review time for each group. Whether reviewers spent more or less effort per merged change.

Evidence that would change the conclusion

Several disclosures would let readers move from “credible floor with an uninterpretable comparison” to something firmer. Each is a proposal, not something GitHub has announced.

A published detection specification, with an audit of false positives on a labeled sample, would establish how much of a floor the 40% is and whether the trend from 17% is comparable across months.

A defined merge metric, stating the cohort, the window and the handling of closed and still-open pull requests, would say whether the 90% concerns acceptance or speed.

A matched comparison would address composition. One proposed design: within repositories that received both agent and non-agent pull requests in the same month, compare merge outcomes for changes of similar size by the same set of reviewers. This is the kind of within-repository analysis GitHub’s own 2025 report invited the community to run. If a gap survived that matching, the case that agent pull requests are becoming more mergeable on equal terms would be much stronger. If it vanished, the September result would be mostly a story about where agents are used.

Downstream outcome data, such as reverts within thirty days or linked bug-fix pull requests, would test whether merged agent changes hold up as well as others.

Until then, the defensible reading is narrow. In September 2026, more than 40% of pull requests on GitHub began with a first draft from an agent GitHub could detect, and the true share was probably higher. That is a large and fast change in how pull requests start. Whether agent pull requests are now as good as the rest is a separate question, and the merge-rate numbers published so far cannot answer it.