# QGIS AI policy moves from human-in-the-loop to no AI-assisted contributions

> Pull request #387, opened September 24, 2026 and moved to voting on October 5, would replace QGIS's human-in-the-loop rule with a strict NOT ALLOWED policy. The thread describes no detector and no defined penalty. The proposed test is whether you wrote the code yourself.

- Published: 2026-10-12
- By: Samir Sengupta (https://www.samcodeman.com/about)
- Canonical: https://www.samcodeman.com/writing/qgis-ai-policy-no-ai-assisted-contributions
- How this was made: Drafted with Claude, Anthropic's model from 1 cited source, then checked against it in a second editing pass; read and approved by Samir Sengupta on 2026-10-14. Editorial policy: https://www.samcodeman.com/editorial-policy
- Disclosure: I build Wayne, an AI coding harness for VS Code, and Omnitron, an agent harness, so I work in this category.

## The short version

- PR #387 ("Add QEP428: No ai contributions permitted") changes QGIS's AI policy to a strict NOT ALLOWED rule, replacing the earlier human-in-the-loop policy. It moved to the voting stage on October 5, 2026.
- The previous policy did not work in practice. Roughly 50 PRs were tagged AI Assisted, roughly 40 of those were closed without merging, and the extractive tag was never created.
- The sources describe no detection tool, disclosure form or defined penalty. The compliance measure timlinux proposed is "did you in good conscience write the code yourself".
- The author calls it a closed door to be opened case by case later, for uses such as IDE autocomplete or language translation. Until then, broader uses such as LLM pre-review are read as excluded.

QGIS's proposed AI policy bans AI-assisted contributions outright. On September 24, 2026, nyalldawson opened pull request #387 on the QGIS-Enhancement-Proposals repository, titled "Add QEP428: No ai contributions permitted". It "formally changes the AI policy to a strict 'NOT ALLOWED' policy", replacing the previous human-in-the-loop rule, under which roughly 50 PRs were tagged AI Assisted and roughly 40 were closed without merging. There is no detector or disclosure step in the sources. The proposed compliance test is whether the contributor, in good conscience, wrote the code themselves.

The numbers can be confusing. 387 is the pull request number, the PR title names QEP428, and the review comments are attached to the file qep-408-ai-tool-policy.md. nyalldawson described the change as "a correction to the earlier QEP" rather than a separate policy. For contributors who send patches with Claude Code, GitHub Copilot CLI or a similar agent, the proposal ends that workflow for QGIS.

## What the proposed QGIS AI policy prohibits

The sources include the pull request thread but not the full policy text. timlinux thanked the author for "a short paragraph like this rather than a long essay". kannes said "the words assisted and used are very broad" and read the policy as also ruling out LLMs for review, auditing and security, for discovering non-obvious context in C++ code, and for simulating a reviewer before a human sees the PR. nyalldawson did not narrow that reading. He said the intention is to "start with a closed door" and later consider cases such as "ai can be used as a replacement for ide autocomplete" or "ai can be used for language translations" one at a time.

> So as noted above, we correct by slamming the door shut, and then choosing later how far we want to inch it open.
>
> - nyalldawson, QGIS-Enhancement-Proposals PR #387

## Why the earlier human-in-the-loop policy failed

uclaros posted figures on how the old process worked. The extractive tag was never created, about 50 PRs were tagged AI Assisted, and about 40 of those were closed without merging. Several more were closed without ever being tagged. nyalldawson replied that the earlier QEP "clearly didn't work", that "the process didn't happen in reality", and that the project had "already lost at least one extremely high value contributor as a result".

One Hacker News commenter summarised the previous rule: from February to 09-24 the policy was "human in the loop", and any tool was fine as long as the contributor read the code and could answer questions about it. The thread does not say how many maintainers review PRs or how long the unreviewed queue is.

haubourg gave reviewer capacity as the reason. He said AI use from external contributors "puts a massive and unbearable pressure on the shoulders of our maintainers", and that the volume is "a lot higher than what human review can take seriously". The result, he said, is either a longer list of unreviewed PRs or "not fully reviewed code and quality issues". He also tied the decision to protecting a human contributor network that organisations rely on for support, training and features.

Amalvir, who had opened two AI-assisted regression-fix PRs, supported the change. They wrote that LLMs give beginners "the illusion" that they can fix bugs in a project this complex, and that this breaks "a trust contract between the reviewer and the contributor". They added that contributors who lean on AI learn little and are unlikely to become reviewers themselves.

## Are issues, comments and security advisories covered?

vpicavet asked whether the rule covers issue content, comments and PRs, and said it should apply to the QEP repository at least. haubourg agreed. He also noted that "100% of the submitted security advisories are written using AI" since the project started using that system, with most of them concerning the QGIS websites rather than QGIS core. The thread does not say how a blanket ban would apply to incoming advisories.

haubourg said LLM use for review, auditing and security is a separate topic, to be discussed at the user conference before any formal proposal. That question is open for now. On the wider objection that useful AI uses would be lost, rouault-on-strike replied that "we are aware we might throw the baby with the bathwater" and that "this QEP is a stop gap measure". They added that the project "might have to wait for the burst of the AI bubble to fully understand what a fair AI use might be".

## How compliance would be judged without a detector

The sources describe no detection tooling, disclosure form or CI check. 02JanDal said it is clear that Claude Code or GitHub Copilot CLI are not allowed, then asked about grey areas. These included LLM-backed autocomplete, ML-ranked completions in JetBrains IDEs, brainstorming a design with ChatGPT, seeing a Google AI answer while searching an error, and using Google Translate for an English term. 02JanDal referred to "the penality", but the thread excerpt does not say what the penalty is.

02JanDal proposed narrower wording: "No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository." They also asked for examples of what is and is not allowed. timlinux replied that "the measure of compliance is 'did you in good conscience write the code yourself'". The excerpt cuts off partway through that comment.

Commenters on Hacker News read the policy as a reference point rather than a verification system. One wrote that "banning does not imply verification". They added that the most egregious cases (big diffs, lengthy descriptions, weird phrasing) can now be rejected quickly by pointing to the policy.

## Where the October 5 vote stands

On October 5, 2026, nyalldawson said the proposal had passed the discussion period and moved it to the Voting label. 3nids asked to keep it open until the end of the week because the contributor meeting was underway. nyalldawson left that decision to timlinux. On October 6, 3nids said he had spoken with Tim, accepted the move to voting, gave a +0 and said he would open another QEP.

elpaso gave a +1 during the voting stage. He noted that the QEP is meant to set "an initial policy" and does not mean AI contributions are banned forever and in every form. haubourg and Amalvir had each posted +1 during discussion on September 24. The sources do not include a final vote count or outcome.

On October 2, four QGIS pull requests referenced the proposal, and all four are shown as closed. They were #67612 ("Fix wrong Natural Breaks (Jenks) classes"), #67630 ("[Postgres] Reconnect NOTIFY listener after connection loss"), #67629 ("Share OGR datasets among layers while reading a project") and #67631 ("Enable parallel provider creation for WFS provider"). The sources do not say whether the policy was why they were closed. A Hacker News commenter cited a follow-up, "QEP 429: Add exception to the AI policy for trusted contributors - #388". That proposal is not in the sources, so its terms cannot be confirmed here.

## What coding-agent users must change to land QGIS patches

One Hacker News commenter said the rule covers only QGIS, the UI application, and not libraries such as GDAL or GEOS. The sources do not confirm the exact scope, and 02JanDal's qgis/qgis wording was a suggestion, not adopted text. Under the policy as proposed and as its author explains it, contributors should plan around the following:

- Do not submit code produced by Claude Code, GitHub Copilot CLI or similar agents. 02JanDal described these as the clear case.
- Treat AI-assisted research, design brainstorming and LLM pre-review as excluded until the project explicitly allows them. nyalldawson said exceptions would be considered case by case.
- Write issue text, comments and PR descriptions yourself. vpicavet asked for them to be covered and haubourg agreed.
- Be prepared to state, in good conscience, that you wrote the code yourself. That is the standard timlinux proposed.
- If a use such as LLM autocomplete or translation matters to your workflow, argue for it in a separate proposal rather than relying on an informal reading. 3nids has already said he will open another QEP.

The sources leave the main operational questions open. They do not say who checks compliance, what happens to a contributor found in breach, or how the project will handle security advisories that haubourg said are all AI-written. Teams contributing to QGIS for clients should treat agent-written patches as unmergeable until the vote result, and any trusted-contributor exception, is published.

## Questions this raises

### What does the proposed QGIS AI policy change?

It replaces the previous human-in-the-loop rule with a strict "NOT ALLOWED" policy for AI-assisted contributions. nyalldawson described it as a correction to the earlier QEP and said the intent is to start with a closed door. Later cases such as AI autocomplete or translations could then be considered one at a time.

### How would QGIS check whether a contribution used AI?

The thread describes no detector, disclosure form or CI check, and no defined penalty. timlinux said the measure of compliance is whether you, in good conscience, wrote the code yourself.

### Why did QGIS maintainers drop the human-in-the-loop policy?

nyalldawson said the earlier QEP clearly didn't work and that the project had already lost at least one high-value contributor. haubourg said the volume of AI-assisted PRs put unbearable pressure on maintainers and exceeded what human review could handle.

## Key facts

- Pull request #387, titled "Add QEP428: No ai contributions permitted", was opened on September 24, 2026 by nyalldawson.
- Under the earlier human-in-the-loop rule, about 50 PRs were tagged AI Assisted and about 40 were closed without merging.
- The proposal moved to the Voting label on October 5, 2026; elpaso, haubourg and Amalvir posted +1 and 3nids gave +0.
- On October 2, 2026, four QGIS PRs (#67612, #67629, #67630, #67631) referenced the proposal and are shown as closed.
- A follow-up, QEP 429 (#388), would add an exception for trusted contributors, but its terms are not confirmed in the sources.

## Sources

1. [QGIS bans AI assisted contributions](https://github.com/qgis/QGIS-Enhancement-Proposals/pull/387) - github.com

Discussion read (practitioners' reactions, not a source): https://news.ycombinator.com/item?id=50054751