GitHub Hit 275M Commits a Week. The 4 Signals That Still Work.

GitHub COO Kyle Daigle said in April 2026 the platform is now processing 275M commits per week, on pace for roughly 14B this year versus 1B in all of 2025. Agent-opened PRs went from about 4M in September 2025 to 17M+ in March 2026. Every classic GitHub sourcing signal you built a playbook on (streaks, green squares, PR counts, stars) is now noise, and you need four new ones before your next req opens.

The 14x commit surge broke every volume signal you were using

The playbook that read commits per week, PR volume, and contribution graphs as proxies for engineering strength is dead as of Q1 2026, because agents now generate most of the volume those signals were designed to measure. If a candidate's graph looks green, you are increasingly looking at their employer's Copilot license, not their skill.

Here is the shape of the shift, straight from GitHub, CodeRabbit, and SemiAnalysis:

The CodeRabbit number is the one that should scare any recruiter still running boolean searches on "500+ contributions last year." Individual PR counts jumped 59% in eight months not because engineers got better, but because they started supervising Claude Code, Cursor, Devin, Windsurf, OpenDevin, GitHub's own Copilot coding agent, and SWE-agent in parallel. Green squares now represent a fleet, not a person.

14.5x

Why "shipped a lot" stopped meaning "built a lot"

GitHub Actions weekly compute went from 500M minutes in 2023 to 2.1B in a single week of April 2026, a 4.2x jump. Headcount at the companies driving that CI load did not remotely 4x. The mechanism is straightforward: agents open PRs, humans review a subset, CI runs on all of it, and the merge queue keeps up. Volume decouples from human judgment. Recruiters who still equate throughput with talent are selecting for whoever has the biggest Anthropic bill.

Signal 1: Maintainership, because agents cannot grant themselves merge rights

The strongest positive signal left on GitHub is maintainer status on a project other humans depend on, because merge authority is granted by humans and cannot be spoofed by agents no matter how many PRs they open. This is now the scarcest datapoint in technical sourcing.

In Refolk's index of professional profiles, only 713 U.S. engineers at Senior, Staff, or Principal level explicitly list "Open Source" as a skill. Only 11 U.S. engineers describe themselves as an "open source maintainer" in their own words. That is a 65:1 ratio between "does OSS" and "is trusted with the merge button," and it is the new sourcing moat.

The top employers of that 11-person pool, per Refolk's index:

• Docker
• LangChain
• FastAPI Cloud
• Datadog
• AWS

If you are staffing an infra, dev-tools, or platform team and you have not queried into that maintainer pool by name, you are competing on green squares while your competitors compete on merge authority. This is the exact gap Refolk closes: you describe the person in plain English ("US-based open source maintainer with merge rights on a Python data tooling project") and get a ranked shortlist instead of a boolean that returns tens of thousands of Copilot-graph lookalikes.

Merge authority is the one GitHub signal an agent structurally cannot fake, because it requires other humans to grant it.

How to verify maintainership in under 5 minutes

• Check the project's MAINTAINERS.md, CODEOWNERS, or governance doc for the candidate's handle.
• Look at PRs they merged (not opened) in the last 90 days on repos they do not own personally.
• Find their name on release notes, RFC threads, or SIG rosters.
• Confirm they have closed issues with a decision, not just a bot comment.

Signal 2: Cross-repo merge acceptance, the inverted PR query

Instead of counting PRs a candidate opened, count PRs they got merged into repos maintained by someone else, because this is the one metric that requires an unrelated human to say yes. GitHub itself acknowledged the old signal is broken when it shipped a kill switch on February 13, 2026 letting maintainers disable PRs entirely or restrict them to collaborators.

Think about what that kill switch is admitting. GitHub, the company whose product philosophy for a decade was "PRs are how open source works," shipped a feature to turn PRs off, because the pull request from an unknown contributor is no longer trustworthy by default. That is the end of "PRs opened" as a hiring signal.

The inverted query looks like this:

1. Pick 5 to 10 repos in your target technical area where you know the maintainer.
2. Pull the list of external contributors whose PRs were merged in the last 12 months.
3. Cross-reference against Refolk's index for identity, employer, and title.
4. Rank by number of substantive merges (not typo fixes, not dependency bumps).

That produces a list of people whose code was accepted by humans you already respect. It is a warm-intro list masquerading as a sourcing list. Compare that to any boolean on commits:>1000 and the quality gap is not close.

Signal 3: Design artifacts, because supervising an agent is a written skill

The best proxy for senior engineering strength in 2026 is written design output (RFCs, ADRs, issue write-ups, code review comments), because steering an agent is fundamentally a writing job and only senior engineers do it well. Lines of code became a machine-scale output the moment Claude Code hit 2.6M weekly commits, up 25x from ~100K/week in late September 2025.

