QGIS Bans AI-Assisted Code to Protect Review Capacity

A human check no longer makes an AI-assisted patch eligible for contribution to QGIS. The open-source geographic information system has accepted a strict prohibition on AI-assisted code contributions, replacing its previous human-in-the-loop approach.

QEP428, proposed on September 24 and merged on October 7, 2026, formalizes what its author, Nyall Dawson, described as a strict “NOT ALLOWED” policy. Supporters gave a practical reason: contributors can produce changes faster than maintainers can responsibly review them.

QGIS is a notable counterpoint to agent-friendly development workflows. Its decision puts the focus on whether a project has the people, time and trust to evaluate a patch and maintain it afterward, even when AI can produce something useful.

The Rule Covers Assistance, Not Just Autonomous Agents

The operative wording, reproduced in a developer analysis of QEP428, is blunt:

“No LLM, AI or agent assisted code contributions are allowed in the qgis/qgis repository.”

The rule covers both AI-generated and AI-assisted code. It extends beyond bots opening pull requests without human supervision: a contributor’s presence in the workflow does not, by itself, satisfy the policy.

Disclosure offers no exemption either. A disclosure rule would permit AI-generated material under specified conditions; QGIS has adopted a prohibition.

The stated scope is code contributions to the QGIS repository. That does not amount to a ban on users applying AI to their own geospatial work, or extend to every independently maintained QGIS-related project.

Some boundaries within the contribution workflow remain unresolved. In the proposal discussion, participant vpicavet asked whether the restriction should also cover issue content, comments and the enhancement-proposals repository. Participant kannes questioned whether broad terms such as “assisted” could prohibit using an LLM to understand existing code or review a human-written change.

The short rule leaves room for questions about individual tools and activities. Contributors should not assume that autocomplete, translation or AI-assisted review has a blanket exemption. The discussion also does not justify treating every such edge case as conclusively settled.

Maintainers Say the Bottleneck Is Review

Project member haubourg made the clearest argument for the change in the proposal discussion. They described AI use by external contributors as placing “massive and unbearable pressure” on maintainers who already faced a demanding job.

In their account, the incoming stream exceeds what human reviewers can seriously examine. Maintainers are left with two unattractive choices: accumulate unreviewed pull requests, or accept changes without sufficient scrutiny.

The discussion records maintainers’ judgment that the current contribution process is imposing an unsustainable burden. It supplies no controlled comparison showing how much longer AI-assisted patches take to review, nor does it establish that every such patch is defective. The claim concerns maintainer capacity, not a published measurement of AI coding performance.

A patch can be plausible, pass its immediate tests and still require substantial work to establish whether it belongs in a mature codebase. Reviewers must assess how the change interacts with existing behavior, whether it addresses the underlying problem and whether its author can respond meaningfully to questions. Cheaper patch production can increase the number of those judgments without making them any cheaper.

haubourg also raised concerns about community relationships. Organizations’ ability to contribute back, hire contributors for support and training, and fund feature development depends on a functioning human network. Protecting time for human contributions was part of their case for the ban.

Beyond managing the review queue, a project needs contributors who can develop enough understanding to become future reviewers. A larger supply of proposed changes alone does not meet that need.

One Contributor Explained Why Human Oversight Was Insufficient

Amalvir supported the prohibition despite saying it directly affected their own contributions.

In the GitHub discussion, they described submitting two AI-assisted regression-fix pull requests, using models to investigate bugs, suggest fixes and review code. They then acknowledged that they did not yet have sufficient knowledge to fix bugs confidently in a project as complex as QGIS.

Their account captures a weakness in a loosely defined human-in-the-loop policy: a person can supervise the interaction without possessing the expertise needed to validate the result.

Amalvir described the apparent ease of obtaining a fix as an illusion and said the process had broken a trust contract between contributor and reviewer. They also worried that relying on AI this way could limit the learning needed to become a stronger contributor.

One contributor’s retrospective account cannot prove that AI-assisted developers generally fail to learn or understand their work. It also does not establish that these two pull requests alone caused QGIS to adopt the policy.

Still, the account helps explain why “a human reviewed it” may leave maintainers’ concerns unresolved. What could that human independently verify? If a contributor cannot defend the diagnosis or explain the implementation, the reviewer may inherit much of the investigation as well as the review.

QGIS’s new policy avoids negotiating that distinction separately for every AI-assisted submission. The cost is that potentially useful contributions are excluded alongside weak ones.

Enforcement Is Framed Around Discovery and Consequences

The enforcement language discussed before adoption acknowledges that prohibited assistance will not always be visible.

A contemporaneous account of the mailing-list discussion reproduces Tim Sutton’s proposed warning:

“We know this is difficult to enforce, but if we subsequently discover that you have used an LLM for your contribution, you risk code reversion and contributor rights sanctioning.”

Under that formulation, discovery can happen after a contribution has been accepted, and consequences can affect both the code and the contributor’s ability to participate. The word “risk” describes possible sanctions, rather than an automatic penalty specified for every violation.

The language establishes no reliable AI-code detector, fixed evidentiary threshold or detailed sanction schedule. QGIS should not be presented as having solved the technical problem of identifying a patch’s provenance.

Contributors are expected to honor the policy, backed by the possibility of action when a violation becomes known. Difficulty detecting every violation does not make the rule meaningless, but practical questions about evidence and consistent application remain.

A blanket prohibition reduces the need to negotiate approved AI workflows. Its broad wording can nevertheless leave maintainers adjudicating boundary cases.

Participant rouault-on-strike explicitly called the QEP a “stop gap measure” in the discussion. That describes one supporter’s position; it supplies neither an expiry date nor a commitment to relax the accepted rule.

The Counterpoint Is About Who Bears the Work

The decision drew hundreds of comments in a Hacker News discussion. That attention documents interest and disagreement, not a representative verdict from developers.

Some participants discussed their own mixed experiences with AI in geospatial programming. mootothemax described errors involving coordinate systems and distance calculations; Waterluvian reported useful assistance with spatial-validation work while also emphasizing supervision. Neither account is a benchmark of QGIS contributions.

The more consequential issue is governance. Where an agent-friendly contribution policy asks how automated work can be admitted safely, QGIS asks whether its maintainers should have to process that work at all.

For the AI industry, this places an uncomfortable limit on contributor-side productivity claims. A faster submission is not necessarily a net saving when verification, correction and long-term ownership fall to someone else.

QGIS’s policy establishes that the project is unwilling to absorb the review burden associated with AI-assisted contributions under its current conditions. It does not demonstrate that coding agents cannot produce good code.

The test will be whether the decision preserves review capacity and contributor trust without consuming comparable effort in enforcement disputes. Other maintainers can borrow the boundary, but they will still have to decide its scope, explain exceptions and handle violations. QGIS provides a concrete governance precedent, not a technical shortcut around those responsibilities.