40% of Pull Requests Now Start With an Agent: What GitHub's Octoverse 2026 Means for Your Engineering Team

What Did Octoverse 2026 Actually Measure?

On 28 October 2026 GitHub published its annual Octoverse report, and the headline figures are large even by the standards of a platform used by more than 225 million developers. Between October 2025 and September 2026, developers and their agents made 34.3 billion commits, up from 12.9 billion the year before. Pushes reached 17.9 billion, more than 2024 and 2025 combined. Merged pull requests reached 1.3 billion, about 3.5 million a day, more than triple the 2024 figure.

Two methodological details matter before you quote any of this in a board deck. First, this edition counts public and private repositories, and GitHub recalculated its 2024 and 2025 baselines on the same basis, so the numbers are not directly comparable with older Octoverse reports. Second, agent involvement is detected through observable signals. A developer who pastes agent output into a normal commit is invisible to the count, so the real share of AI-assisted work is almost certainly higher than reported.

The shape of the year matters as much as the totals. According to GitHub's engineering team, developers and agents made 7.38 billion commits in September 2026 alone, more than five times the figure a year earlier, and monthly pushes grew 4.9x year over year. Most of the growth arrived in the second half of the year. This was not gradual adoption. It was a step change that most engineering organisations are still absorbing.

This article is a companion to our earlier look at what the 2026 Stack Overflow survey means for your team. The survey tells you what developers say. Octoverse tells you what they, and their agents, actually pushed. The two point in the same direction.

From 17% to More Than 40%: Agents Became the Default Author

The single most quoted number from the report is the share of pull requests started by an agent. GitHub reports that it rose from 17% in March 2026 to more than 40% in September, when agents opened 110 million pull requests, about six times the March volume. On GitHub's own Copilot product, 55% of monthly active users now use agentic features, up from 35% a year earlier, and the asynchronous cloud agent grew 230% while interactive agent chat grew 85%.

That last comparison is the more important one. Developers are not just chatting with agents more. They are handing work off and coming back later to review it. That changes the job from writing code to specifying and accepting it, and it means the bottleneck moves to whoever is responsible for saying yes.

The quality signal is better than sceptics might expect. In February, 83% of agent-involved pull requests were merged within two weeks, compared with about 86% for pull requests without agent signals. By September, the agent figure had risen to 90% while the comparison group stayed near 86%. Agent pull requests also tend to be broader: about 87% change multiple files, against 79% of the rest.

Read those numbers carefully. A higher merge rate means agent work is being accepted more often. It does not prove the accepted work is correct, and broad multi-file changes are exactly the kind that are hardest to review well. We have written before about agents making tests pass without making code work. A rising merge rate is good news only if your review process is getting stronger at the same pace.

The Platform Buckled Before Most Teams Did

The clearest evidence that agent volume is a different kind of load comes from GitHub's own incident history. On 17 August 2026, github.com, authentication, Actions, APIs, pull requests, issues and Copilot were degraded for 7 hours and 47 minutes. In its post-incident write-up, GitHub's CTO said traffic reached a new peak and a critical component in its Central US data center failed to scale with it. It was not a bad deploy. Monthly commits had grown from 1.4 billion to 2.9 billion since April, and a client-side retry loop in some Copilot services added traffic during recovery.

Earlier in the year, on 9 April, the Copilot coding agent itself failed in a different way. According to GitHub's April availability report, about 84% of new agent session requests were delayed, queue waits peaked at 54 minutes against a normal 15 to 40 seconds, and about 22,700 workflow creations were delayed or failed. The cause was a rate-limit bug that applied one installation's limit to everyone.

GitHub's response is a redesign of how Git is stored. The October engineering post explains that every replica in the old design takes part in every write, so adding read replicas slows writes down, and that heavy concurrent agent traffic hits that ceiling. Internal benchmarks of the new architecture show up to 35 times higher write throughput. Those are benchmark results, not production numbers.

If the largest code host in the world had to re-architect for agent traffic, your internal systems probably need attention too. CI runners, artifact stores, preview environments, secrets managers and internal APIs were all sized for human cadence. We covered the CI side in our piece on what agent load does to pipelines and the broader pattern in why a retry loop is not a fallback plan. The August incident is a textbook example of both.

Review Is Now the Scarce Resource

Octoverse also shows where teams are investing to cope. GitHub reports that usage of AI-assisted code review and of GitHub Advanced Security each grew more than 90% year over year. Push protection ran 5.8 billion secret scans, nearly four times the 2025 pace. More than 30 million Dependabot pull requests were merged. Stacked pull requests, launched in preview on 30 July, were used by more than 264,000 developers by September.

Every one of these is a tool for handling more change with the same number of reviewers. Stacked pull requests break large changes into reviewable pieces. AI review catches the obvious problems so humans can focus on design and intent. Push protection stops credentials leaking at a volume no human could check. These are sensible responses, but none of them decides whether a change is the right change. That still needs a person who understands the system.

The trust data explains why. In the 2026 Stack Overflow Developer Survey, released on 6 October, only 6.6% of respondents said they are prepared to trust AI with important decisions, and only 24% said their organisation publishes approved tools or an official AI policy. Adoption is close to universal. Governance and trust are not.

