51% of GitHub Commits Are AI. Source the 82, Not the 2,584.

Every GitHub sourcing playbook written before 2024 assumed one thing: that a human sat down and typed the commit. That assumption is dead. If you are still filtering by contribution graph density, star counts, or follower counts in late 2026, you are sorting a pool that AI agents actively pollute.

What still works is narrower and older-school: merged PRs into a short list of load-bearing AI infrastructure repos. That is the article.

The signals that died in 2026

Contribution graphs, star counts, and follower counts stopped separating real engineers from prompt-typers the moment Claude Code could open, review, and merge a PR on its own. GitHub itself reports 51% of committed code in early 2026 was AI-generated or AI-assisted. Snap sits at 65%. Google says 25% of new code is AI-written.

The volume shift is the tell. GitHub is processing 275 million code commits per week as of mid-2026, up from roughly 1 billion commits in all of 2025. Claude Code alone accounts for an estimated 4% of all public commits, about 135,000 per day as of February 2026, and SemiAnalysis projects it clears 20% of daily commits by December 2026.

275M

Three specific shortcuts stopped working:

• The green-square heatmap. Anyone running an agent overnight can produce a dense, recent contribution graph. Density and recency are now, at best, neutral, and at worst adversarially generated.
• Star counts on trend repos. LangChain went from ~111k stars in mid-2025 to 122,850 in 2026. Over the same window, OpenAI, Anthropic, and Google absorbed most of its differentiation into their own APIs. Stars measure vibe.
• Prolific-committer leaderboards. GitClear's 2024 report, analyzing 153 million changed lines from 2020 to 2024, found code churn (lines added then removed within two weeks) doubled after Copilot adoption. The top of any commit-count leaderboard is now enriched for people writing code they immediately delete.

The mechanism is boring. AI raises the ceiling on output and lowers the floor on quality signaling. Anything that measures how much someone shipped, without asking where it shipped or whether it stayed shipped, is now noise.

What still separates real engineers from prompt-typers

Merged PRs into strict-reviewer repos are the last high-precision filter for sourcing AI engineers on GitHub. Not commits. Not stars. Not followers. Merged, reviewed, kept-in-tree pull requests into a small number of repos where the maintainers push back hard.

The Beamery study cited by Herohunt found 83% of technical hiring managers trust a GitHub profile more than a traditional resume. That trust is still warranted, but only if you look at the right surface. Judgment shows up in what someone chose not to build, how they argued in an issue thread, and whose review comments they addressed on the third revision. None of that is visible in the contribution graph.

The four repos worth enumerating by hand in 2026:

1. pytorch/pytorch. The base layer. Contributions here are the closest thing to peer-reviewed publication for framework-level work.
2. vllm-project/vllm (2,000+ lifetime contributors; ~212 shipping per release cycle). The cloud-inference standard. A recent release shipped 411 commits from 212 contributors, 61 of them new.
3. ggml-org/llama.cpp (~1,016 contributors). The local-inference community, largely disjoint from the vLLM crowd. Different talent pool, different employer set.
4. huggingface/transformers (~164,600 stars). Merged PRs here are the applied-NLP equivalent of a conference paper.

Everything downstream (agent frameworks, RAG wrappers, prompt libraries) is where the noise is. The four repos above are where reviewers still say no.

The 31x narrowing: PyTorch skill vs vLLM signal

Pivoting from a broad skill tag to a narrow-repo keyword collapses a 2,584-person pool into an 82-person shortlist, a roughly 31x signal-to-noise improvement. This is the mechanism behind GitHub sourcing in 2026: stop matching skills, start matching maintainer files.

In Refolk's index of professional profiles, there are 2,584 U.S.-based Machine Learning and AI Engineers who list PyTorch as a skill. That is a reasonable Boolean-search result. It is also unworkable, because most of those profiles are engineers who once completed a PyTorch tutorial, not engineers whose merged code runs in production inference stacks. Only 17 of them hold the exact title "Machine Learning Engineer," concentrated at Meta, Apple, and Amazon.

Swap the keyword to "vllm inference" against ML, AI, and Inference engineer titles, and the same index returns 82 people globally. Top employer: AWS. Concentration in Bengaluru and the U.S.

The 82-person number is the point. Sourcing AI engineers on GitHub in 2026 is not a search problem, it is an enumeration problem. Once you have the right repo and the right keyword pivot, you can literally read the list.

The nine names behind vLLM

The vLLM founding author list is a nine-person shortlist any recruiter can enumerate today. The 2023 paper "Efficient Memory Management for Large Language Model Serving with PagedAttention" names them: Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Most were affiliated with UC Berkeley's Sky Computing Lab.

This is what vllm contributors sourcing looks like when you take it seriously. You are not building a market map, you are building a call list. Nine people wrote the paper. Roughly 200 people ship the current release. Two thousand-plus have committed at least once in the project's lifetime. Each ring outward is a different hiring conversation:

