Curl Got 37 AI Slop Reports in 2025. Three GitHub Signals That Still Work.

GitHub's own 2026 outlook post used the phrase "AI slop" in print, which is the platform quietly conceding that its most-cited recruiter signal - the green-square contribution graph - is now measuring agent output as much as human skill. If your GitHub sourcing playbook still starts with "sort contributors by commit count and DM the top result," you are ranking by a metric that inflated 3.6x in three years while the underlying talent pool did not.

Here is what to use instead.

Why commit counts stopped meaning what they used to

Commit volume decoupled from engineering skill somewhere between the launch of Copilot and early 2026, and GitHub's own numbers make the decoupling impossible to argue with. The platform went from 25 million merged pull requests per month in January 2023 to 90 million in March 2026, and from 389 million monthly commits to 1.4 billion, both roughly 3.6x. The number of humans capable of writing production code did not 3.6x in the same window.

The mechanism is straightforward. 80% of new developers on GitHub use Copilot in their first week. GitHub added 36 million accounts in 2025 alone, roughly one every second. When you sort a repository's contributor list by commits in 2026, you are largely ranking who ran the most agent sessions against that codebase, not who understands it.

3.6x

Daniel Stenberg, who maintains curl, published the cleanest single dataset on this: AI-slop security reports to his project went from 2 in 2023, to 6 in 2024, to 37 in 2025. In January 2026 he ended curl's six-year HackerOne bug bounty program because roughly a fifth of submissions by mid-2025 were reports that "sounded technical but described vulnerabilities that did not exist in the code." That is the read on the raw signal from someone who has to look at every submission.

What "AI slop" actually is, and why sourcers should care

GitHub defines AI slop as "a large quantity of low-quality, often inaccurate contributions that don't add value, or would take so much work to incorporate it would be faster to implement the solution yourself." For a maintainer that is a triage problem. For a recruiter it is a measurement problem: the pool of accounts that look active on GitHub now includes a large fraction of people whose visible output was generated by an agent they cannot explain.

Three projects that broke publicly under the load:

1. Jazzband, a Python collective, shut down entirely. Its lead maintainer cited the unsustainable volume of AI-generated spam PRs and issues as a primary driver.
2. Tldraw closed external contributions in late 2025 "for the good of the project."
3. OCaml rejected a single PR containing more than 13,000 lines of AI-generated code, a patch that would have taken a human months of community discussion and that an agent produced in a session.

Keeley Hammond at Electron reported receiving twice as many proposals in 2025 as prior years, with a significant portion being AI-generated noise. Remi Verschelde at Godot described the triage as draining and demoralizing. Jeff Geerling, who maintains more than 300 Ansible projects, put it best: the cost of entry collapsed, but the cost of evaluation did not.

For sourcing, the corollary is that the top of the funnel got dramatically noisier at the same time inbound funnels did. WasItAIGenerated's 2026 report puts AI-generated content in 78% of job applications, up from 8% in 2023, and 41% of candidates now get auto-rejected by AI screening tools. GitHub is not a safe haven from that dynamic anymore; it is part of it.

Signal one: merges into repos that turned PRs off

The strongest positive signal in 2026 GitHub sourcing is a merged commit inside a repository that has enabled GitHub's new repo-level PR restrictions. GitHub shipped these controls in February 2026 in response to the slop wave: maintainers can now limit PRs to collaborators only, disable PRs entirely, pin issue comments to surface contribution guidelines before a PR can be opened, and impose temporary interaction limits during targeted campaigns.

The mechanism is a human trust gate. If a repository has restricted PRs and your candidate's name still appears on merged code, someone with commit rights vouched for that person out of band. That is a stronger reference than any recruiter phone screen. Named-and-shamed slop targets whose survivors are pre-vetted include:

