GitHub Octoverse 2026: Agents Now Start 40 Percent of Pull Requests
GitHub's Octoverse 2026 report says agents started more than 40 percent of pull requests in September, and the bottleneck has moved from writing code to reviewing it.

GitHub Octoverse 2026: agents are writing the first draft
The GitHub Octoverse 2026 report puts a number on something developers have felt for months. More than 40 percent of pull requests on GitHub started with a coding agent's first draft in September 2026, up from 17 percent in March. That is about 110 million agent-started pull requests in a single month, roughly six times March's volume, according to GitHub's report, published October 28.
The reporting year runs from October 1, 2025 to September 30, 2026, and covers public and private repositories unless noted. In that year, developers pushed code 17.9 billion times, made 34.3 billion commits, and merged 1.3 billion pull requests, an average of about 3.5 million merges a day. Those totals are, by GitHub's account, the biggest in the platform's history. The agent share is the headline, but the volume underneath it is what changes daily work: when drafting gets this cheap, everything downstream gets busier.
What the agent numbers actually show
The details matter more than the headline. Agent-started pull requests are more likely to touch multiple files: about 87 percent do, against 79 percent for pull requests without detected agent involvement. They also merged slightly faster by September, with 90 percent of agent-involved pull requests merging within two weeks, against about 86 percent for the rest. In February, the agent group was slightly behind on that measure, at 83 percent, so the gap closed and then reversed over the year.
Copilot usage tells the same story from the user side. About 55 percent of Copilot's monthly active users now use agentic features, up from 35 percent a year earlier, and use of the Copilot cloud agent, where a developer hands over a whole task and the agent works independently, grew 230 percent year over year, against 85 percent for agent chat. AI-assisted code review and GitHub Advanced Security usage each grew more than 90 percent year over year, which suggests teams are buying review help as fast as they buy drafting help.
Open source grew too. Contributions to public repositories reached 2.5 billion in 2026, more than double 2025's 1.12 billion. The open source agent tools themselves are part of that growth: opencode passed 200,000 stars by late 2026, and OpenAI's Codex CLI and Google's Gemini CLI are open too, with six-figure star counts. The reference implementations of the agent era are public code that anyone can fork, which is a very different world from the closed tools of a few years ago.
The bottleneck moved to review
If agents write the first draft, humans still own the merge decision, and that is where the pressure now sits. Every agent-started pull request still needs a reviewer, a merge decision and an owner, and the review load grows with the draft volume. A team that used to review a handful of human pull requests a day can now face dozens of agent drafts, each touching more files than a typical human change.
Independent data complicates the rosy merge-rate picture. LinearB's 2026 benchmarks, built from 8.1 million pull requests across more than 4,800 organizations, report that AI pull requests wait 4.6 times longer before review, then are reviewed twice as fast once someone picks them up, with acceptance rates of 32.7 percent against 84.4 percent for manual pull requests. That dataset covers a different population, organizations that pay LinearB to instrument them, so it does not directly contradict GitHub's numbers. But it points at the same truth from the other side: drafting is no longer the constraint, and review quality is where teams win or lose.
There is also a measurement caveat that applies to every GitHub number here. These are GitHub's own platform measurements, not an independent audit. Detected agent involvement is a floor, since GitHub counts only agents it can detect, so the true agent share is higher, and the comparison group almost certainly contains undetected agent work. A merge rate is also not a quality metric. A change can merge quickly and still be wrong, insecure, or expensive to maintain.
What teams should change now
The practical response is not to ban agent drafts or to wave them through. It is to redesign review for a world where drafts are abundant:
- Keep pull requests small, even when the agent offers a big one. A 20-file change that an agent produced in minutes still takes a human a long time to review properly. Ask for smaller, focused changes.
- Require tests and CI checks to pass before human review starts. Automated gates catch the errors that are cheapest to catch, and they keep reviewers focused on design and risk.
- Assign clear ownership for every merged change. An agent can draft, but a named human should be accountable for what ships.
- Review the diff, not the description. Agent-written summaries are fluent and confident, which makes them easy to trust and easy to skim. Read the actual code.
- Track reverts and post-merge fixes separately from merge speed. If agent changes merge fast but get reverted more often, speed is hiding a quality problem.
Those habits were good practice before agents, but they were optional when draft volume was low. Now they are load-bearing.
The practitioner view
For individual developers, the Octoverse numbers suggest a skill shift rather than a job loss story. Writing boilerplate and first drafts is increasingly automated, while reviewing, debugging, designing and owning systems become more valuable. The developers who thrive will be the ones who can judge agent output quickly and precisely, and who know when to reject a plausible-looking change.
That shift connects to the wider agent tooling wave, from GitHub's agentic workflows to DeepSeek's autonomous coding agent. The tools are converging on the same model: describe the job, let the agent draft it, and supervise the result. The Octoverse report is the first large-scale evidence of how far that model has already spread, and how much of the work has moved to the review queue. Teams that staff and tool for review, rather than just for drafting, will be the ones that benefit most from it.


