GitHub’s 220 Million Merged PRs: What Actually Shipped?

By Lazar Milicevic · Published October 29, 2026 · 8 min read

GitHub put a huge number on the Universe stage: 220 million merged pull requests per month. That tells you how much code is being accepted into branches. It doesn't tell you whether an email became a correct invoice, or whether a lead got one follow-up instead of two. If your afternoons disappear into email, invoicing, and follow-up, the useful question isn't how much code agents wrote. It's whether the job finished without you copy-pasting between tabs.

Here's exactly how I think about that, and one acceptance test you can write today before you commission any automation.

What GitHub actually reported (and what it didn't)

On October 28, 2026, at GitHub Universe, executive vice president Jay Parikh presented figures from the Octoverse 2026 report. Simon Willison's write-up of the keynote captures the slide: 220 million merged PRs per month, and commits more than tripling to 7.38 billion per month. New repositories doubled to 30.3 million per month.

The numbers are large, so it pays to be careful about which number is which. The GitHub Blog's Octoverse post reports annual figures for the Octoverse year (October 1, 2025 to September 30, 2026):

That 1.3 billion merged PRs works out to an average of 3.5 million a day. Unless noted, the metrics include public and private repositories.

Now the awkward part. 1.3 billion divided by 12 is roughly 108 million, not 220 million. I couldn't find the 220 million monthly figure in the GitHub blog text I read. It comes from the keynote slide as relayed by Willison. The most likely explanation is that the monthly figure reflects a recent peak month rather than the yearly average, since volume was climbing fast through the year. But that's my inference, not something GitHub stated. So I'll keep the labels straight: 220M is a keynote-slide monthly figure; 1.3B is the annual total. Don't add them, divide one by the other, or quote them as if they were measuring the same thing.

Two other cautions from the report itself:

• The agent count is a floor. GitHub's methodology only counts agents it can detect. The true share could be higher.
• Industry breakdowns are estimates. Repositories were sorted into industry sectors by an embedding model reading names, descriptions, topics, and READMEs.

And the biggest caution: none of this measures hours saved in a business. A commit records a change. A merged PR records that a change was accepted into a branch. Neither says whether an invoice was right.

What the agent numbers do say

The more interesting data isn't the headline total. It's the shift in who starts the work.

According to the Octoverse blog post, by September 2026 more than 40% of GitHub pull requests started with an agent's first draft, up from 17% in March. That was 110 million PRs in September alone, about 6x March's volume.

Agent-started PRs also look different from the rest:

• They change multiple files more often: about 87%, versus 79% for PRs without detected agent involvement.
• Agent-authored PRs merged within two weeks rose from 83% in February 2026 to 90% in September 2026. The comparison group without detected agent involvement sat at about 86% in both periods.

It's tempting to read the 90% as quality. Don't. A merge rate tells you a human or a process accepted the change. It says nothing about defects, reverts, or whether the work turned out to be useful.

There's also a quieter detail: the blog notes developers merged more than 30 million Dependabot pull requests in the year, about double the pace of 2025. Dependabot PRs are routine, mechanical dependency updates, and they're included in the merged PR count. Part of that giant number is automation maintaining automation. That's useful work, but it's a reminder that "220 million" isn't 220 million units of product value.

The part GitHub is signaling that matters for your business

Buried under the volume stats is a framing shift. A news summary of GitHub's Universe messaging describes the intended output as completed work, not more code. In the Universe keynote post, Parikh described GitHub's "agentic software delivery system" as solving for three things: velocity, intelligence, and quality. The new Copilot app is described as connecting agents and tools across projects so users can direct the work without making every handoff themselves.

That last phrase is the one to hold onto: without making every handoff. Handoffs are exactly where small businesses lose their afternoons. Per the Universe recap, Copilot automations run in the cloud and can be started manually, triggered by an event, or scheduled, coordinating agents for tasks like issue triage and code review.

Even GitHub is saying the goal is fewer handoffs and finished work. So judge your own automations by the same standard.

One more caution on scope: the Octoverse measures software development activity only. Nothing in it says anything about automating email, invoicing, or lead follow-up for a small company. The report's industry breakdown is a good example of why to be careful. Construction had the highest share of agent-opened PRs at about 9%, but that statistic applies to repositories sorted into the construction sector, not to construction businesses adopting AI. I'd treat that statistic as a curiosity, not a signal for your shop.

Why activity metrics mislead small teams

Take one narrow job: turning a customer's email into a draft invoice.

Today, someone reads the message, finds the customer, copies the billing details, enters the line items, and asks about anything missing. Gmail, the customer database, accounting software, and chat don't talk to each other. The person is the integration.

If that sits inside two to four hours a day of email, invoicing, lead follow-up, and reporting, hiring feels like the only way out. But hiring is slow and expensive, generic software often misses your particular billing rules, and you may have already tried ChatGPT only to discover that a good answer in a chat window doesn't update your accounting system.

An agent can help build the connectors. But a connector that exists is not an integration that works. Here's the gap, using an illustrative example with round numbers: a customer emails asking for ten hours of work at $80 an hour. The draft subtotal should be $800. Tax treatment follows whatever your accounting rules say. Now consider the cases that break naive automations:

• Ambiguous customer. Two clients share a first name. The workflow should route to review, not guess.
• Duplicate email. The same message arrives twice (forwarded, or re-sent). The workflow should find the existing draft. Creating a second invoice turns a time-saving tool into an accounting problem.
• Missing billing detail. No VAT number, no PO reference. The workflow should say which field is missing.
• Correction. "Actually, it was 12 hours." The workflow should link to the earlier request and ask for review before replacing anything.

Manual entry mistakes already create compliance and audit risk. Automating the same mistake just makes it repeat faster. What you need is validation, a record of what happened, and a clear handoff when the system can't decide.

The five-case acceptance test

Here's the one thing you can do today, before asking an agent or a developer to build anything: write the acceptance test.

Pull five historical requests you're allowed to use. Strip unnecessary personal information. Choose them deliberately:

1. One complete request
2. One missing a billing detail
3. One with an ambiguous customer
4. One duplicate
5. One correction of an earlier request

Beside each, write the result you expect, in plain language or a small file:

# acceptance_invoice_draft_v1.yaml
cases:
  - id: complete
    input: emails/complete_request.txt
    expect: one draft invoice, subtotal matches hours x rate, status=draft
  - id: missing_detail
    input: emails/no_billing_ref.txt
    expect: no draft; review task naming the missing field
  - id: ambiguous_customer
    input: emails/two_possible_clients.txt
    expect: no guessed match; review task listing candidates
  - id: duplicate
    input: emails/complete_request_forwarded.txt
    expect: no second draft; log entry pointing to existing draft
  - id: correction
    input: emails/revised_hours.txt
    expect: link to earlier request; review before any replacement
gates:
  send_to_customer: human_approval
  final_posting: human_approval

Run those cases in a test environment. Keep sending and final posting behind human approval for this first version. Then record four things:

• How many drafts are correct
• How many exceptions were routed correctly
• Whether any duplicates appeared
• How much human handling remains

A simple results log is enough:

# results.csv
case,expected,actual,pass,human_touch_minutes
complete,1 draft,1 draft,yes,1
missing_detail,review task,review task,yes,2
ambiguous_customer,review task,guessed match,NO,0
duplicate,no 2nd draft,2nd draft created,NO,0
correction,linked review,linked review,yes,2

Five cases won't prove production reliability. That's not their job. They give you a concrete first gate and expose obvious failures before a customer sees them. In the made-up log above, the two failures are exactly the ones that cause real accounting damage, and you'd have found them in an afternoon instead of at month-end.

How to use this when someone pitches you an agent-built tool

Notice what you have now: five inputs, five expected outcomes, and an actual result for each. That's an artifact you can judge. Working code, working system. It's a stronger conversation than "the agent produced 400 commits this week," and it works whether you hire a freelancer, buy a tool, or build with an agent yourself.

A few rules I apply when I'm the one building:

• Define finished before you start. "Draft invoice appears in accounting with correct subtotal, or a review task explains why not" is finished. "Integrate Gmail with accounting" is a task description.
• Make exceptions a first-class output. A queue of "I couldn't decide" items you understand is a feature. Silent guessing is the bug.
• Log every decision. You should be able to trace each amount back to the original email.
• Expand the test set when reality surprises you. Every production failure becomes case six.
• Don't confuse a high merge rate with a high success rate. GitHub's own data shows why: acceptance into a branch isn't the same as the work holding up.

My take

When code activity reaches numbers this large, counting activity becomes less useful for deciding what to automate. The skill that's getting more valuable is defining a small job precisely enough to verify it. For a solo founder, the win is one recurring task that finishes correctly while you're doing something else, with exceptions waiting in a queue you understand.

Use GitHub's numbers as a prompt to raise your standard for delivery. Start by making one workflow earn your trust.

Want more like this?

I share practical AI automation notes and working builds.

Planning an AI automation project or need a second opinion on your architecture? I'm Lazar Milićević, a senior engineer who builds AI automations that ship.

Visit bizflowai.io for services, case studies, and AI consulting.