• The nine. Already known, already recruited, expensive. Useful mostly as reference calls and as anchor employers for their alumni.
• The 200. Actively shipping, mostly employed, most productive to reach in the two-week window after a release lands.
• The 2,000. Historical contributors, many now working on adjacent inference problems. The vllm-project org has 49 public repos beyond core vLLM, including aibrix, tpu-inference, compressed-tensors, speculators, and semantic-router. Each side project is a narrower sourcing pool.

The Hugging Face transformers hiring signal works the same way. The repo has ~164,600 stars, but the number that matters is how many humans have a merged, non-trivial PR against it in the last 18 months. That set is small enough to read, and it maps cleanly to applied NLP engineers whose work survived review.

Harrison Chase pushed LangChain to GitHub in October 2022 after time at Airbnb and Robust Intelligence. That is the canonical repo-first career: the graph followed the code, not the other way around. In 2026 you are looking for the same pattern, just three years further into the maintainer histories.

The junior collapse and why enumeration beats Boolean now

The economics of hand-enumeration flipped in 2026 because the underlying population shrank. Stanford data shows junior developer employment down 20% since 2024 and entry-level tech postings down 67%. The pipeline of new open-source AI contributors is smaller and older than it was in 2022.

That matters for proof-of-work hiring in two ways. First, the population producing genuinely new contributions to load-bearing repos is now countable. Second, the marginal cost of reading the top 200 contributors to a target repo is competitive with running Boolean searches across LinkedIn, because LinkedIn's ML-engineer pool is polluted with self-taught prompters while the maintainer list is not.

Sourcing AI engineers on GitHub in 2026 is not a search problem. It is an enumeration problem.

The workflow that survives:

1. Pick the repo, not the skill. pytorch/pytorch, vllm-project/vllm, ggml-org/llama.cpp, huggingface/transformers. Add one or two org-adjacent repos if you are hiring for a specific inference stack.
2. Pull merged PRs, not commits. Filter to merged, non-docs, non-typo PRs in the last 12 to 18 months.
3. Read the reviewer thread. How the candidate handled pushback is a better signal than the diff itself.
4. Cross-reference to current employer. Someone who merged into vLLM while at a hyperscaler is a different conversation than the same person at a stealth startup.
5. Enumerate, do not search. The pool is small enough to read.

Refolk runs steps four and five automatically across GitHub, LinkedIn, and the open web, which is where the "ask in plain English" pitch stops being marketing and starts being a working sourcing tool.

Why Claude Code caused this, and why it keeps getting worse

Anthropic's Claude Code is the single largest cause of the sourcing-signal collapse, and its usage is compounding fast. Weekly active Claude Code users doubled between January 1 and February 12, 2026. The average developer using it spends 20 hours per week with the tool. The @claude mention on GitHub PRs means the agent can respond to review comments autonomously, which means even the reviewer thread is partially adversarial now.

That is why the four-repo shortlist works and will keep working: those repos have human maintainers who push back on agent-generated PRs, close them, and require humans to defend architectural choices. The filter is not the repo, it is the reviewer culture of the repo. Any repo without a strict human reviewer bench is now downstream noise.

The takeaway for eng leaders and technical recruiters: retire the contribution graph, retire the star count, retire the follower count. Build your 2026 sourcing motion around merged PRs into four repos and one paper. The population you care about is smaller than your CRM, and it is enumerable this quarter.

FAQ

Is the GitHub contribution graph completely useless in 2026?

Not completely, but close. It is now a neutral-to-negative signal on its own, because agents can produce dense, recent graphs overnight. It still has diagnostic value in combination: a dense graph with zero merged PRs into strict-reviewer repos is a specific pattern, and it is not the pattern you want. Treat the graph as context, not evidence.

Why merged PRs instead of commits?

Because commit volume rewards code churn, and GitClear showed churn doubled after Copilot adoption. A merged PR into pytorch, vllm, llama.cpp, or transformers has survived human review by maintainers who reject most of what they see. That is a proof-of-work signal that agents cannot cheaply fake, at least not yet. Commits into a candidate's own repo are almost noise-free of review, so they carry almost no information.

How do I source vLLM contributors without spending a week on graphs/contributors pages?

Start with the release notes rather than the contributors page. Each vLLM release lists the exact contributors for that cycle (about 212 people, 61 of them new, per the most recent release). Cross-reference those handles to current employers. Or ask Refolk in plain English for "engineers who merged to vllm-project/vllm in the last release and now work at AWS, GCP, or an inference startup" and skip the manual step.

Do star counts still tell me anything useful?

They tell you about topic hype, not engineering quality. LangChain climbing past 122,000 stars in 2026 happened while OpenAI, Anthropic, and Google were absorbing its core capabilities into their own APIs. If you are using star counts to rank engineers or repos for hiring, you are measuring the audience, not the author. Merged PRs into a small number of load-bearing repos are the signal that survived 2026.