40% of Pull Requests Now Start With an Agent: What Octoverse 2026 Shows, and What It Does Not

In one sentence: the starting point of coding changed, and review got heavier

GitHub's Octoverse 2026 annual report, published on October 28, 2026, contains a number every developer should pause on: by September 2026, more than 40% of pull requests (PRs) on GitHub started with an agent's first draft, up from 17% in March. In six months, agents went from occasionally helping with a snippet to drafting the first version of a large share of the work.

The report covers the full year from October 1, 2025 to September 30, 2026, across public and private repositories. Its weight does not come from any single number, but from a whole set of numbers pointing the same way: developer work is shifting from writing every line by hand to setting direction for agents and reviewing what comes back. This article first lays out the key numbers, then what they actually mean for ordinary developers and for vibe coders, and which conclusions you should not draw from them.

The headline numbers: 40%, 110 million, sixfold

Start with the three core numbers. First, in September 2026, more than 40% of PRs started with an agent's draft, versus 17% in March. Second, in September alone, agents started 110 million PRs, roughly six times the March volume. Third, agent-started PRs more often touch multiple files: about 87%, compared with 79% of PRs without detected agent involvement.

Read together, the three numbers tell a story about share, scale, and speed. Forty percent is the share, 110 million is the volume, and sixfold is the pace. In half a year, agent-drafted volume multiplied by six. That is not one team's experiment. It is the whole platform bending at once. GitHub notes that platform activity accelerated from around June, when better models, more mature agent tooling, and cloud execution arrived together.

One detail is easy to miss: GitHub counts agent involvement it can detect. The 40% figure counts PRs whose first draft came from a detectable coding agent. Agents it cannot detect are missing, so GitHub itself presents the figure as a floor, not an exact value. The real share is higher, not lower. Keep that discount in mind, because several judgments below depend on it.

Merged fast is not the same as merged well

Another set of numbers is often quoted as proof that agent code is better, but it only proves that it merges faster. In February 2026, 83% of agent-involved PRs merged within two weeks, slightly behind the roughly 86% for PRs without detected agent involvement. By September, agent PRs had risen to 90% merging within two weeks, while the comparison group stayed near 86%.

Merge speed measures how fast work reaches the main branch, not whether it works in production. The report publishes no revert rate, defect rate, or incident rate for agent code, so anyone using "merges faster" to argue "written better" is adding imagination on top of the numbers. Reviewers should keep the two things apart: a smoother pipeline is good news, but quality still has to be proven with tests, review, and production behavior.

Meanwhile, agent PRs touching more files is a real burden on reviewers. More files mean more context to check and more chances to miss something. The report also describes the tooling response: Stacked PRs, which split related work into smaller changes that are easier to review in sequence, launched in preview on July 30 and had been used by more than 264,000 developers by September. Usage of AI-assisted code review and GitHub Advanced Security both grew more than 90% year over year. The platform is building review tooling because it knows the bottleneck has moved from "cannot write it" to "cannot review it fast enough."

The full-year scale: it is not only PRs growing

Focusing only on PRs understates the scale of the change. In the reported year, developers pushed code to GitHub 17.9 billion times, more than in 2024 and 2025 combined. Commits reached 34.3 billion, more than three times the level two years earlier. Merged PRs reached 1.3 billion, an average of 3.5 million a day. GitHub Actions ran 45.4 billion jobs, an average of 1,440 every second.

Together, these numbers draw a picture of output accelerating across the board, with agents as one accelerator among others. Another comparison is striking: among repositories created this year, the average repo with an agent configuration file logged eight times as many commits as the average new repo without one. That comparison does not prove the configuration caused the output, since teams willing to configure agents may already be more active. But it does show that teams set up for agent collaboration from day one move at a markedly different pace.

The human scale grew too. GitHub now serves more than 225 million developers. The United States (38.3 million) and India (32 million) remain the two largest communities, each adding more than 10 million developers this year. Public contributions reached 2.5 billion in 2026, more than double last year's total. The agent story is not "machines replacing people." It is "more people doing things with machines."

