# Agents Start 40% of GitHub PRs. Score Engineers on Reviews, Not Merges

_Octoverse 2026 shows agents start over 40% of GitHub PRs. Here are the GitHub signals that still separate strong engineers, plus revised sourcing filters._

- Canonical URL: https://www.refolk.ai/blog/octoverse-2026-agent-pull-requests-score-engineers-on-reviews
- Published: 2026-11-02
- Reading time: 9 min
- Keywords: octoverse 2026 agent pull requests, github profile signals for recruiters, how to evaluate engineers on github, sourcing developers on github 2026, ai generated pull requests hiring

If you screen engineers by GitHub activity, the floor under your filters just moved. GitHub's Octoverse 2026, unveiled by EVP Jay Parikh at Universe, reports that agents started more than 40% of pull requests in September 2026, up from 17% in March. Commit counts and merged-PR totals were the cheapest proxies a sourcer had for "this person ships." Now they mostly measure how much work someone hands to an agent.

## What Octoverse 2026 says about agent pull requests

Agents started more than 40% of GitHub pull requests in September 2026, about 110 million in one month, and agent-involved PRs now merge more often than other PRs. The 40% is a floor, because GitHub only counts agents it can detect.

The headline numbers recruiters need:

- **Agent share of new PRs:** above 40% in September 2026, up from 17% in March.
- **Merge rate:** 90% of agent-involved PRs merged within two weeks in September, against roughly 86% for the rest. In February, agent PRs trailed at 83%.
- **Scope:** agent PRs touch multiple files more often (87% vs 79%).
- **Volume:** September 2026 commits ran about 6x September 2025. Merged PRs ran about 3.9x.
- **Review tooling:** AI-assisted code review usage grew more than 90% year over year.

> **40%+** Share of GitHub pull requests started by agents, September 2026
>
> Up from 17% in March, and a floor, since GitHub only counts agents it can detect.

For anyone working out GitHub profile signals for recruiters, the takeaway is not "GitHub is useless now." Some signals got cheaper to fake or to produce by accident. Others got scarcer, which makes them worth more.

## The 6x figure is a monthly number, not your inflation rate

The widely quoted 6x commit and 3.9x merged-PR jumps compare one month (September 2026) with the same month a year earlier. Across the full year, commits grew about 2.7x and merged PRs about 2.4x, so your thresholds did not inflate 3 to 4x evenly across every candidate.

That correction matters because it tells you which filter to fix first.

| Metric | Sept 2026 vs Sept 2025 | Full year (derived) |
|---|---|---|
| Commits | ~6x | ~2.7x (12.9B to 34.3B) |
| Merged PRs | ~3.9x | ~2.4x (538M to 1.3B) |
| Pushes | ~4.5x | 17.9B total |
| Actions jobs | ~4.8x | Not reported |

The more useful finding is where the growth landed. Since June, about 55% of all commits came from brand-new repositories. New repos with an agent config file averaged 8x the commits of new repos without one.

So the flood is not spread evenly across all developers. It's concentrated in fresh, greenfield, agent-driven repos. A candidate who spun up a handful of side projects with an agent can sail past a commit-count filter that a senior engineer doing careful work on a long-lived codebase barely clears.

The cheapest fix: **count only activity on repos the candidate doesn't own and that are older than about a year.** That one rule removes most of the inflated volume, because it cuts off exactly the slice that grew.

## Merged-PR counts now reward agent-heavy workflows

A merged-PR threshold now ranks agent-heavy candidates higher, because agent PRs merge faster and more often than human ones. It measures workflow choice, not engineering skill.

Look at the trend. In February, agent PRs merged at 83% within two weeks and trailed everything else. By September they merged at 90% and led the rest at roughly 86%. A merged-PR filter can't see who or what wrote the change. It just sees a bigger number.

Language skews it further. The share of merged PRs with AI involvement varies widely:

- TypeScript: 44.1%
- Python: 41.1%
- Rust: 40.4%
- Java: 21.2%

