Quorum
← All writing

Agents now draft 40% of pull requests. Who clicks merge?

AI and organizationsAI agentsEngineering productivity

A mostly dark open-plan office at night, one desk lamp still on, an engineer seen from behind staring at a vertical monitor full of red and green code changes

On October 28, GitHub held its annual Universe conference in San Francisco and published its 2026 Octoverse report the same day. The number that got the most attention: by September, more than 40% of pull requests on GitHub started as a first draft from a coding agent. In March the figure was 17%.

In September alone, agents started 110 million pull requests, roughly six times the March count.

From under a fifth to over two fifths in six months is faster than I expected. But what stayed with me after reading the report was something it doesn’t contain. It counts how much code was written and how much was merged. It has no number for how much of that code someone actually read.

The things that nearly tripled

Start with the totals. The Octoverse year runs from October 1, 2025 to September 30, 2026 and covers public and private repositories. GitHub says it recalculated the prior years on the same window, so the comparisons hold.

  • 17.9 billion pushes. Up from 6.7 billion the year before and 5.2 billion the year before that. This year beat the previous two combined.
  • 34.3 billion commits. Up from 12.9 billion.
  • 1.3 billion merged pull requests. Up from 538 million, or about 3.5 million a day.
  • 45.4 billion GitHub Actions jobs. Up from 14.0 billion, or 1,440 every second.

How much GitHub activity multiplied in one year

Over a similar period, GitHub’s developer count went from “more than 180 million” in last year’s Octoverse to “more than 225 million.” The two reports don’t use exactly the same window, so treat this as a rough scale: about a quarter more people, and two and a half times as many changes merged into main branches.

Who wrote the difference? The report offers some clues:

  • Agent pull requests are bigger. 87% of agent-started PRs touched multiple files, against 79% of PRs with no detected agent involvement.
  • Repos with agents commit far more. Among repositories created this year, those with an agent configuration file logged eight times as many commits as those without. The report doesn’t control for repo size or type, so this is correlation, not cause.
  • Copilot users are shifting to agents. 55% of monthly active Copilot users used agentic features, up from 35% a year earlier.

One caveat matters. GitHub defines an agent-started PR as one “whose first draft came from a coding agent that we can detect.” The glossary notes that “not all agent use may be detected.” My reading is that code written locally with an AI tool and then committed by a person likely falls into that blind spot. So 40% is a floor.

A 90% merge rate doesn’t tell you much

The only metric in the report that touches quality is the share of PRs merged within two weeks. For PRs with agent involvement, it rose from 83% in February to 90% in September. For PRs with no detected agent involvement, it stayed around 86% at both points.

It is tempting to read that as “agent code is now more reliable than human code.” My view is that it shows agent PRs are more likely to be accepted, and there are several reasons that could be true:

  • Agents got better. Models and tooling improved over six months. Plausible.
  • People got better at picking tasks. Teams learned what to hand off, and handed off small, well-bounded fixes.
  • Reviewers relaxed. With more PRs and bigger diffs, no one reads every line, and the bar for clicking approve drops.

All three look identical in a merge rate. The report doesn’t pretend otherwise: it contains no data on defect rates, reverts or security issues in agent PRs.

Outside data shows the other side. On October 20, the Linux Foundation published a survey of open source maintainers sponsored by Red Hat (reportedly 234 respondents, collected through a web survey from April to June):

  • 59% of maintainers say contribution volume has grown since generative AI took off. At large projects, those with more than 50 contributors, it’s 69%.
  • Maintainers estimate about 25% of incoming PRs are low-quality “AI slop.” At large projects the estimate is 31%.
  • Only 35% of projects have a formal policy permitting AI use. 32% have no policy and no plans for one.
  • 53% of maintainers disagree that AI has improved community trust.

These are self-reported estimates from a limited sample, not measurements, and they can’t be compared directly with GitHub’s platform data. But they make one thing clear: on the open source side, the first people to feel the strain are the ones reading the code.

A rough back-of-envelope, just to feel the scale. Take September’s 110 million agent PRs and assume five minutes of review each. That’s over 9 million hours. At 160 hours a month, it’s more than 50,000 full-time engineers doing nothing but reviewing agent PRs. Five minutes is a generous assumption. The cost of writing code is falling toward zero. The cost of reading it is not.

The August 17 outage

The pressure hit GitHub first.

On August 17, GitHub was down for 7 hours and 47 minutes. github.com, authentication, Actions, the API, pull requests and Copilot were all affected, and it was the second major incident that month. CTO Vlad Fedorov’s postmortem on August 20 was blunt: “Both incidents were capacity failures at their core.” And: “We failed to scale critical components before demand exceeded their capacity.”

Two details stuck with me:

  • Monthly commits went from 1.4 billion in April to 2.9 billion, in roughly four months. A platform that has been running for nearly two decades saw commits double in a season, and its usual capacity planning couldn’t keep up.
  • During recovery, errors in Copilot clients triggered automatic retries, and the retries amplified traffic. Machines don’t pause and come back later the way people do during an outage. They keep trying.

At Universe, GitHub said it has added 4 million CPU cores, 160 PB of high-speed storage and 50 Tb/s of network capacity so far this year, and is moving to a multi-region Azure deployment due to finish early next year. A GitHub engineering post in October called agent-driven development “the next architectural shift” and noted that, compared with reads, “writes are way harder.”

I take this as a warning in its own right. GitHub is one of the companies that understands code collaboration best, and its systems were built for the pace of people writing code. Switch to agents writing code and by August it buckled. Most companies’ internal review processes, CI capacity and release cadences were also built for human pace.

