QGIS bans AI-assisted code: which open-source projects ban AI contributions, and why

QGIS, the open-source geographic information system, now refuses code written with any AI help in its main repository. Its revised policy says plainly: "No LLM, AI or agent assisted code contributions are allowed." A Hacker News post on October 12, 2026, "QGIS enacts moratorium on AI contributions," drew hundreds of comments. QGIS joins a short list of open-source projects that ban AI contributions outright, while others such as LLVM, curl and the Linux kernel accept AI-assisted coding-agent work under disclosure rules. This analysis looks at what QGIS decided, which other projects have published policies, and the reasons on both sides.

It is based on QGIS's enhancement proposals and developer mailing list, and on each project's own policy pages and contribution guides, checked October 16, 2026. Projects whose policies couldn't be confirmed from their own documents are left out.

The short version

• QGIS: QEP 428, approved on October 7, 2026, replaced its earlier "human in the loop" rules with a flat ban on AI-, LLM- and agent-assisted code in the qgis/QGIS repository. Its pull-request template now asks contributors to certify they used none.
• Other bans: Gentoo (2024), NetBSD (2024), QEMU (2025) and Servo ban or presume against AI-generated contributions.
• Disclosure instead of a ban: LLVM, curl, llama.cpp and the Linux kernel allow AI help if a human reviews it, discloses it and takes responsibility.
• The reasons: maintainers' review time, uncertain copyright and licensing, code quality and, for some projects, ethics.
• Not about software: "Why We're Banning AI," which drew more than 230 points on Hacker News after it was posted on October 15, is from Current Affairs, a magazine. It isn't an open-source project.

What did QGIS decide?

The policy went through four stages:

1. January 31, 2026. QGIS's first AI policy, QEP 408 by Even Rouault, was adapted from LLVM's policy. It allowed AI tools as long as a human reviewed the output and labeled substantial AI-generated content.
2. April to September 2026. In April, a developer-list thread asked whether to "ban AI based contributed from non-core developers?" In a message from April 1 quoted in that thread, developer Stefanos Natsis said a no-AI policy "will improve the SnR of new PRs" (SnR: signal-to-noise ratio) and that the project already struggled "with a queue of ~100 PRs." On September 15, core developer Nyall Dawson proposed a "complete and total moratorium" on LLM-assisted contributions. He wrote: "We've tried gentle policies regarding this up till now, but clearly that's not helping." His email also proposed a "proof of life" for new contributors: a financial donation to the project before their first contribution is accepted.
3. September 24, 2026. After project steering committee (PSC) member Tim Sutton replied on September 23 that the PSC was "fine with" banning AI and LLM use in the repository and suggested the formal QEP process, Dawson submitted "QEP428: No ai contributions permitted" as pull request #387. It rewrites the QEP 408 document as version 2.0, dated September 24 and credited to "the QGIS project contributors."
4. October 7, 2026. Dawson moved the proposal to a vote on October 5 and, on October 7, declared it "approved" with +1 votes from Even Rouault and the GitHub users alexbruy, signedav and elpaso. GitHub shows PR #387 merged the same day.

The policy now on QGIS's master branch reads: "No LLM, AI or agent assisted code contributions are allowed in the https://github.com/qgis/qgis repository. If we subsequently discover that you have used an AI, LLM, or any agent-based workflow for your contribution, you will be subject to code reversion and contributor rights sanctioning." The pull-request template adds a checkbox certifying that no AI tools "were used or supported my development of this PR." QGIS's QEP process requires at least two +1 votes from core developers or steering committee members. Besides the four votes Dawson cited, the PR thread shows other +1s, and one +0 from a developer who said they would open another QEP to raise further discussion.

Dawson said the intention was to "start with a closed door, which we can then selectively open a little if/when it's safe and proper discussion has been made on that." Rouault called it "a stop gap measure." There was dissent. One commenter argued the wording also rules out using LLMs for review, auditing and security work. Others asked whether it covers issues and comments. A follow-up, QEP 430, opened on October 11 and still open, would extend the ban to all text in the repository, with an exception for translation. One contributor summed up its case on the PR: "It's not ok to ask humans to read, understand, or otherwise interact with LLM-generated text."

Which other open-source projects ban AI-generated contributions?

These are policies published by the projects themselves:

Last verified: October 16, 2026

The details differ. QEMU's code-provenance page excludes "other uses of AI," such as research, static analysis or debugging, as long as the output stays out of the contribution. In May 2026, Linuxiac reported a proposal from QEMU maintainer Paolo Bonzini to allow small AI-assisted fixes with an AI-used-for: trailer. As of October 16, the published policy hasn't changed and lists no approved exceptions. Gentoo's policy says it "can be revisited" if a tool raises no copyright, ethical or quality concerns. NetBSD's rule isn't absolute: core can approve exceptions in writing. Servo calls its position "a cautious approach" that it is "open to revising." Its FAQ allows AI tools for translating into English and for finding bugs, as long as contributors verify the findings themselves.

Who allows AI, and on what terms?

The larger counter-position isn't "anything goes." It's disclosure plus accountability:

