23 open-source projects now refuse AI-generated PRs: 6 things their policies say reviewers are tired of in 2026

A community-run catalog called Open Source Says No refreshed its list on November 11 and landed on Hacker News the same week. The catalog's Banned view now shows 23 open-source projects whose written policies refuse AI-generated contributions. Two listicles dated November 11 already say 22.

The count matters less than the reasons. Many of those policies spell out what AI-generated pull requests cost the people who review them. Read together, they work as a reviewer's checklist written by maintainers.

Teams shipping agent-generated code want the same end state: changes merged sooner with fewer rollbacks. The lesson here is not about getting past a ban. Where a project refuses AI-generated work, the answer is to respect the policy. The lesson applies to your own repositories, where your reviewers carry the same costs.

What Open Source Says No tracks, and who runs it

The site links its source repository to GitHub user jlengrand, who also posted the site to Hacker News. The about page calls the catalog "informational" and says it "takes no position on whether those policies are right." The repository link returned a 404 on November 12.

Projects qualify with at least 5,000 GitHub stars, or as widely used infrastructure. Each entry quotes the policy text verbatim, links to the official source, and shows the date the entry was last checked. Labels follow the wording of the policy and, per the site, are "not upgraded or downgraded."

Banned is the small group; restricted is the big one

"Refuse" in the title means the Banned label only. Most of the catalog sits under Restricted, where AI assistance is allowed under conditions. The Linux kernel is Restricted, not Banned. The kernel's guidance on generated content says "reviewer and maintainer bandwidth is a scarce resource" and asks contributors to understand their entire submission.

PyTorch is Restricted as well, and the project's AI policy says: "We do not accept contributions created by fully autonomous agents." Restricted and Banned policies often name the same costs. The difference is how far each project is willing to go to avoid them.

6 things their policies say reviewers are tired of

Not every ban is about reviewer fatigue. Some are about copyright, the Developer's Certificate of Origin, or ethics, and those reasons get their own section below. The six costs here are the ones that policies giving review reasons actually put in writing.

1. Code the author doesn't understand
2. Changes nobody tested or reproduced
3. Back-and-forth that costs more than the fix
4. Large PRs that arrive out of the blue
5. Descriptions and comments a person didn't write
6. Unclear provenance and license

1. Code the author doesn't understand

Servo's AI policy puts maintainer burden first. The tools, it says, "make it easy to generate large amounts of plausible-looking code that the contributor does not understand."

fast-check's AI policy refuses "Code you cannot explain line by line and take responsibility for." pdfcpu's contributing guide expects contributors "to be able to explain every change in review."

For any reviewer, the cost is the same. A reviewer can check a change against intent only when the author can state the intent. Without that, the reviewer has to reconstruct it from the diff.

2. Changes nobody tested or reproduced

Servo also describes generated code that "is often untested, and does not function properly." fast-check rejects "Reports or fixes for problems you have not reproduced yourself."

immich's contributing guide is direct about the trade-off: "if it's non-trivial for us to verify it works and you don't show that you fully understand all implications of the change, reviewing the PR is not worth our time."

Evidence that a change ran is cheap for the author to provide and expensive for a reviewer to produce. Every policy above pushes that cost back to where it belongs.

3. Back-and-forth that costs more than the fix

immich says code generated with an LLM "tends to need a large amount of back-and-forth, which is a very inefficient use of our time." The same guide adds: "If we want LLM-generated code, it's much faster for us to use an LLM ourselves than to go through an intermediary via a pull request."

The contributing guide for sebastianbergmann/recursion-context says such pull requests "cost reviewers too much time," and warns that submitting one leads to a ban from the project.

A review round costs both sides a context switch. When the author's answers come from the same tool that wrote the code, each round adds cost without adding understanding.

4. Large PRs that arrive out of the blue

gh-dash's AI policy says AI-assisted pull requests it received were "often times very large PRs that appear out of the blue." Its ideal workflow starts with a discussion, and "a large change is split into smaller PRs."

awesome-claude-skills, a list of resources for an AI coding tool, cites "the influx of PRs" in its contributing guide. Reviewing "the entire codebase of an LLM-generated project" is, in its words, "too untenable."

Size and surprise compound. A large change nobody asked for forces the reviewer to judge scope, design and correctness in one sitting.

5. Descriptions and comments a person didn't write

immich: "Communication should be between humans. We want to hear from you in your own words." Meilisearch's contributing guide excludes generated "PR descriptions, PR comments, issue descriptions, and issue comments" along with code.

The okhttp contributing guide says "We believe writing is thinking." stb's contributing file asks contributors to "Write them yourself, in English, even if your English is bad."