Java's AI share is about half of TypeScript's. If you use one volume cutoff across languages, you'll let in more TypeScript and Python candidates and shut out Java engineers with the same underlying ability. Set volume thresholds per language, or better, stop using them as a primary gate.

## Four signals that still separate strong engineers

The signals that still work are the ones agents can't cheaply produce: reviews given on other people's code, issue threads that change decisions, merges approved by maintainers of gated projects, and honest attribution. If you're asking how to evaluate engineers on GitHub in 2026, start with these.

### 1. Reviews given on repos they don't own

A code review given is a comment or approval a developer leaves on someone else's pull request. It shows they can read unfamiliar code, spot what's wrong, and say so usefully. Reviews on external repos count most, because nobody asked them to be polite to a stranger's code.

### 2. Issue threads that change a decision

Issue threads show judgment you can watch. A strong engineer reproduces the bug, narrows it down, pushes back on the proposed fix, or explains why a feature belongs in a different layer. Volume doesn't matter here. One thread where the maintainer writes "good catch, changing the approach" tells you more than forty drive-by "+1" comments.

### 3. Merges into gated external projects

External merges got scarcer in 2026, and that makes each one worth more. On August 27, 2026, GitHub, in a launch led by Director of Open Source Ashley Wolf, let maintainers disable PRs, limit them to collaborators, or cap how many PRs outside contributors can have open at once. Projects tightened up:

- **Ghostty** (Mitchell Hashimoto) accepts AI PRs only on pre-approved issues.
- **tldraw** (Steve Ruiz) auto-closes all external PRs.
- **curl** (Daniel Stenberg) ended its bug bounty.

A merged PR into a project with these gates is real proof that a maintainer trusted the contributor. The flip side matters just as much: a strong engineer can now have zero external PRs because the projects they care about closed the door. Don't treat a blank external-PR record as a red flag. Go look at their issues and reviews instead.

### 4. Co-authored-by trailers, read as honesty

A Co-authored-by trailer is a line at the end of a git commit message that credits a second author, and some agents use it to mark their involvement. The catch is that it tells you which tool someone uses, not how much AI they use.

- **Claude Code** adds a Co-authored-by trailer by default.
- **Aider** marks its commits too.
- **GitHub Copilot, Codex CLI and Cursor** add nothing.
- **Users strip trailers.** One developer reported 489 tagged commits they planned to rewrite.
- **Foundations use their own labels.** Apache uses "Generated-by:", and OpenInfra uses "Generated-By:" and "Assisted-By:".

If you penalize trailers when screening for AI-generated pull requests, you punish the most transparent candidates and reward the ones whose tools leave no trace. Treat a trailer as disclosure. Then judge the commit on its merits.

## Why reviews are the judgment signal now

Reviews matter most because agent PRs mostly fail on judgment, not on code. A study presented at MSR 2026 (the Mining Software Repositories conference) found that only about 36% of rejected agent PRs had clear failures in the agent's code.

Most of the rest came down to judgment and fit. That's exactly what a good reviewer supplies and what an agent lacks. A candidate who regularly catches those problems in other people's PRs is showing the skill that's now in short supply.

> Agents can write the diff. Someone still has to decide whether the diff should exist.

One caution: AI-assisted review grew more than 90% year over year, so read what the reviews actually say. Strong human reviews tend to:

- Reference project history or a past decision.
- Push back on scope, not just style.
- Ask for a specific test that would catch a specific edge case.
- Get a reply from the author that changes the code.

Generic summaries of what the diff does, with no request for change, are the review equivalent of padded commit counts.

## You can't find maintainers by job title

Self-described open source maintainers are almost impossible to find with a profile keyword search. In Refolk's index of professional profiles, only 293 people across the US, India and Germany use "open source maintainer" in their headline, against 225 million developers on GitHub.

> **293** Profiles with "open source maintainer" in the headline across the US, India and Germany
>
> From Refolk's index of professional profiles, compared with 225 million developers on GitHub.

