AI Slop Is DDoSing Open Source: A Maintainer Policy That Protects Review Time
The problem is not that a contributor used AI. The problem is transferring the cost of understanding, testing, and repairing generated work to a maintainer.
Open source has always accepted imperfect contributions. A maintainer might coach a first-time contributor through a failing test or an unfamiliar project convention because the exchange builds a future collaborator.
Coding agents change the economics. A contributor can generate ten plausible pull requests in the time a maintainer needs to verify one. If the author has not reproduced the bug, understood the patch, or run the repository's checks, the maintainer becomes the unpaid operator of the contributor's tool.
Openness works when contribution cost is shared. It breaks when generation is cheap and verification is silently outsourced.
The evidence: more volume can mean less capacity
The 2026 study “AI Slop is DDoSing Open Source” analyzes 294 repositories and more than two million pull requests and issues. The authors use AI-DDoS for the effect created when plausible, low-quality generated contributions overwhelm community capacity.
In the study, pull-request volume increased during 2025 while merge rates declined. The estimated merge rate for one-time contributors fell 18.18% relative to the counterfactual. The research does not say every rejected contribution was AI-generated or that AI use should be prohibited. It shows a sustainability problem: review supply did not expand with submission supply.
The authors also identified 11 remediation strategies and validated them with 229 open-source practitioners. The central lesson is not “close the doors.” It is that low-effort defensive policies can preserve today’s queue while making communities less open tomorrow. A useful policy must reduce verification waste without turning every new contributor into a suspect.
Policy principle: judge evidence, not vibes
AI authorship is difficult to prove and is a poor proxy for quality. Humans submit bad patches. Agents can help produce good ones. A maintainer policy should focus on observable obligations: is the problem real, is the change scoped, did the contributor validate it, and will they own the follow-up?
Disclosure still matters. It helps maintainers calibrate their review and tells future contributors how the patch was produced. But disclosure should not replace evidence. “Generated with Claude” is not validation, and “written manually” is not a quality guarantee.
A three-lane contribution policy
Lane 1: documentation and bounded cleanup.
Accept small, reversible changes through the normal path. Require links to the affected page, screenshots or rendered output when relevant, and successful repository checks. These patches should not introduce dependencies or redesign public APIs.
Lane 2: verified bug fixes.
Require a minimal reproduction, a failing test or exact verification procedure, a focused fix, and evidence that the test now passes. The contributor must be able to explain the failure and answer review questions. Close patches that only restate an issue and attach a generated diff.
Lane 3: features, security, dependencies, and architecture.
Require an issue or design discussion before implementation. New packages need provenance, maintenance, license, and necessity checks. Security changes need a threat model and private reporting path where appropriate. Large generated pull requests submitted without prior agreement can be closed without line-by-line review.
Copyable pull-request requirements
Before requesting review, confirm:
- I reproduced the problem or linked the approved feature discussion.
- I understand the changed code and can answer questions about it.
- The diff is limited to the smallest change needed for this task.
- I ran the documented build, test, lint, type, and security checks.
- I added or updated a test that would fail without this change.
- I independently verified every new dependency, API, and configuration key.
- I disclosed material use of code-generation tools.
- I will respond to review and repair regressions introduced by this patch.
Add one clear enforcement line: submissions missing required evidence may be closed without a detailed review. That is not hostility. It prevents the queue from rewarding the cheapest possible submission process.
Automate the admission checks
Templates reduce omission, but CI enforces consistency. Run formatting, compilation, tests, static analysis, secret detection, dependency review, and generated-code quality checks before a maintainer is requested. Apply the same gate to humans and agents.
A deterministic gate is particularly useful for repetitive review drag: empty exception handlers, unsafe type escapes, debug leftovers, dead code, unresolved placeholders, trivial comments, and complexity regressions. These findings should reach the contributor in minutes, not wait days for a maintainer to point them out.
In repositories using aislop, a change-only scan can sit in that admission layer:
npx aislop@latest ci --changes --base origin/mainReplace origin/main with the pull request's target
branch. It is not an authorship detector and should not be used as one. Its value is a
reproducible standard for the code itself.
Protect people as well as the queue
Give maintainers permission to close low-evidence work with a saved response. Rotate intake if the project has enough people. Limit simultaneous pull requests per contributor. Ask trusted contributors to triage only after automated checks pass. Publish the expected response window so silence does not become another source of conflict.
Finally, leave a path back. A closed submission can invite the contributor to return with a reproduction, test, or smaller patch. The policy should make responsible contribution easier to recognize, not make newcomers prove they are human.
Sources
Frequently asked questions
Should open-source maintainers ban AI-generated pull requests?
A blanket ban is one option, but it is not the only workable policy. Maintainers can require disclosure, reproduction steps, scoped diffs, successful local checks, and contributor ownership of follow-up. The enforceable standard should be evidence and review cost, not guesses about authorship.
What is AI-DDoS in open source?
AI-DDoS describes a denial-of-service effect in which plausible, low-quality AI-generated contributions arrive faster than maintainers can verify them. The scarce resource being exhausted is human review capacity.
What should an AI contribution policy include?
Include disclosure expectations, accepted contribution scope, required tests and reproduction steps, dependency rules, diff-size limits, automated gates, response deadlines, and a clear close-without-review condition for submissions that transfer basic verification work to maintainers.