yt-dlp's contributing guide goes furthest. The yt-dlp ban covers issues, bug reports, PR descriptions, issue tracker comments and code review comments. The PR description is part of the review, and these projects treat it that way.

6. Unclear provenance and license

The sixth item is a legal reason, not fatigue. QEMU's code provenance policy ties its ban to the Developer's Certificate of Origin. Contributors must certify the license status of what they submit, and for AI output that status "is ill-defined with no generally accepted, settled legal foundation."

libvips's contributing guide makes a similar point: training sources "are generally not known," so the project declines such contributions "because of the related legal risks."

pdfcpu adds a smaller provenance rule worth noting. Contributors should not add AI instruction files such as AGENTS.md, CLAUDE.md, or Copilot and Cursor rules files to a pull request.

What review can't fix

Several reasons in these policies are not review problems at all. Servo lists ethical concerns, including energy use and labor conditions. QEMU and libvips cite legal risk. A more careful review changes none of those, and a ban grounded in them stands regardless of code quality.

QEMU's policy does leave room for other uses: AI for researching APIs, static analysis or debugging is fine "provided their output is not included in contributions." fast-check makes a related point about disclosure, which "does not make an unacceptable contribution acceptable." Where a project says no, the respectful response is to follow the policy.

Review your agent's PR before a maintainer has to

The useful lesson sits inside teams' own repositories, and in projects whose policies allow AI assistance with conditions. Reviewers there carry the same six costs, whether they're maintainers or colleagues. Mapping the costs to questions gives a pre-review checklist for any agent-generated pull request:

• Can the author explain every change, and the intent behind it?
• Did someone run the change, and reproduce the bug it fixes?
• Is the PR small enough to review in one sitting, and was the scope agreed first?
• Does the description say what changed and why, in the author's words?
• Does the PR add agent configuration files the project didn't ask for?
• Is the provenance of the code clear enough for the project's license?

A pull request that passes all six arrives cheaper to review. One that fails the first two shouldn't reach a reviewer yet.

Choose Qodo when agent PRs need a first review before people spend time on them

Qodo, the AI code review platform, covers part of that checklist on teams' own repositories. Qodo in your Git reviews each pull request with context from the wider codebase and applies the team's custom instructions, so missed team standards and other instruction-backed checks surface before a reviewer starts reading.

For high-velocity teams, custom instructions or a pr_compliance_checklist.yaml file at the repository root get checked on every PR, with no new process. Enterprise engineering teams can apply the same custom instructions once at organization level, so the same checks apply whichever team owns the repo.

The limits are firm. Qodo can't make a contribution acceptable to a project that bans AI-generated content, and it isn't a way to disguise one. Explaining the change, writing the description and agreeing the scope still belong to the author. Qodo flags; your team decides.

Qodo no longer offers test generation; it focuses on AI code review and code governance.

The first pass is most useful when the team's instructions ask Qodo to flag missed standards, so a person spends time on the questions only an author can answer: whether they can explain the change, and whether they ran it.

FAQ

Which open-source projects ban AI-generated code?

On November 12, 2026, Open Source Says No listed 23 projects as Banned. The list includes yt-dlp, immich, Meilisearch, Servo, stb, QEMU, libvips, Zig and Gentoo Linux. The list changes, so check the site and each project's own policy.

Why do open-source maintainers reject AI-generated pull requests?

The reasons in the policies quoted here include review time, code the contributor can't explain, untested changes, generated descriptions, unclear licensing and ethical concerns. Different projects weigh them differently.

Can I use AI tools to contribute to open source?

Depends on the project. Of 220 projects in the catalog, 191 are Restricted, typically requiring disclosure and human understanding, and 6 allow assistance. Read the project's CONTRIBUTING or AI policy file before opening anything.

What is an AI_POLICY.md file?

A file some projects keep alongside CONTRIBUTING.md to state their rules on AI-assisted contributions. gh-dash, fast-check and PyTorch each have one.

Does disclosing AI use make a contribution acceptable?

Not where a project bans it. fast-check says disclosure "does not make an unacceptable contribution acceptable." In Restricted projects, disclosure is often required but not sufficient on its own.

Is every listed project a ban?

No. Only 23 of the 220 projects carry the Banned label. Restricted is by far the biggest group.

Why do some lists say 22 projects?

Two listicles dated November 11 counted 22. The catalog showed 23 Banned projects on November 12, with yt-dlp's entry last verified on November 11.

Does the Linux kernel refuse AI PRs?

No. The Linux kernel is labeled Restricted. The kernel's guidance asks contributors to understand their entire submission and be ready to respond to review comments.