• Ghostty (Mitchell Hashimoto's terminal, zero-tolerance AI-PR policy, permanent bans for repeat offenders)
• curl (Stenberg, bounty program shut down)
• azure-sdk
• nixpkgs
• homebrew-cask

Mitchell Hashimoto is also building Vouch, a contributor-trust layer, which tells you where the maintainer community thinks the primitive belongs. For a recruiter, "merged into Ghostty after the policy" or "landed in curl in 2026" is a stronger line on a resume than 4,000 green squares.

Signal two: issue-comment-to-PR ratio and account age

Slop accounts open PRs without prior issue engagement, so the ratio of issue comments to PRs on a candidate's profile now outranks stars, followers, and total commits combined. Real contributors discuss the problem before they write the code. Agents skip that step because there is no reward function for it.

Two adjacent signals from the same intuition:

• Account age. With 36 million accounts added in 2025, freshness now correlates with slop risk. An account created in the last 12 months with a high commit graph is a red flag; an account from 2017 with a lower graph but 400 issue comments across five projects is the opposite.
• Linked-issue-before-PR discipline. Some maintainers now require a linked issue before a PR can be opened, precisely because the ratio is diagnostic. Candidates whose PRs consistently reference prior issues they participated in are demonstrating the exact behavior maintainers now filter for.

Rank-by-commits is a slop filter that filters for slop.

Neither of these signals is available from a Boolean search on LinkedIn, and neither is surfaced by GitHub's own default sort orders. This is the exact gap Refolk closes for technical sourcing: describe the person in plain English ("Rust contributors who opened issues on tokio before their first PR, active since 2020") and get a ranked shortlist across GitHub, LinkedIn, and the open web, rather than a commit-graph leaderboard polluted by agent runs.

Signal three: "explain your PR" as a 30-second phone screen

The cheapest interview filter in 2026 is asking a candidate to walk through one of their own merged diffs line by line, because that is the exact question maintainers use to reject slop. When maintainers ask "why did you change it this way?" the slop submitter cannot answer. A recruiter can replicate that filter in 30 seconds without a take-home, without a coding platform, and without paying for a proctored assessment.

What to listen for:

• Specific memory of the tradeoff ("we picked a BTreeMap over a HashMap because iteration order mattered for the snapshot format")
• Awareness of the review comments ("the maintainer pushed back on the error type, so I split it into two variants")
• The alternative they rejected ("I tried it with a channel first, but the backpressure semantics were wrong")

Candidates who wrote the code answer these in seconds. Candidates who ran an agent answer in generalities or freeze. This maps directly to the maintainer's own filter, which is why it works: you are running the same test the code already passed.

The pool math: claims to do open source vs. actually does it

The gap between "profiles that mention open source" and "profiles with hard-skill proof of work" is roughly 51x in US software engineering, which is the actual size of the sourcing problem slop created. In Refolk's index of professional profiles, 81,711 US-based software, senior, and staff engineers list "Open Source" or "Git" as a skill. Only 1,603 of them combine that with Rust plus Kernel experience, a reasonable proxy for verified low-level systems work.

51x

Two things fall out of this table. First, the "who has the most green squares" strategy targets 81,711 people, most of whom cannot walk through their own merged diffs. Second, the actual pool for hard systems work is small enough (1,603 people) and concentrated enough (Oxide Computer alone accounts for 4 of a 25-person sample from the top employer cut) that a directed search beats a broad one every time.

The 2026 GitHub sourcing playbook, in five moves

The playbook that replaces "sort by commits and DM the top result" has five moves, in order:

1. Filter for merges into gated repos. Ghostty, curl, azure-sdk, nixpkgs, homebrew-cask, and any repository that adopted GitHub's Feb 2026 PR controls. A merge inside a locked-down repo is a human vouch.
2. Weight issue-comment-to-PR ratio over commit count. Real contributors discuss before they code.
3. Down-weight accounts younger than 12 months with high commit graphs. GitHub added 36 million accounts in 2025; freshness correlates with slop risk.
4. Run the "explain your PR" screen in 30 seconds. Same filter maintainers use, cheaper than a take-home.
5. Search by hard-skill combinations, not by "open source." Rust plus Kernel returns 1,603 people; "Open Source" returns 81,711. The first list is the one you can actually hire from.

Kate Holterhoff at RedMonk called this shift "AI Slopageddon" in early 2025. The recruiting version of it is simpler: the metrics that made GitHub sourcing easy are the metrics that got polluted first. The signals that still work were always the ones maintainers used, and the pool is much smaller than the profile count suggested. Adjust accordingly.

FAQ

Are GitHub stars and follower counts still useful signals?

Stars and followers did not degrade under agent use because agents don't optimize for them, but they were never skill signals in the first place. They measure attention and network, not engineering ability. Use them for context (a maintainer with 20,000 followers is a public figure worth a more careful outreach) but never as a ranking metric. Issue-comment depth and merged code into gated repos are the actual skill proxies in 2026.

How do I tell if a repository has enabled GitHub's Feb 2026 PR restrictions?

The visible tells are a pinned issue comment linking to contribution guidelines that appears before you can open a PR, a "PRs restricted to collaborators" notice on the Pull Requests tab, or an outright disabled PR button. Maintainers of high-slop-target repos (curl, Ghostty, nixpkgs, homebrew-cask) have written publicly about turning these on. If a repo has them on and your candidate has merges dated after February 2026, that is the strongest positive signal on the platform today.

Does the "explain your PR" screen work for candidates who legitimately use Copilot?

Yes, because legitimate Copilot users still made the decisions. They picked the data structure, accepted or rejected the suggestion, ran the tests, and responded to review. A candidate who used Copilot to write the boilerplate but understood the change will walk you through the tradeoffs fluently. The screen is filtering for authorship of the decision, not authorship of the keystrokes. That distinction is exactly what maintainers are filtering for too.

Why does the Rust plus Kernel cut return only 1,603 people in the US?

Low-level systems work is a small specialization, and self-reported skills on professional profiles skew toward the layers most engineers actually touch (web frameworks, cloud services, data pipelines). Kernel-adjacent Rust work is concentrated at a handful of firms - Oxide Computer, parts of Meta and Google's infrastructure orgs, some of OpenAI's systems teams - and the resume language for it is narrow. The 51x ratio between "claims open source" and "Rust plus Kernel" is not unusual for any deep specialization; it is unusual how much the slop wave inflated the numerator without changing the denominator.