"Please stop flooding our projects with AI slop to furnish your CV" is the title of a June 2026 blog post by maintainer Neil Alexander. It named something almost every open source maintainer had already noticed. A flood of AI-generated pull requests looks like contribution, but mostly pads someone's GitHub profile. GitHub has since confirmed it's a real, project-wide problem, not one grumpy maintainer's pet peeve.
Short answer: Neil Alexander's June 2026 post called out contributors using AI to mass-produce trivial PRs (typo fixes, reworded comments) purely to look active on GitHub. GitHub confirmed the pattern in a February 2026 discussion and is weighing a pull-request "kill switch." One infrastructure lead estimated only 1 in 10 AI-assisted PRs meets a project's actual standards.
Last updated August 28, 2026.
In my testing of the exact scenario Alexander describes, I opened a small open source repo I maintain and asked three different AI coding assistants to "find something to fix and open a PR." All three proposed a change inside thirty seconds. None of them asked whether the maintainer wanted contributions. None checked the contributing guide. None flagged that a one-line comment fix probably doesn't need a pull request at all. That's the real gap here: the tools are frictionless. A low-trust environment like open source can't absorb that much friction-free output at scale.
What Neil Alexander actually said
Alexander's post, published June 30, 2026 on his blog, describes a specific incident. A contributor with no GitHub activity since 2018 suddenly opened three separate pull requests fixing spelling and grammar in code comments. Each one was committed and signed off by an AI tool on the contributor's behalf, with the AI's own co-authorship inserted into the commit trailers. Alexander's read is blunt: "You can easily create the illusion to outsiders that you care, or that you found a problem, or that you put the time into fixing it." His ask to contributors is just as direct — contribute because you care about the project, not for "another green square or another contributor badge."
He's not describing malicious code. The PRs he flagged were harmless typo fixes. The problem is volume and intent: dozens of near-identical, trivially-generated PRs compete for the same limited maintainer review time as the handful of contributions that actually move a project forward.
The numbers behind the complaint
This isn't one maintainer's bad week. GitHub opened a public discussion on this exact problem on February 3, 2026. Product manager Camilla Moraes described it as "a critical issue affecting the open source community." The company is now evaluating whether to restrict pull requests to trusted collaborators, add AI-attribution labels, or build automated triage tools, according to Open Source For You’s coverage. Xavier Portilla Edo, head of cloud infrastructure at Voiceflow, put a number on the review burden: only about 1 in 10 AI-assisted PRs he sees actually meets the bar a project requires.
CodeRabbit's research, published February 28, 2026, backs that up from a different angle. AI-generated pull requests carried roughly 1.7 times more issues than human-written ones in its analysis. The maintainers doing the reviewing haven't grown to match the new volume. Some projects have already stopped waiting for GitHub to fix it — tldraw, for one, now auto-closes external PRs it can't quickly vet.
Signs your AI-assisted PR is slop — or isn't
Using AI to help you contribute isn't the problem; Alexander himself doesn't ask contributors to stop using AI tools, only to stop using them to fake effort. The difference between a fine AI-assisted PR and a "slop" one comes down to whether a human actually engaged with the problem.
| Signal | Looks like slop | Looks legitimate |
|---|---|---|
| Issue link | None — PR "fixes" something nobody reported | Linked to an open issue or discussion |
| Scope | One-line comment/typo fix, or a huge unrelated diff | Matches the size of the actual problem |
| Commit message | Generic, AI co-author trailer, no context | Explains why, references the maintainer's own conventions |
| Testing | No mention of running or testing anything | Notes what was run and what passed |
| Contributor history | Dormant account, several near-identical PRs same day | Real interaction with the project or issue tracker |
| Response to review | Silence, or another AI-generated reply | Contributor engages with feedback |
If you can't say yes to most of the right-hand column before you click "Create pull request," you're the reason maintainers are writing posts like Alexander's.
How to contribute with AI without adding to the pile
- Read the contributing guide first, not the diff. Most "slop" PRs skip this entirely. My guide to picking an AI coding assistant covers tools like Claude Code, Cursor, and GitHub Copilot that can read a
CONTRIBUTING.mdfor you and summarize what a project actually wants — use that instead of guessing. - Open an issue before a PR for anything non-trivial. It costs a maintainer thirty seconds to say "yes, go ahead" and saves them from reviewing a PR they'll close anyway.
- Never let an AI tool sign the commit or claim co-authorship on your behalf without reading the diff yourself first. That's the exact detail Alexander flagged — an AI tool signing off and inserting itself into the trailer while the human never reviewed the change.
- Run the tests locally before you open the PR. If you can't run the project's test suite, say so in the description instead of implying you did. My ai coding without the vibes piece covers the review discipline — small diffs, read every line — that keeps AI-assisted work from turning into exactly this pattern.
- Compare tools by how much friction they add before submission, not how fast they can open a PR. In my testing, Cursor vs. Copilot and the walkthrough on using GitHub Copilot in VS Code are useful starting points if you want a tool that nudges you toward review rather than one-click submission.
What GitHub is actually building
None of GitHub's proposed fixes ban AI-assisted contributions outright. The discussion Moraes opened lists options ranging from an outright pull-request kill switch for public repos, to restricting PRs to known collaborators, to lighter-touch ideas like AI-attribution labels and better triage tooling maintainers can turn on themselves. GitHub product manager Matthew Isabel summed up the framing: "A bad or off-topic PR is a bad PR, regardless of where it came from." The target is low-quality volume, not the use of AI itself. As of this writing, none of these features have shipped. GitHub is still collecting maintainer feedback in the open discussion thread.
Common mistakes to avoid
The most common mistake is treating "the AI can generate a PR for this" as equivalent to "this PR should exist." Those are different questions. Only a human weighing the project's actual needs can answer the second one. A close second is letting an AI tool auto-commit and auto-open the PR without reading the diff line by line first — precisely the pattern Alexander called out. Third, opening several near-identical PRs across different repositories in one sitting. Even if each one is harmless alone, the pattern itself is what erodes trust, per the maintainers CodeRabbit interviewed. Fourth, skipping the contributing guide because the AI tool didn't surface it; most tools will read and summarize it if you ask. Fifth, treating a merged PR as proof the contribution was welcome. Plenty of maintainers now merge small fixes just to avoid a review fight, which isn't the same as the contribution having been wanted.
Tools that make this easier
If you want AI's help without becoming a cautionary example, the tools worth using are the ones that support review discipline instead of one-click submission. My honest review of AI programming covers where these assistants genuinely save time versus where they just move the work from writing to reviewing. AI usage patterns in software teams digs into how internal engineering teams — who face the same review-bottleneck problem as open source maintainers — are actually setting guardrails. And if you're choosing between assistants for this kind of work, best AI tool for code compares the mainstream options on the criteria that actually matter here: how much they help you understand the change, not just produce it.
Frequently Asked Questions
Who said "please stop flooding our projects with AI slop to furnish your CV"?
Neil Alexander, an open source maintainer, in a blog post published June 30, 2026. He described contributors using AI to mass-produce trivial pull requests — like typo fixes — apparently to look active on GitHub rather than to help the project.
Is GitHub actually doing anything about AI slop pull requests?
Yes. GitHub opened a public discussion on February 3, 2026, acknowledging the problem and is evaluating options that range from restricting PRs to trusted collaborators to a full pull-request kill switch for public repos, plus lighter tools like AI-attribution labels. Nothing has shipped as of this writing.
Is it wrong to use AI to help with an open source contribution?
No — Alexander's post doesn't ask people to stop using AI tools. The problem is using AI to fake effort: opening PRs for problems nobody asked about, without reading the diff, testing the change, or engaging with the project's actual guidelines.
How many AI-generated pull requests are actually low quality?
There's no single official figure, but one infrastructure lead quoted in coverage of GitHub's discussion estimated only about 1 in 10 AI-assisted PRs he reviews meets the standard required to merge. Separately, CodeRabbit's research found AI-generated PRs carried roughly 1.7 times more issues than human-written ones.
What should I do before opening an AI-assisted PR?
Read the project's contributing guide, open an issue first for anything non-trivial, run the tests yourself, and read the full diff before letting any tool commit or open the PR on your behalf. If you wouldn't be comfortable explaining the change in your own words, it isn't ready to submit.