Correction, October 12, 2026: An earlier version called the change “QEP #387” and said the ban covered documentation. #387 is the GitHub pull-request number. The PR title identifies the change as “Add QEP428,” and the PR edits the existing
qep-408-ai-tool-policy.mdfile. The adopted sentence prohibits LLM-, AI-, or agent-assisted code contributions to theqgis/qgisrepository; it does not explicitly name documentation. The original URL is unchanged; the headline, scope and citations are corrected here.
QGIS has changed its written policy on AI-assisted contributions, but the identifiers and scope are easy to misstate. The key distinction is this: GitHub PR #387 is not QEP #387, and the adopted policy sentence addresses code contributions to one named repository, not every use of AI or every QGIS project.
In brief: PR #387, titled “Add QEP428: No ai contributions permitted,” was merged on October 7, 2026. It replaced the earlier human-in-the-loop wording in the existing QEP 408 policy file with a prohibition on AI-assisted code contributions in
qgis/qgis. The operative sentence does not explicitly mention documentation.
What exactly does QGIS’s adopted policy prohibit?
The current text says: “No LLM, AI or agent assisted code contributions are allowed in the https://github.com/qgis/qgis repository.” It adds that if the project later discovers AI, LLM or agent use for a contribution, the contributor may face “code reversion and contributor rights sanctioning.” Those are the policy’s own words, not a broader interpretation from a news headline.
The scope matters. The sentence names code contributions to the qgis/qgis repository. It does not say that using AI tools in general is forbidden, that AI features in the QGIS application are banned, or that every repository connected with QGIS has the same rule. The wording should not be expanded beyond what the policy states. The current policy text and the pull request that changed it are the primary sources.
QEP 428, QEP 408 and PR #387: why are there three numbers?
Some coverage referred to “QEP #387.” That confuses the proposal label with the GitHub pull-request number. The official PR is number 387 and its title is “Add QEP428: No ai contributions permitted.” The file it changes is still named qep-408-ai-tool-policy.md.
The numbers describe different parts of the history. QEP 408 is the existing AI policy document, whose earlier text allowed a human-in-the-loop approach. PR #387 is the specific GitHub change. QEP 428 is the new proposal label used in that PR’s title. The PR diff shows that it did not add a separate file called qep-428; it replaced the contents of the existing QEP 408 file with version 2.0. This is why the article distinguishes the PR number from the QEP labels instead of repeating the shorthand used by secondary coverage. The PR metadata and file diff make the relationship checkable.
What did the earlier policy say?
The previous version of QEP 408 allowed contributors to use tools, provided a human read and reviewed generated code or text before asking others to review the contribution. It also encouraged contributors to disclose substantial tool-generated content, for example in a pull-request description or commit message.
That older text listed several kinds of interaction with the project, including code, QEPs and design proposals, issues, security vulnerabilities, and comments. It also gave an explicit example: using an LLM to draft documentation that a contributor then manually checks, edits and submits was an approved use. Those details were removed in the change made by PR #387. The comparison explains why the change is described as a move away from “human in the loop,” but it does not prove that the new policy explicitly bans every kind of documentation work. The official diff shows both versions.
Why did the project tighten the policy?
Participants in the PR discussion described pressure from AI-assisted submissions: haubourg wrote that they put pressure on maintainers and that the flow could exceed what human reviewers could handle. Tim Sutton separately supported establishing a clear policy through the QEP process and argued against putting its rationale in the policy text. These are contributions by individual participants, not a complete account of every QGIS maintainer’s view. The comment by haubourg on PR #387 and the QGIS-Developer thread document these two distinct points.
In a PR review comment, participant uclaros gave an approximate count: about 50 pull requests had been tagged “AI Assisted,” and about 40 were closed without merging. The comment also says other pull requests were closed without being tagged. This is a participant’s estimate in the discussion, not a statistical report published by QGIS, so it should be described as an approximation rather than a complete measurement. See the comment in PR #387.
How was the change approved?
PR #387 was opened on September 24, 2026. On October 5, its author said the discussion period had ended and that it was moving to a vote. On October 7, Nyall Dawson recorded the proposal as approved, and the pull request was merged later that day. These dates come from the pull request’s own history.
The discussion also shows that contributors disagreed about the boundaries of the rule. Questions covered AI agents, autocomplete, translation, asking a model for advice, and written interactions. In a comment, the author described the intent as starting with a restrictive position and considering specific exceptions through separate discussions. That statement does not mean any exception has already been adopted. The PR timeline and comments provide the record.
Does the new ban cover documentation?
It would be inaccurate to say that the adopted sentence explicitly bans documentation. Its operative wording refers to “code contributions” in qgis/qgis; it does not separately name documentation, translations or written issue reports. The earlier version did name documentation and gave a manually reviewed LLM-drafted document as an allowed example.
During the PR discussion, one participant suggested adding documentation, bug reports, PR descriptions, comments and other written interactions to the ban. A suggestion in the discussion is not proof that the final text adopted it. The careful reading is that the adopted clause prohibits AI-assisted code contributions in qgis/qgis, while its wording does not expressly settle whether documentation-only changes or other forms of contribution are included. Do not present an unmentioned expansion as settled policy. Read the merged policy wording, rather than relying on a secondary headline.
Is this a technical block on AI use?
The document states a rule of conduct; it does not describe an automated detector for identifying model-written code. In the PR thread, a participant described the compliance question as whether the contributor had, in good conscience, written the code themselves. That is a discussion comment, not a technical control added to the policy.
The distinction is practical: the policy defines what the project will not accept, but it does not specify a tool that can reliably determine the origin of every change. The text anticipates that AI use might be discovered later and states consequences including code reversion and contributor-rights sanctions. It would be unsupported to claim that the repository automatically scans every contribution or can detect all AI assistance.
What should contributors take from the change?
Anyone planning to contribute to qgis/qgis should read the exact policy text and current project guidance. Neither “QGIS bans AI everywhere” nor “human review makes every use acceptable” is a safe summary. The adopted sentence focuses on AI-assisted code contributions, while comments in the PR show that participants raised unresolved edge cases.
It is also important to separate formal wording from discussion. A comment about possible future exceptions is not an exception in force today. A suggestion to include documentation is not part of the adopted sentence. Approximate counts in a review comment are not a comprehensive project report. If a case involves translation, autocomplete, advice from a model, or work outside qgis/qgis, consult current QGIS guidance or ask maintainers rather than guessing at the boundary.
Frequently asked questions
Did QGIS ban every use of AI?
That does not follow from the adopted sentence. It addresses LLM-, AI- or agent-assisted code contributions to the qgis/qgis repository, not every use of AI in the QGIS application or ecosystem.
Does the policy explicitly ban AI-assisted documentation?
No. The operative sentence names code contributions and does not separately mention documentation. The earlier QEP 408 text contained an example allowing manually reviewed AI-assisted documentation.
Which number is correct: 408, 428 or 387?
The GitHub pull request is #387. Its title calls the change “QEP428.” The PR updates the existing qep-408-ai-tool-policy.md file, whose earlier version described the human-in-the-loop policy. These are distinct identifiers.
When was the change approved?
The history of PR #387 records approval and merge on October 7, 2026. That date is the merge date, not a date inferred from later media coverage.
Summary
- GitHub PR #387 is titled “Add QEP428: No ai contributions permitted” and was merged on October 7, 2026.
- The PR replaced the earlier human-in-the-loop text in
qep-408-ai-tool-policy.md. - The adopted sentence prohibits AI-assisted code contributions to the
qgis/qgisrepository. - Documentation is not explicitly named in that sentence, so it should not be described as expressly banned.
- The estimate of about 50 tagged pull requests and about 40 closed comes from a participant’s PR comment, not a complete project audit.