GitHub Octoverse 2026: 40% of pull requests now start with an agent

You open a project’s list of pull requests (the requests to merge a change into the main code) and half of them say an agent prepared them. It isn’t an unusual project: it’s what’s happening across all of GitHub. And if you still write every change by hand, GitHub’s Octoverse shows how common working this way already is.

On October 28, GitHub published the Octoverse 2026 (opens in a new tab), its annual report on how people code on the platform. Below are the numbers for the last year, how they fit with the Harvard study discussed this month, and what the projects where working with agents goes well have in common. It’s a ten-minute read and three changes you can make to your repository this week.

What the Octoverse is

Every year, GitHub measures what happens on its platform: how many people code, in which languages, how much code gets pushed, and how the way people work is changing. This year covers the twelve months ending September 30, 2026, and there are now more than 225 million developers. Satya Nadella, Microsoft’s CEO, presented it at GitHub’s annual conference.

The report states its main conclusion in one sentence: “The first move is now directing an agent, and review is how developers shape what comes back.”

The numbers

Agents now start the work, not just help with it. In March, 17% of pull requests started with a first draft made by an agent. In September, 40%: about 110 million in a single month. That’s more than double in six months.

Commits, pushes and merged pull requests tripled. Compared with the previous year:

Over twelve months	2025	2026
Commits (changes saved to history)	12.9 billion	34.3 billion
Pushes (changes sent to GitHub)	6.7 billion	17.9 billion
Merged pull requests	538 million	1.3 billion

Agent changes are broader. 87% of pull requests started by an agent touch more than one file, versus 79% of those started by a person.

And they get merged. This is the number that drew the most attention: in February, 83% of agent pull requests were merged within two weeks, versus 86% of hand-written ones. By September, agent pull requests reached 90% and pulled ahead.

Why the Octoverse doesn’t contradict the Harvard study

The Harvard study found that, with agents, each pull request took 49% longer to merge. The Octoverse shows that agent pull requests get merged faster than the rest. The two findings are compatible, because they measure different things, at different times and in different populations:

• They measure something else. Harvard measured how many days a pull request takes to merge on average. The Octoverse measures what share gets merged within two weeks. If a team used to merge in three days and now takes five, for Harvard it got slower. For the Octoverse nothing changed, because both cases fall within “under two weeks”.
• They look at a different moment. Harvard’s data runs through March 2026, when only 17% of pull requests started with an agent. Since then the models, the tools and, above all, the way teams work have improved.
• They look at a different population. Harvard studied 718 companies using internal data from a metrics platform. The Octoverse counts all of GitHub, including millions of personal projects where the same person writes and merges.

There’s one more caveat. In its methodology section, the Octoverse explains in detail how it worked out countries and industries, but not how it decides that a pull request “was started by an agent”. It’s worth reading those numbers as a clear direction, not an exact measurement.

What the projects where it works do differently

More interesting than the 40% is what the report reveals about how the teams that do well actually work.

They explain the project to the agent

Repositories that have configuration files for agents (an AGENTS.md, for example, saying how to run the tests, what conventions the project uses, and what not to touch) have eight times more commits than those that don’t.

That doesn’t mean the file multiplies the work: most likely, the most active projects are the ones that write it. It still makes sense: an agent that knows how the project works makes fewer mistakes. This article covers the six changes that help a repository most, and what’s worth putting in that file.

They send small changes, one after another

More than 264,000 developers already use stacked pull requests on GitHub. Instead of one huge change, you send a chain of small changes, each building on the previous one. For example: first the database change, then the logic that uses it, then the screen. Each gets reviewed in minutes, and you don’t have to wait for the first to be approved to keep working on the second.

It’s the direct answer to Harvard’s problem: if review is the bottleneck, the solution is to send changes that can be reviewed quickly.

They don’t marry a single model

61% of Copilot users now use more than one AI model (it was 50% in May), and the most used model accounts for only 25% of requests. Teams pick a fast model for mechanical work and one that reasons more for planning. It’s what we covered in choosing a coding agent is no longer choosing a model: the tool matters more than the brand of the model inside it.

What else changed

A few more numbers from the report worth knowing:

• TypeScript is still first in new contributors each month (3.6 million), followed by Python (3.2 million). Rust doubled its contributors in a year.
• Brazil now has more than 10 million developers on GitHub, and added 3.3 million this year alone. It’s third after the United States and India.
• Automated security grew too. GitHub scanned 5.8 billion pushes for leaked keys and passwords (four times the previous year’s pace), and more than 30 million pull requests from Dependabot, the bot that updates dependencies with known vulnerabilities, were merged.

What it changes for you

If you work with agents, or are about to start, the report leaves three concrete takeaways:

1. Your first move will be explaining what you want. If the work starts by directing an agent, the quality of the request decides the quality of the result. It’s worth learning to write a spec that won’t be misread.
2. Review is where the result takes shape. The agent brings a draft; what reaches production depends on what you correct. This list is a good starting point, and this one helps you decide what to delegate and what not to.
3. Prepare the ground. An instructions file for the agent and small changes that can be reviewed in minutes are the two things the report associates with the projects that move fastest.

Who decides what the code should do

There’s a line in the Octoverse that sums up the moment well: “What doesn’t change is who decides what the code should do.” Agents already start almost half the work on GitHub, and that number will keep rising. What doesn’t get delegated is knowing what needs to be built and noticing when what the agent delivered isn’t what was asked for. With 40% of drafts written by an agent, that part of the job doesn’t lose value: it’s the part that gains the most.