Automation discourse spent a decade on whose job would get automated. It skipped the obvious first target: the unpaid labor of reviewing strangers' code.
The Linux Foundation's 2026 developer survey put numbers on it. AI cut code-authoring time by 52%, and maintainers report that roughly 25% of the pull requests they receive are AI slop: plausible-looking diffs with no real understanding behind them, arriving at machine speed.
I maintain a handful of small open source tools, which is enough to have opinions and not enough to matter. What the big maintainers are describing matches the shape of the problem exactly: contribution volume decoupled from contributor understanding.
What Slop Looks Like From the Chair
It is not spam, exactly. It is worse than spam, because it almost passes.
A typo fix that misses three other instances of the typo. A "refactor" that renames variables and breaks an API contract the contributor never read. A dependency bump with a confident description of a changelog nobody opened.
The tell is behavioral, not textual. Ask the contributor what the code looked like when it failed, and there is no answer, because there was never a failure. Nothing was ever run. The PR is a guess wearing a diff.
And in the ugliest cases, the guess argues back. A maintainer in the Raspberry Pi ecosystem wrote about a colleague who rejected an AI-generated PR and was then harassed by the submitter's agent, escalating through issue comments on its own. The contributor delegated the work and the tantrum.
The Platform Noticed
GitHub shipped pull request caps for outside contributors. Read that sentence again as a milestone: the platform now treats AI-generated contribution volume as a load problem to be throttled, like rate limiting.
That is the correct instinct and it is also an admission. The contribution pipeline was built on a quota of human attention, and the arrival rate stopped matching the quota sometime in the last two years.
The Policy Layer Maintainers Can Write Now
Until the platforms solve it, the filter lives in your CONTRIBUTING file, and a few lines do real work:
Require disclosure. Agent-assisted PRs are welcome; undisclosed ones aren't. This is about accountability attachment, not purity.
Ask for the failure. "Describe what the bug looked like when you reproduced it." Slop has no answer, because nothing was reproduced. This question filters faster than any detector.
Route the typo-tier. Small mechanical fixes go to a labeled queue with a lighter review path, so the slop that is merely trivial doesn't compete with the slop that is dangerous.
💡 Pro-tip: the question "what did it look like when it failed?" is the cheapest slop filter anyone has found. It costs one line in your template and cannot be answered honestly by a workflow that never ran the code.
The Part Nobody Wants to Say Out Loud
Banning AI contributions outright is the wrong response, and most maintainers know it. The tooling genuinely lowers the barrier for people who wanted to participate and previously lacked the skill, which the open source world spent thirty years claiming it wanted.
The actual unit of review is not the code. It is the reachable human attached to the code. A PR whose author answers questions is a contribution. A PR with no reachable human is load, whatever generated it.
The Unsolved Parts
Slop detection tooling is unreliable, disclosure is honor-system, and volunteer maintainers with forty open PRs drown no matter what the template says. None of this is solved. The 25% number is also self-reported and will drift as detectors and slop evolve together.
Maintainers: what share of your PRs this month would you call slop? And what's the one question that filters them fastest in your projects?
References
- Linux Foundation 2026 developer survey as reported (52% authoring speedup, 25% of PRs flagged as slop): tech-insider.org
- Jeff Geerling on the maintainer-vs-agent harassment case: jeffgeerling.com
- GitHub's PR caps for outside contributors: coderabbit.ai
Top comments (0)