Model choice is changing too: nobody uses just one model

The report's section on model choice is directly useful for anyone who picks models daily. In September 2026, among Copilot users who selected a model themselves, 61% used more than one model in the month, up from four months earlier. Paying users used 47 distinct models in September, up from 29 in May. No single model carried more than 25% of requests that month.

The era of "pick the best model and stick with it" is over. Developers match models to tasks: some need deep reasoning and planning, some need general capability, some need speed and lightness. Grouping requests by what models are built for, the report finds 38 out of every 100 developer-selected requests went to general-purpose models, 37 to deep reasoning and planning models, and 25 to fast and lightweight models. Few developers stay with one kind for long.

For vibe coders, the practical lesson is to stop asking "which model is strongest" in the abstract, and start asking "which kind of model fits this task." Building a small tool and refactoring an old system are not the same job, and forcing one model through both is like cutting everything with one knife. The report also notes that 63% of paying Copilot users tried automatic model selection at least once in September. That is the same direction as Copilot Fusion, covered in a separate article about its launch: the system picks models step by step, and you set the effort level. The launch article describes the feature; this report shows the platform-wide data behind it.

Languages: TypeScript, Python, and Rust lead

On languages, TypeScript remains first by contributors, followed by Python and JavaScript. From September 2025 to September 2026, TypeScript added 3.62 million monthly contributors, Python 3.23 million, and JavaScript 1.82 million, the largest gains among the top ten languages. By percentage, Rust grew fastest, doubling over the past year.

The link between language growth and AI involvement is worth noting. Among the fastest-growing language communities, the share of merged PRs with detected AI involvement is also highest: about 44% for TypeScript, 41% for Python, and 40% for Rust. Java, C#, and C++ sit lower but still above 20% each. In repositories created in 2026, TypeScript was the primary language in 35% of those with an observed agent signal, versus 24% without one.

There are two ways to read that. One is "agent users prefer TypeScript." The other, which the report leans toward, is "agents prefer TypeScript," because type information makes agent output easier to check. The practical tip for vibe coders is simple: if you let an agent choose freely, it will probably hand you TypeScript. If you want another language, say so up front instead of rewriting afterward.

Four practical consequences for ordinary developers

First, review skill becomes the core skill. One person used to be limited by how much code they could write in a day. Now agents can draft far more than one person can review in a day, so the bottleneck sits at review. People who can split PRs well, write clear review comments, and hold quality with tests will be worth more than people who only write code fast. Writing still matters, but its share shrinks while review's share grows.

Second, PRs need to get smaller. Agents naturally change many files at once; the 87% figure is the evidence. If you let an agent hand over a change touching dozens of files, review becomes skimming, which is the same as no review. The practical fix is to have the agent split work by feature into a sequence of small PRs, or use tools like Stacked PRs, with each PR doing one thing, with a title and description that say what changed, why, and how it was tested.

Third, acceptance criteria should come before code. An agent's first draft often "looks like it runs," while edge cases, error paths, and data migrations hide the real problems. Before the agent starts, write down what must pass tests, which interfaces must not change, and how to roll back. That costs far less than reviewing line by line afterward, and it matches advice repeated across many earlier guides: the more specific the instructions, the less rework.

Fourth, do not be scared by "40%," and do not be fooled by it either. Being scared means thinking "learn agents or be replaced," when the report is about drafting, not about independently finishing and owning work. Being fooled means thinking "I never need to write code again," when merging, owning, and covering production failures still fall on people. GitHub closes the report with the same point: deciding what the code should do, whether it works, and whether it belongs is still the developer's job. The tools changed. The responsibility did not.

A specific note for vibe coders

Vibe coders lean on agent drafting more than traditional developers, so this report hits them more directly. Three points deserve emphasis.

First, your project should have an agent configuration file from day one. The eightfold commit figure cannot be read as cause and effect, but it does point to a useful habit: writing the agent's working style, standards, and boundaries into the repository beats inventing instructions fresh in every chat. The configuration file is the agent's long-term memory. Do not rely only on temporary chat instructions.

