QGIS bars AI-assisted code contributions to its core repository

QGIS now bars AI-assisted code contributions to its core qgis/qgis repository, under a policy approved on October 7, 2026. The published rule has no expiry date; it does not ban every use of AI with QGIS software. Suppose you ask a coding agent to investigate a bug and then test its patch: a working result does not by itself make that contribution acceptable.

On October 7, 2026, QGIS approved and merged a change to its AI tool use policy. Its operative text is only two sentences: no LLM-, AI-, or agent-assisted code contributions to qgis/qgis; if such assistance is discovered later, the contribution may face reversion and the contributor may face sanctions on contribution rights. This is a rule about submitting code to a named repository. It is not a ban on using QGIS software with AI, a published rule for every QGIS-related repository, or a verdict that every AI-assisted patch is defective.

The distinction matters because the debate that led to the vote ranged much more widely: reviewer workload, the identity of new contributors, autocomplete, code review, and what a fair future exception might look like. Only the enacted language defines the current rule. The contributors’ discussion explains why it was adopted—and why a two-sentence policy cannot settle every edge case.

What does QGIS’s AI contribution policy actually prohibit?

The published AI tool use policy, version 2.0 says:

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 words “assisted” and “code contributions” do important work. This is broader than a narrow rule against pasting code that a chatbot generated in full; at the same time, the object is a contribution of code to a specific repository. The second sentence addresses discovery after a contribution, so acceptance of a pull request should not be mistaken for a permanent clearance. It describes possible reversion and restrictions on a contributor’s rights, not a stated automatic outcome or a legal judgment about ownership.

What the short policy does not do is provide an approved list of tools, a definition of “assisted” by percentage of code, or examples covering every kind of contact with an AI system. In the proposal discussion, contributors asked whether issues, comments, documentation, review, autocomplete, brainstorming, translation, or search results containing AI text would count. Those questions show where readers might need guidance. The final two sentences do not expressly decide each example; neither does silence create an exception.

One contributor suggested changing the text to ban code written by an AI rather than code assisted by one. A project steering committee member replied that, in good conscience, the contributor should have written the code they want to share. That exchange is a useful view into intent, but the adopted wording remained “assisted.” Treating the comment as an official carve-out for every tool named in the discussion would rewrite the policy without a new decision. Likewise, another participant asked why the restriction named qgis/qgis rather than all project repositories; the response was that the steering committee had requested that wording. It does not justify extending this particular text to the other repositories by implication.

The practical boundary is therefore clear for AI-assisted code patches, but not exhaustively defined for every adjacent use of a tool. A human review or disclosure is not an exception written into the policy.

How did a proposed pause become an approved QGIS policy?

The final policy did not spring from a single viral complaint. In a September 16 developer-list proposal, preserved in the discussion thread, developer Nyall Dawson raised two ideas: an immediate moratorium on LLM-assisted contributions and a separate “proof of life” requirement for new contributors. A small donation was floated as one possible way to screen out automated or low-effort submissions. Dawson also acknowledged that the second idea was more difficult and contentious.

It is tempting to collapse those proposals into “QGIS now makes contributors pay.” That would be wrong. The adopted policy text contains no donation, identity-document, or face-to-face requirement. The archived exchange shows that another contributor opposed a payment barrier, pointed to the cost of entering this kind of development, and suggested a demonstration of a working pull request instead. A different developer supported a pause while the group considered contributor verification. These are competing suggestions in an open discussion, not clauses enacted in October.

On September 23, steering committee member Tim Sutton proposed a narrower route in the same developer-list thread: specify the scope of prohibited code contributions, put the policy through the project’s QGIS Enhancement Proposal process, and then work out how to communicate and enforce it in the contribution workflow. The message explicitly acknowledged enforcement would be difficult. The project then opened proposal PR #387 on September 24. According to its public timeline, it moved to voting on October 5; on October 7 the proposer declared it approved, and the PR was merged shortly afterward.

There was an earlier pull-request-template intervention in the core code repository, but that PR’s history also links a subsequent revert. The durable development here is the approved QEP policy, not a claim that a September template edit alone made permanent law. Keeping these events separate gives contributors the right reference point: the published policy and its merged proposal.

The hard limit is reviewer attention, not the time needed to produce a patch

The reason voiced most concretely in the proposal discussion is a mismatch in throughput. One contributor argued that incoming AI-assisted work could arrive faster than maintainers could review it seriously, leaving either more unreviewed pull requests or less thorough review. They connected reviewer bandwidth to the project’s ability to welcome human contributors. That is a participant’s account of the pressure on maintainers, not a published measurement of how many pull requests QGIS received or how many were faulty.

A self-described beginner contributor offered a particularly uncomfortable example. They said they had opened two AI-assisted regression-fix pull requests, using an LLM to investigate causes, suggest fixes, and review code. They then questioned whether the tools had given them a misleading sense that they understood a codebase complex enough to review their own changes. Their reflection does not establish that those particular fixes were wrong. It does illuminate a trust problem: the person who sends a patch and the person who must approve it may not have the same understanding of how the patch was made or what it might break.

There were serious objections as well. Another participant in PR #387 described using an LLM to find non-obvious context in C++ code, or to simulate an early reviewer and catch problems before bothering a human colleague. They argued that the broad word “assisted” might rule out useful, human-verified help. A later commenter raised more granular questions about IDE autocomplete, translation, brainstorming, and accidental exposure to AI-generated search summaries. Those examples differ in how much they shape the submitted code; the policy currently does not publish a taxonomy that sorts them.

The project’s debate, then, was not a simple contest between people who value correct code and people who do not. It was about who absorbs the work of checking a rapidly produced change. A contributor can spend less time writing a plausible fix while the maintainer still needs to understand the affected subsystem, reproduce the problem, inspect the patch, and own the long-term consequences. Conversely, help that catches an error before review could save that same maintainer time. The public record contains arguments and experiences on both sides, not a controlled study proving that one outcome always wins.

That uncertainty helps explain the deliberately restrictive starting point. In the PR discussion, Dawson said they did not intend the rule to be “written in stone, forever”: future uses such as autocomplete or translation could be argued individually. Another participant likewise called it an initial policy. Neither statement is a sunset clause. The enacted text names no expiry date and lists no approved future exception; the door could be opened only through a later project decision.

What should a prospective contributor do next?

If your intended contribution is code for the main qgis/qgis repository, begin with the actual two-sentence policy, not a paraphrase of the initial mailing-list proposal. If an AI system or coding agent assisted your work on the code you intend to submit, do not assume that testing the result, rewriting a portion, or adding a disclosure makes it eligible. The published policy offers no such safe harbor. If your work did not use those tools, be ready to explain the bug, the change, and the verification yourself; that is good contribution practice, not a special attestation mandated by these two sentences.

For a contributor whose workflow includes a gray-area tool, the honest next step is to ask for clarification rather than guess where the boundary sits. The questions about autocomplete and review in the proposal thread are evidence that even project participants wanted more precise examples. Likewise, do not infer from the policy’s named repository that every other project surface has an affirmative AI-use permission. Different repositories, documentation changes, and issue comments require their own applicable guidance. The two-sentence QEP does not resolve them by itself.

Maintainers have an equally concrete choice ahead: if experience shows that some assisted workflow lowers rather than raises review cost, someone can make that case with a specific use, verification method, and policy amendment. The approved restriction is the present rule. The discussion about how to revise it remains open, and neither a good patch nor a good argument silently changes the text contributors must follow today.