• LLVM. Its AI Tool Use Policy, which QGIS's first policy copied, lets contributors use any tool but requires "a human in the loop." Contributors must review all generated code before asking for review and be "able to answer questions about their work." It bans agents that act "without human approval," naming GitHub's @claude agent. It also bars AI on issues labeled "good first issue."
• Linux kernel. The kernel's coding-assistants guide says "AI agents MUST NOT add Signed-off-by tags" and asks for an Assisted-by: tag. Its tool-generated content guidelines start from the same worry as QGIS, that "reviewer and maintainer bandwidth is a scarce resource," but answer it with transparency rather than a ban. Linus Torvalds disclosed that Claude Code wrote his experimental page-cache patches "under my direction."
• curl. Its contribution guide accepts "code written with the help of AI" that meets normal standards. It requires reporters to disclose AI use in bug reports and bans "immediately" anyone who submits "made up fake reports." curl ended its HackerOne bug bounty on January 31, 2026. BleepingComputer quoted maintainer Daniel Stenberg: "The main goal with shutting down the bounty is to remove the incentive for people to submit crap."
• llama.cpp. Its contributing guide says "AI-generated code is allowed. You are 100% responsible for every line." It requires disclosure and a manual review "at least" as long as a normal code review. It prohibits using AI to write bug reports, PR descriptions or replies to humans. Undisclosed use can bring a permanent ban.

Why are projects banning AI contributions?

The published policies give four reasons:

1. Reviewer time. This is the reason almost every project gives, including those that allow AI. An AI-assisted pull request costs the author little to produce but costs a volunteer reviewer the same time as any other. Servo cites "plausible-looking code" that contributors don't understand and haven't tested. QGIS's QEP 408 called these "extractive contributions," with a "golden rule" that a contribution should be worth more than the time it takes to review.
2. Copyright and provenance. Gentoo, NetBSD, QEMU and Servo all cite uncertainty over who owns model output and whether it reproduces licensed training data. For projects that rely on the Developer Certificate of Origin, the question is whether a contributor can honestly certify code they didn't write.
3. Quality and security. Servo says AI output can't be trusted to consider the security issues a browser engine must handle. curl's experience with fabricated vulnerability reports is the best-documented example.
4. Ethics. Gentoo and Servo cite energy and water use and labor concerns. Not every project shares these concerns. At QGIS, steering committee member Tim Sutton advised against putting "any rationale" in the policy, saying that "takes us down a rabbit hole," and the adopted text gives none.

What does the evidence say?

The clearest outside evidence for the reviewer-time argument is a working paper by Harvard's Fiona Chen and James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production" (current version August 4, 2026). Ars Technica covered it under the headline "AI coding agents generate more code, but not more software," and the Hacker News thread on the article drew 364 points and 310 comments on October 12.

• The data: activity on Jellyfish, an engineering analytics platform, at 718 firms and about 726,000 workers from January 2021 to March 2026.
• The method: a staggered difference-in-differences design comparing firms before and after they adopted AI tools.
• The result: after firms adopted coding agents, lines of code per worker rose 30%, commits 20% and pull requests 23%. But review time rose 49%, the share of PRs needing changes nearly doubled, and resolved Jira issues didn't change significantly.
• The limits: these are companies, not volunteer projects. The data comes from one vendor's customers, and the paper is a job-market paper, not a peer-reviewed publication.

The direction matches what maintainers report: more code arrives, and the cost lands on reviewers. Vals AI's October 9 multi-agent study found a related pattern on cost: agent teams cost 1.8 to 5.1 times as much as single agents, with a statistically significant quality gain in only one of four comparisons.

What's at stake for contributors?

• Enforcement is hard. Sutton wrote on the list, "We know this is difficult to enforce." The sanction applies "if we subsequently discover" AI use. Asked on the PR on October 14 how the ban would be enforced, one contributor replied: "By trust." QGIS's CONTRIBUTING.md also carries a note addressed to "automated agents," telling them to add three robot emoji to PR titles to be "fast-tracked." The project hasn't explained the note publicly or said how such PRs are handled; read alongside the ban, one effect is that agent-opened PRs would be easy to identify. Sutton's September 23 reply asked for "easter eggs" to be removed from CONTRIBUTING.md.
• Background agents raise the stakes. Tools now run agents in the background and open pull requests on their own, as OpenCode 2.0 does with background subagents. Most of the policies above, LLVM's explicitly, prohibit agents that post without a human approving each action. That matches the argument in our case against unattended agents.
• Read the policy before you open a PR. The same AI-assisted patch could be welcomed with an Assisted-by: tag in the kernel, need a disclosure and an hour of self-review at llama.cpp, and be reverted at QGIS.

What's confirmed, reported and uncertain

• Confirmed from project documents:
  • QGIS's policy text, template checkbox and QEP history, including QEP 428's approval and merge on October 7, 2026
  • the Gentoo, QEMU, Servo, LLVM, Linux kernel, curl and llama.cpp policies as published on October 16
  • NetBSD's current guideline text
• Reported:
  • NetBSD's May 2024 adoption (OSnews, May 15, 2024)
  • the end of curl's bounty (BleepingComputer, January 22, 2026)
  • QEMU's proposed relaxation (Linuxiac, May 29, 2026)
• Uncertain:
  • whether QEP 430 will pass
  • how QGIS will enforce the ban
  • whether the projects that ban AI will revisit their policies as copyright questions settle