QGIS Formally Says No to AI Contributions: Behind the Ban, Open Source Communities' Review Capacity Is in Collective Crisis

One Year of Experimentation, Fifty Rejected PRs

On September 24, 2026, QGIS core developer Nyall Dawson submitted QEP428 to the project's proposal repository, proposing to upgrade the AI contribution policy from "human oversight" to a comprehensive "strict prohibition." The proposal completed voting in early October and was formally merged. The new rule is explicit: it prohibits any code submission completed with the help of large language models, AI agents, or automated workflows; contributors found in violation after the fact will face forced code rollback and restrictions on their contribution rights.

This was not a sudden turn. QEP428's direct predecessor was QEP408—a "human oversight" policy in place for about a year, requiring contributors to label AI-assisted content and guarantee a "human in the loop." The results are documented: about 50 PRs were tagged as AI-assisted, of which about 40 were closed outright after review and never merged. A large amount of unlabeled AI-generated content also entered the review queue during the same period. The cumulative effect: the project lost at least one high-value contributor due to review pressure.

An Asymmetric Dilemma: Generation Costs Approach Zero, Review Costs Stay Constant

In the discussion, QGIS project steering committee member and GitHub user haubourg offered this diagnosis: "AI submissions have placed enormous, unsustainable pressure on our maintainers—who were already saturated with work before the era of large language models arrived. AI traffic far exceeds human review capacity, which either leads to an ever-growing pile of unreviewed PRs or forces reviews to become perfunctory; neither outcome is acceptable to the project." He pointed out: "The cost of generating a PR is extremely low, while the cost of reviewing it is extremely high, and this asymmetry will only grow."

A skilled AI user can mass-produce dozens of code submissions in a single day; reviewing a non-trivial PR, by contrast, requires a senior maintainer to trace code context, test edge cases, consider compatibility with the project's long-term architectural intent, and confirm adherence to community norms—work that cannot be compressed, let alone outsourced. AI tools have driven the supply curve sharply upward, while review bandwidth remains a slowly creeping horizontal line.

The Enforcement Weak Spot: A Ban Written on an Honor System

Enforcement of QEP428 relies almost entirely on contributors' self-reporting. There is currently no mature technical means to reliably detect AI-generated code, and both false-positive and false-negative rates fall short of what engineering-grade gating would require. Developer Kannes noted in the discussion that the proposal's broad wording could inadvertently penalize legitimate uses, such as using AI to assist with code review or security audits. Nyall Dawson responded that QEP428 is a "strict starting point" that leaves room to relax the rules later for specific scenarios.

For contributors intent on evading it, the ban is effectively a dead letter. But until AI content detection technology matures, a blanket ban backed by an honor system carries lower enforcement costs and sends a clearer community signal than a leaky, selective-disclosure regime.

Industry Consensus Is Converging

QGIS is not an isolated case. According to public reports, on July 29, 2026, the GCC steering committee announced a ban on any code submissions containing AI-generated content, covering even "AI-derived content modified by humans"; that same month, code hosting platform Codeberg announced a ban on projects generated primarily by LLMs; in August, Oracle imposed a temporary ban on AI contributions to OpenJDK, with its core concern being ambiguity over licensing and intellectual property ownership. Godot, Zig, NetBSD, GIMP, Gentoo, and qemu have also issued similar policies in succession.

Not all projects have moved toward an outright ban. The Linux kernel and LLVM chose another path: permitting AI-assisted contributions but requiring disclosure and placing final responsibility on humans. The divergence between these two paths reflects a real difference—mega-projects with more full-time engineers involved in review have greater bandwidth to absorb the extra load, while community projects maintained by volunteers have review capacity closer to a hard ceiling, with no slack to spare.

This Is an Emergency Declaration, Not a Final Verdict

This wave of AI contribution bans in the open source world is essentially filling a governance vacuum that had previously been quietly avoided. When AI tools push the marginal cost of "sending a contribution request" close to zero, the existing open source collaboration infrastructure—trust-based submission processes, human-driven review mechanisms, and a contribution culture sustained by community cohesion—was not prepared to handle the resulting scale shock.

AI tools can indeed quickly generate formally correct, clearly structured code, but there is a real gap between "it runs" and "it can be merged into the mainline codebase": the latter requires that a contribution align with the project's long-term architectural intent, maintenance conventions accumulated over decades, and an understanding of the context behind historical decisions. These judgments cannot be replaced by mass-produced automated tools, nor easily bypassed through a "final human sign-off."

QEP428 is QGIS's pragmatic response to its current predicament, but the answer it offers has a clear expiration date. Once reliable AI content detection tools emerge, or the community develops genuinely effective automated verification processes, the necessity of the current ban will inevitably come up for review again. The real value of this ban lies in forcing the entire open source industry to confront an unavoidable issue: the next generation of collaborative governance rules must find a new balance between contribution velocity and review capacity.