| Market | Profiles | vs. Germany | Notable employers and clusters (25-profile sample) |
|---|---|---|---|
| United States | 124 | 2.6x | CNCF, Docker, AWS, Microsoft, Okta; Seattle top region |
| India | 122 | 2.6x | Oracle, IBM, Siemens (3 each); Bengaluru 15 of 25 |
| Germany | 47 | 1.0x | Datadog, NVIDIA, Dash0; Karlsruhe and Berlin |
| Total | 293 | | |

The samples show how narrow the label is. In India, 15 of 25 sampled profiles sit in Bengaluru, and Oracle, Siemens and IBM each appear three times, so this is mostly corporate open-source work. Headline matching also undercounts, because most maintainers never put the word in their title.

So you have to infer review ability from behavior: who reviews on which repos, whose issue comments maintainers act on, whose external merges landed after the August gates went up. That's the gap [Refolk](/) closes. You describe the behavior you want in plain English and get back a ranked shortlist, instead of guessing which keyword a maintainer might have put in a headline.

> **Example search:** "Find backend engineers in Berlin who regularly review pull requests on established open-source Go or Rust projects they don't own." - [run it on Refolk](https://www.refolk.ai/s/ad9jb6wxdx)
>
> You get a ranked list of people with their review activity, GitHub handles linked to professional profiles, and current employers.

Doing this by hand is slow. For every candidate you pull the PRs they reviewed, open a dozen threads, check each repo's age and ownership, then try to match a GitHub handle to a real name and employer. All of that happens before you send a single message.

## Revised filters for sourcing developers on GitHub in 2026

Replace volume gates with filters that target external, older repos and human judgment. Here's the order I'd apply them in when sourcing developers on GitHub in 2026:

1. **Exclude owned and new repos first.** Count commits and PRs only on repos the candidate doesn't own and that were created more than about a year ago. That removes the 55% of commit growth that came from brand-new repos.
2. **Pull reviews given.** Look at PRs they reviewed outside their own account, and look for repeat reviews on the same established project.
3. **Read issue participation.** Skim their issue threads for ones where a maintainer changed course after their comment.
4. **Weight gated external merges.** A merged PR into a project with collaborator limits, PR caps, or a pre-approved-issue policy like Ghostty's outranks a pile of merges into ungated repos.
5. **Calibrate any leftover volume threshold per language.** Don't use a TypeScript cutoff on Java engineers, given the 44.1% vs 21.2% AI-involvement gap.
6. **Treat agent trailers as neutral-to-positive.** Note them, don't filter on them.
7. **Don't drop candidates for an empty external-PR record.** Fall back to reviews and issues before you rule anyone out.

Step 7 is where most pipelines leak good people. The engineer with no external PRs since August may be the one tldraw or Ghostty would have accepted before the gates went up. With Refolk, ask for engineers with strong issue activity on a named project and you'll get the people a merge filter would have thrown out.

## FAQ

### Are commit counts useless for screening engineers now?

Not useless, but no longer a primary gate. Commits grew about 2.7x over the full year, and 55% of commits since June came from brand-new repos. Raw totals now mostly reflect how many greenfield agent projects someone started. Commit activity on established repos the candidate doesn't own still carries signal.

### Should I reject candidates whose commits carry Co-authored-by agent trailers?

No. Claude Code and Aider add trailers by default, while GitHub Copilot, Codex CLI and Cursor add nothing, and some users strip trailers entirely. A trailer shows which tool someone used and that they were willing to disclose it. Penalizing it filters for less transparent candidates, not less AI-dependent ones.

### What if a strong candidate has no external pull requests at all?

That's increasingly normal. Since GitHub's August 27, 2026 maintainer controls, projects like tldraw auto-close external PRs and Ghostty limits AI PRs to pre-approved issues. Look at the reviews they've given and the issue threads they've shaped. Those often show judgment better than a merge would.

### How can I tell a human code review from an AI-generated one?

Look for specifics an agent rarely supplies: references to past project decisions, pushback on scope rather than style, requests for a particular test, and an author reply that changes the code. A review that only summarizes the diff, with no request for change, is weak evidence whoever wrote it.

---

_From the Refolk blog. More posts: https://www.refolk.ai/blog/index.md_