QGIS Draws a Hard Line on AI-Assisted Code Contributions

One of the strangest parts of an AI coding assistant is how quickly it can produce something that looks finished. A pull request (PR)—a proposed change submitted for review—may arrive with a tidy code diff, passing tests, and a confident explanation. Yet a maintainer still has to reconstruct the author’s intent, check the edge cases, and decide whether the change belongs in a large geographic information system (GIS), software that stores, analyzes, and displays data tied to locations.

That mismatch sits behind QGIS’s new AI policy. As of October 12, 2026, the project has moved from a human-in-the-loop approach to a strict ban on AI-assisted code contributions in the main qgis/qgis repository. The policy was accepted and merged on October 7, 2026, after a discussion that began in September. Why would an open-source project reject code that compiles? The answer is less about whether AI can write code and more about who pays for understanding it. (github.com)

The headline needs a footnote

QGIS is an open-source GIS: a mapping and spatial-analysis application whose source code can be inspected, changed, and shared. The final policy specifically names code contributions to the main QGIS repository. It does not automatically rewrite the rules for every QGIS plugin, website, or community project. The QGIS Website repository, for example, maintains separate guidance that permits large language models (LLMs)—systems that generate text or code from patterns in training data—as assistants when their output is disclosed and checked by a human.

There is also a small naming wrinkle. The proposal was discussed in pull request #387 as QEP 428, where QEP means QGIS Enhancement Proposal. The merged change, however, revises the existing QEP 408 file, qep-408-ai-tool-policy.md, and the QGIS proposal index lists number 408 as the approved AI policy. That history matters because the project is not adding a completely separate rule; it is replacing the earlier one.

From human review to a closed door

The earlier version of QEP 408, dated January 31, 2026, took a permissive position. Contributors could use whatever tools they wanted, provided a human reviewed the result, accepted responsibility for it, and disclosed substantial machine-generated content. An AI agent that acted in GitHub without human approval was not allowed, but manually reviewed documentation or code could still be submitted.

The revised policy is much shorter and much harder to misread. It says that no LLM-, AI-, or agent-assisted code contributions are allowed in the main QGIS repository. If the project later discovers that an AI workflow was used, the change may be reverted, meaning removed or rolled back, and the contributor’s rights may be restricted. The policy was approved with multiple core-project votes and merged into the proposal repository on October 7. (raw.githubusercontent.com)

The bottleneck is review, not typing

A code review is not a spelling check for programming. Reviewers examine whether a change fits the project’s design, handles unusual data, preserves compatibility, includes useful tests, and will still make sense to the next person maintaining it. In a complex mapping application, a patch can pass a narrow test while quietly violating assumptions elsewhere.

That is why the QGIS discussion focused so heavily on maintainer capacity. AI tools make it cheap to generate many plausible patches, but they do not make careful review happen faster. Maintainers described a stream of contributions large enough to leave more pull requests unreviewed or force rushed reviews that miss quality problems. The earlier QEP used the term extractive contribution for work that shifts more effort onto the reviewers than value back to the project.

The distinction is easy to miss from outside an open-source project. A contributor may feel that a ten-line fix is a gift. A maintainer may see an hour of archaeology: finding the original bug, checking related providers, testing different data sources, and deciding whether the proposed solution creates a future maintenance burden. The code may be small. The responsibility is not.

The community is protecting a learning path

There is a second concern beyond review queues. People usually become strong open-source contributors by starting with small changes, learning the project’s conventions, answering questions about their patches, and gradually building enough context to review someone else’s work.

An LLM can interrupt that progression. A beginner may describe a complicated regression, receive a convincing patch, and mistake a working-looking answer for real understanding. One participant in the QGIS discussion described this as an illusion of competence: the code appears within reach, but the contributor may not yet be able to explain why it works or what could break next. That weakens the trust between contributor and reviewer, while also making it harder for new contributors to grow into future maintainers.

This is not an argument that beginners should stay away. It is an argument that the contribution itself should carry evidence of learning. A small, well-understood bug fix can be more valuable than a sweeping patch assembled in minutes, because it gives the project a change and gives the contributor a path into the community.

What the new rule means in practice

The old workflow looked something like this:

AI-assisted draft → human review → disclosure → submit

For code destined for qgis/qgis, the conservative reading of the new policy is now:

AI-assisted code → do not submit upstream

That means disclosure is no longer a permission slip. Adding an Assisted-by note may have been transparent under the earlier policy, but transparency alone does not make an AI-assisted code contribution acceptable under the revised rule.

The boundary around submitted code is clear enough, but several edge cases remain unsettled. During the discussion, contributors raised LLM-backed autocomplete, brainstorming, translation, AI-generated code review, and using an assistant to understand an error before writing a fix manually. The final policy does not provide a detailed decision table for those situations. Project members indicated that future proposals could consider individual use cases, but the first step was to close the door rather than keep expanding an unclear exception list. (github.com)

For now, the practical lesson is straightforward: code submitted to the main QGIS repository should be written without AI assistance, and contributors should read the local rules for other QGIS repositories or non-code work. The policy may evolve, but the current default is deliberately strict.

QGIS has not claimed that AI can never be useful. It has decided that, for this codebase and this moment, the cost of proving that usefulness falls too heavily on maintainers. The closed door is a way to restore review capacity, preserve trust, and keep human understanding at the center of upstream contributions.