The friction between AI coding agents and open-source maintainers has officially hardened. As of November 12, 2026, the community-run catalog Open Source Says No lists 23 major projects with written policies that explicitly refuse AI-generated contributions. While earlier reports cited 22 projects, the updated count includes yt-dlp, whose policy was verified on November 11. This isn't just a rumor mill; it’s a concrete shift in infrastructure governance, driven by maintainers who are tired of cleaning up after autonomous agents.

The Catalog Breakdown

The catalog, linked to GitHub user jlengrand, categorizes 220 projects based on their AI policies. Only 23 are labeled 'Banned,' while 191 are 'Restricted,' allowing AI assistance under strict conditions, and 6 allow it freely. Notably, heavyweight projects like the Linux kernel and PyTorch are in the 'Restricted' category, not 'Banned.' The Linux kernel’s guidance emphasizes that reviewer bandwidth is scarce, requiring contributors to understand every line of their submission. PyTorch’s policy similarly states it does not accept contributions created by fully autonomous agents, drawing a clear line between assistance and automation.

Six Costs Reviewers Are Tired of Paying

The policies from banned projects like Servo, fast-check, and immich reveal a consistent pattern of reviewer exhaustion. The primary complaint is code the author cannot explain line-by-line, forcing reviewers to reconstruct intent from the diff alone. Second, there is the issue of untested changes; immich’s guide bluntly states that if verifying a fix is non-trivial and the contributor doesn't show full understanding, reviewing the PR is 'not worth our time.' Third, the back-and-forth required to fix LLM-generated code often costs more than the fix itself, leading immich to suggest it’s faster for maintainers to use LLMs directly rather than review human intermediaries.

Scope Creep and Provenance Issues

Large, unexpected pull requests are another major pain point. gh-dash’s policy notes that AI-assisted PRs are often 'very large' and appear 'out of the blue,' bypassing the crucial discussion phase. This is compounded by unclear provenance; QEMU’s ban is tied to the Developer's Certificate of Origin (DCO), citing that the license status of AI output is 'ill-defined' legally. Similarly, libvips declines contributions due to unknown training sources. These aren't just style preferences; they are legal and operational necessities for projects that can't afford copyright ambiguity or unreviewable scope bloat.

Key Takeaways

  • 23 projects, including yt-dlp, QEMU, and Servo, have explicit bans on AI-generated contributions.
  • Reviewer fatigue stems from unexplainable code, untested changes, and excessive review cycles.
  • Legal risks regarding DCO and training data provenance drive bans for projects like QEMU and libvips.
  • Disclosure of AI use does not automatically make a contribution acceptable in banned projects.
  • Most projects (191) are 'Restricted,' requiring human oversight and understanding rather than full bans.

The Bottom Line

The 'Banned' label is a blunt instrument, but the real signal is in the 'Restricted' majority: if your AI agent can't explain its own code, it's a liability, not an asset.