For most companies this is a staffing question disguised as a tooling question. If agents now start four in ten pull requests, the ratio of experienced reviewers to generated changes has collapsed, and the senior people doing that review are the ones you can least afford to burn out. This is where a dedicated development team with senior engineers who own review for a defined part of the system can add real capacity, as opposed to more people generating more pull requests for the same few reviewers.

No Single Model Wins Anymore

One of the less discussed findings is how fragmented model use has become. Among Copilot users who choose a model themselves, 61% used more than one in September 2026, up from 50% four months earlier. Paid users tried 47 distinct models in September, up from 29 in May, and no single model accounted for more than 25% of requests, according to the Octoverse data. Developer-selected requests split roughly 38% general purpose, 37% deep reasoning and planning, and 25% fast and lightweight.

GitHub has turned that behaviour into a product. Copilot Fusion, generally available since 28 October, routes each task across models using three patterns: Single, where one model does the work; Cascade, where a cheap model drafts and a stronger one takes over if a quality check fails; and Critique, where one model drafts and a second reviews. GitHub says the Max effort level scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, at about half the average API cost per task.

The lesson for engineering leaders is not that you should adopt any particular router. It is that model choice has become a per-task, cost-versus-quality decision rather than a one-time vendor decision. Teams that hard-code a single provider into prompts, evaluation suites and agent configuration are building the lock-in we described in our article on model portability.

It also changes how you should read cost. If routing can halve the cost per task at similar quality, the question to ask a vendor or a development partner is not which model they use, but how they decide which model to use for which job, and how they measure whether the cheap option was good enough.

TypeScript Gets the Agents. Java Gets Less Help.

TypeScript is now the most used language on GitHub by monthly contributors, ahead of Python and JavaScript, and it added 3.62 million contributors between September 2025 and September 2026. Rust roughly doubled. More interesting is the link between language and agent use. In GitHub's data, AI was involved in 44.1% of merged TypeScript pull requests, 41.1% for Python and 40.4% for Rust, but only 21.2% for Java.

There are several plausible explanations, and the report does not settle between them. Java codebases tend to be older, larger and more often inside enterprises with stricter tool policies. They also often carry more implicit context: frameworks configured by convention, integration code, and business rules that are not written down. Agents perform best where the code is typed, well tested and self-describing, and worst where knowledge lives in people's heads.

For companies running large Java, C# or C++ estates, this is a warning about an uneven productivity gap. Your competitors on newer stacks may be getting twice the agent leverage you are. The fix is rarely a rewrite. It is usually the unglamorous work of making the existing system agent-readable: better tests, clearer module boundaries, documented conventions and build commands that run reliably. We set out that checklist in your AI agents aren't the bottleneck, your repository is.

One Octoverse data point supports that approach, though it shows correlation rather than cause. Among repositories created in 2026, those with an agent configuration file averaged eight times as many commits as new repositories without one. Teams that write down how their codebase works for agents are, at minimum, the teams getting the most activity out of them.

The Industry Gap: Talking About AI Is Not Using It

The industry breakdown contains a useful reality check. Public repositories grew from 9.0 million in 2022 to 25 million in 2026, with fast growth in sectors such as construction, mining, healthcare and agriculture. But GitHub found that in administrative services, mining, healthcare and agriculture more than 40% of repositories mention AI, while fewer than 3% of their pull requests are opened by agents. Construction had about a quarter of repositories mentioning AI and about 9% agent-opened pull requests, the highest share of any sector.

In other words, many industries are building AI into their products faster than they are using AI to build their products. That matches what we see in practice. Mid-sized companies outside the software sector often have an AI feature on the roadmap, a small internal team, and no agent workflow, review standard or evaluation process for their own engineering.

That gap is an opportunity. A team in a regulated or traditional industry does not need to repeat every mistake the software sector made in 2026. It can adopt agent workflows with the review discipline, secrets hygiene and capacity planning already in place. This is exactly the kind of engagement where an experienced nearshore development partner helps: senior engineers who have run agent-heavy delivery elsewhere, working in your time zone, alongside the people who know your domain.

What Should Engineering Leaders Do Before 2027?

Octoverse is a description of the past year, not a plan. But the data points to a short list of decisions that most engineering organisations should make in the next two quarters, regardless of which tools they use.

First, measure review capacity as seriously as you measure output. Track time to first review, review depth and the share of changes merged without meaningful human review. If agent pull requests are rising and those numbers are getting worse, you are borrowing against future incidents. Our analysis of the verification capacity gap covers how to size this.

Second, load-test the systems agents touch. GitHub's outages were capacity failures triggered by success. Run the same exercise on your CI, preview environments and internal APIs at three to five times current volume, and put retry budgets on every agent client.

Third, treat model selection as an engineering decision with an evaluation behind it, not as a procurement choice. Fourth, invest in making legacy codebases agent-readable before concluding that agents do not work on them. And fifth, write down who owns acceptance. When four in ten changes start with an agent, "the team reviewed it" is not an answer an auditor, a customer or an insurer will accept.

Stepto's dedicated teams are built around these constraints. We staff senior engineers who own review and architecture for a defined scope, use agents heavily for implementation, and report on review and quality metrics rather than raw output. Because our engineers work from Serbia with a full overlap with European business hours and a usable overlap with the US East Coast, review does not wait overnight.