GitHub’s answer: let agents review agents

Most of what GitHub launched this week responds to that problem:

  • The Copilot app. Runs agent sessions in parallel across multiple repositories, and a single session can continue across the GitHub app, VS Code, the CLI and the web.
  • Copilot Fusion. Picks models step by step within a task. GitHub says Fusion Max scored within two points of Claude Opus 5.5 Max on the Artificial Analysis Coding Agent Index, at half the cost and with 40% less time per task. That’s the vendor’s own claim.
  • Copilot code review Max. GitHub says it posted the highest F1 score on ReviewBench for high-severity issues.
  • Usage-based pricing. GitHub Enterprise customers no longer need a separate Copilot subscription and pay for the AI credits they use. It’s sold through GitHub’s sales team for now, with self-serve “coming soon.”

Put together, the logic is clear. Coding agents created a review problem, so sell a reviewing agent, metered by usage. The report echoes it: AI-assisted code review and GitHub Advanced Security each grew more than 90% year over year.

I don’t think that’s wrong. Machine review catches a lot of basic problems and never gets tired. But it solves “too much to read,” not “who is accountable.” If an agent writes a PR, another agent reviews it, and a person clicks merge, can that person explain what they approved when something breaks? Tools can’t answer that.

The former CEO’s answer: drop the pull request

Two days before Universe, on October 26, Entire, the startup founded by former GitHub CEO Thomas Dohmke, launched its own Git hosting platform.

Entire raised a $60 million seed round at a $300 million valuation in February, led by Felicis. In the announcement, Dohmke said “massive volumes of code are being generated faster than any human could reasonably understand.”

The centerpiece of the launch is Trails, which replaces the traditional pull request. By Entire’s description, instead of people reviewing change requests one by one, agents run a set of customizable evals on every push and score them, and humans watch a dashboard the company likens to an airline pilot’s heads-up display. Entire also claims pushes up to 89 times faster than GitHub, again a vendor benchmark with no independent check.

As I read it, Dohmke’s bet is that the pull request, where one person submits and another reads line by line, was designed for people working with people and should be replaced for the agent era. GitHub’s bet is that the pull request stays and the reviewer becomes an agent. The answers point in different directions, but they concede the same thing: reviewing code line by line at human speed no longer keeps up.

I lean toward Entire’s direction, but it’s a product that just launched. Private repositories work; public repositories and self-hosted nodes are still on the roadmap. What deserves attention is the question it raises: if people stop reading code line by line, what should they look at instead?

For people who run engineering teams

In AI-native means rewriting the organization I argued that AI amplifies whatever bottleneck an organization already has: make coding ten times faster and everything around coding still sets the pace. GitHub’s data now points squarely at which part: review. A few things I think teams can do now:

  • Measure your own numbers first. What share of PRs are agent-drafted, how big they are, how long from commit to merge, how many each reviewer handles per week. Without that, “we’re more productive” is a feeling.
  • Write down who is accountable for a merge. For a PR written by an agent and reviewed by an agent, spell out what the person who clicks merge is responsible for. At minimum, they should be able to explain in their own words what the change does and where the risk is.
  • Tier by risk. Docs, tests and dependency bumps can lean on machine review. Changes touching permissions, payments, data deletion or external interfaces need a person who actually reads them. Octoverse counts more than 30 million merged Dependabot PRs this year; that kind of change was always a good fit for heavy automation.
  • Cap PR size. Agents happily change dozens of files at once, and the bigger the diff, the more likely a reviewer just approves it. Breaking work into smaller pieces does more than asking people to “review carefully” after the fact.
  • Make agents leave the why. The requirement, the prompt, the approaches tried and abandoned should travel with the code. That’s what Entire’s first product, Checkpoints, was built to do. Even without it, a PR template can require it.
  • Price review, not just generation. With usage-based billing, both writing and reviewing burn credits. Don’t only count how many engineers code generation saves; count how much review costs in money and people.

If you maintain an open source project, the Linux Foundation data says you’re not alone. Setting rules for AI contributions early, such as requiring disclosure and requiring contributors to run the tests themselves, is far less work than rejecting PRs one at a time later.

Final thoughts

A few days ago I wrote about a bug AI found in a week that took two months to fix. Today’s numbers are the other side of the same story. AI has made output cheap. Confirming that the output is right still costs human time, and there isn’t more human time.

The 40% will probably be 60% or 70% next year. By then, the ceiling on a company’s engineering capacity may depend less on how many people write code and more on how many people, and how many mechanisms, can stand behind the code that gets merged.

The question I’d put to any team right now: of the code you merged last month, how much did someone actually understand?

References

  • GitHub, Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents, 2026-10-28
  • Jay Parikh (GitHub Blog), GitHub Universe 2026: Evolving every layer of the stack, 2026-10-28
  • Vlad Fedorov (GitHub Blog), The August 17 outage, and the work ahead, 2026-08-20
  • Brian Celenza (GitHub Blog), Building Git infrastructure for agent-scale development, 2026-10-06 (updated 10-26)
  • The Next Web, GitHub launches Copilot Fusion as agents start 40% of pull requests, 2026-10-28
  • The Linux Foundation, New LF Research survey shows generative AI cuts open source coding time in half, but 25% of incoming pull requests are considered AI slop, 2026-10-20
  • TechCrunch, Former GitHub CEO raises record $60M dev tool seed round at $300M valuation, 2026-02-10
  • ITPro, Former GitHub CEO Thomas Dohmke’s startup just unveiled a GitHub alternative – and AI agents are front and center, 2026-10-26
  • GitHub, Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1, 2025-10-28