Second, small projects need a review step too, even if the reviewer is just you. A one-person-plus-agent project is the easiest place to skip review: the code is agent-written, it seems to run, so it gets merged. But the tendency to change many files at once applies to small projects as well. Set yourself a rule: every PR gets its tests run, its changed-file list read at least once, and a check that nothing it should not touch was touched. That takes under five minutes and catches most basic mistakes.

Third, use more than one model, but do not chase every new release. The data on 47 models and 61% multi-model users shows that mature practice means matching models to tasks: light models for quick jobs, stronger reasoning models for hard jobs, general models for everyday work. At the same time, do not be pulled along by a new model's first-week buzz. The report notes that new models take a larger share of requests in their first weeks than the share of developers who have tried them, meaning a small group of heavy early users drives the heat. Waiting until the heat fades before judging whether a model fits you is perfectly reasonable.

Three conclusions you cannot draw from this report

The first is "40% of code is written by AI." The report counts PR drafting sources, not lines of code. It does not say how many lines in agent-started PRs survived, or how many were rewritten by people. Turning "40% of PRs started by agents" into "40% of code written by AI" swaps the unit of measurement.

The second is "agent code is higher quality." The report has no quality data, only merge speed and multi-file share. Faster merging could mean better tooling, or it could mean looser review. Merge rate alone cannot tell the difference. Quality needs test coverage, revert rates, and production incidents, none of which are in this report.

The third is "developers will shrink in number." The report shows the opposite: more than 225 million developers and growing fast, public contributions doubled, and more industries and countries joining. Agents let more people build things rather than reducing the number of builders. What shrinks is the amount of handwriting every line from scratch. What grows is the work of setting direction, checking results, and taking responsibility.

How this differs from the other Copilot news this week

Several GitHub stories landed around October 28, and they blur together. Here is the boundary. The Copilot Fusion article is about a model-routing feature going live. The Copilot Projects article is about a cross-repository collaboration feature. The code review Max article is about a review feature upgrade. The Enterprise-includes-Copilot article is about a billing model change. This article is about none of those features. It is about an annual data report that answers how developers actually use agents across the whole platform. Feature news tells you what you can use. Data reports tell you how people actually use it. The angles differ, and they do not repeat each other.

If you are choosing tools, read the feature news first. If you are judging trends and deciding how your team should work, this data is more useful. Keeping the two apart prevents confusing "a feature launched" with "a practice became common."

What to watch when next year's report arrives

An annual report is valuable not only for this year's numbers but as a baseline for next year. Four numbers are most worth comparing next time. First, whether the agent-started share keeps climbing or levels off somewhere. Second, whether the two-week merge rate and the multi-file share move with it, which will show whether review kept up or fell behind. Third, whether multi-model use keeps growing, which will show whether model choice becomes fully a platform decision. Fourth, whether the share of new repositories with agent configuration files keeps rising, which will show whether setting up for agent collaboration from day one becomes the default. Writing this year's numbers down and comparing them next year beats debating trends in the abstract.

The judgment: drafting moved to agents, decisions stayed with people

The most important takeaway is not the 40% figure but the division of labor behind it: more and more drafting goes to agents, and more and more judgment stays with people. Drafting can be done in bulk. Judgment cannot. A bad draft can be rewritten. A bad judgment may only surface in production. That asymmetry is the real shape of developer work in the agent era.

For individuals, the skill worth investing in is shifting from "write fast" to "judge well": judging whether what the agent handed back is right, complete, and sufficient. For teams, the process worth investing in is shifting from "how to write code" to "how to review, how to split PRs, and how to set acceptance criteria." Those skills do not change every month like models do, but they decide whether using an agent saves time or creates rework.

Back to the report's plainest line: tools will keep changing, and new industries will keep showing up in unexpected places, but what to build, who to build it for, and whether it is good remain the developer's decisions. Agents can draft 40% of PRs, but they cannot decide for you whether those PRs should exist. That decision is the part of the job that remains, and the part that matters most.