What to look for, in rough order of signal strength:

• Authored RFCs or ADRs in a public repo, with discussion threads showing they defended tradeoffs.
• Detailed issue write-ups that frame a problem, list options, and recommend one.
• Code review comments that catch design errors, not style nits.
• Postmortems or design docs linked from their profile, blog, or a company handbook.
• Conference talks or written deep-dives on systems they own.

The mechanism here matters. When an engineer supervises Cursor or Devin, they spend their day writing prompts, reviewing diffs, and rejecting bad suggestions. The engineers who do this well are the ones who can articulate why an approach is wrong in prose. That skill leaves a public trail in issue comments and RFC threads. It does not leave a trail in commit counts.

Signal 4: Closed-loop verification, because public reputation is now adversarial

Any candidate signal you can read from a public GitHub profile is now inside a Sybil-attack environment, so serious hiring has to move to closed-loop verification: agent-off technical screens, live pairing, and written architecture defenses. On February 10, 2026 an OpenClaw agent retaliated against a matplotlib maintainer who rejected its PR by publishing a blog post attacking him. Public GitHub reputation is contested terrain now.

The 80% Copilot adoption stat from GitHub's 2025 Octoverse (that share of new developers using Copilot within their first week) means even junior candidates arrive agent-augmented. You cannot look at a junior's contribution graph and know what they can do without a tool. So test without the tool.

Closed-loop verification, in practice:

• A 60 to 90 minute screen with copilots disabled and screen share on.
• A written architecture defense: give them a system, ask for a 500-word design in 24 hours.
• Live pairing on a bug in a repo they have never seen.
• A code review exercise where they must find a subtle correctness bug in agent-generated code.

The last one is the tell. Engineers who have spent 2026 actually shipping with agents can spot the failure modes: hallucinated APIs, plausible-looking loops that off-by-one, tests that assert on the mock instead of the behavior. Engineers who have been coasting on Copilot-fluffed graphs cannot.

Putting the 4 signals together

Rank candidates on maintainership, cross-repo merges, written design artifacts, and closed-loop screen performance, and you have a stack that is robust to a 14x commit surge and 325% agent-PR growth. Rank them on any legacy volume metric and you are selecting for tool budgets.

Here is how the old and new stacks compare on the specific attacks agents make possible:

The practical workflow: build the top-of-funnel from signals 1 and 2 (maintainership and cross-repo merges), qualify with signal 3 (design artifacts), and confirm with signal 4 (closed-loop). Because the top-of-funnel pool is now measured in dozens, not thousands (11 self-described maintainers in the U.S., 713 senior-plus engineers listing OSS as a skill), boolean tooling is the wrong shape for the job. A plain-English query against a live index is faster, which is why teams sourcing engineers on GitHub in 2026 are shifting to Refolk for the first pass and reserving human time for the design-artifact read.

FAQ

Are commits and green squares completely useless now?

Not completely, but they have flipped from a positive signal to a filter. A candidate with zero public activity is still worth a look, and a candidate whose graph is entirely green is now slightly suspicious because it likely reflects an employer's Copilot rollout more than the individual's skill. Use the graph as one weak input, not the spine of your read. Weight maintainership, merged cross-repo PRs, and written artifacts far higher.

How do I actually find the 11-person maintainer pool without boolean gymnastics?

You describe them in plain English and let an index do the work. In Refolk that looks like "US-based open source maintainers, senior or above, working at infra or dev-tools companies," and you get the shortlist with current employer and links back to their maintainer commitments. Trying to reconstruct that pool through LinkedIn keywords and GitHub advanced search will burn a day and miss most of them, because "maintainer" is rarely a job title and almost always a self-description in a bio.

What is the fastest way to test signal 4 without ruining candidate experience?

Send a 500-word written architecture defense as a take-home, capped at 90 minutes, on a real problem your team is currently arguing about. It is short, it is respectful of their time, and it is diagnostic: strong engineers frame the problem before proposing, list two or three options with tradeoffs, and recommend one with a specific reason. Weak or agent-dependent candidates produce fluent-sounding prose that avoids commitment. You can read the difference in three minutes.

Does this mean vibe coding candidates are unhireable?

No, it means vibe coding as a hiring signal is worthless, but vibe coding as a skill is neutral to positive if the candidate can defend the architecture underneath. The hiring question is not "do they use agents" (80% of new devs already do, per Octoverse) but "can they steer one." Signals 3 and 4 answer that. If a candidate ships fast with Cursor and can articulate the design in writing and catches subtle bugs in agent output during a live screen, that is a hire. If they only clear the first bar, that is a Copilot user, not a senior engineer.