Checking an AI-generated patch yourself no longer makes it eligible for QGIS's main repository. The mapping project's new contribution policy bans AI-assisted code, closing the route through which a contributor could previously review a model's output before asking maintainers to accept it.
Nyall Dawson declared the proposal approved and merged it on October 7. Approval changes what developers may submit, even when they believe they understand the resulting code.
QGIS is free software for creating maps, editing geographic data and running spatial analysis on Windows, macOS and Linux. It is licensed under GPLv2 or later and owned by its contributors. Its community development model lets users help shape the software they depend on, so rules about who does the work affect more than the contents of a release.
What the ban actually covers
The adopted text names code contributions to the main QGIS repository. It prohibits assistance from LLMs, AI and agents, and says discovery of such use can lead to code reversion and sanctions on contributor rights. It gives no exemption for a patch whose author has manually checked the generated output.
That wording makes tool disclosure insufficient for an AI-assisted code submission. It also leaves practical details unspecified: the policy doesn't define a detection method or spell out the sanctions. Its explicit repository scope gives no basis for declaring a blanket ban on every independently maintained QGIS plugin or on users' private workflows.
Before the vote, Tim Sutton's September 23 mailing-list message acknowledged that enforcement would be difficult. He proposed clear rules in the contribution documentation and handling them through the project's established policy process. A contributor agreement was one suggestion in that email. The suggestion should not be confused with a requirement enacted by the short policy.
The distinction between writing code and receiving other assistance was contested. In the proposal discussion, a participant posting as 02JanDal asked about autocomplete, design brainstorming and translation. Sutton answered in terms of whether the contributor had written the code themselves. Those comments don't constitute a published list of exceptions.
The earlier rules already counted review costs
The removed policy, visible in the change diff, required contributors to read generated code or text, take responsibility for it and answer questions during review. Substantial generated content was supposed to be labelled. New contributors were advised to begin with small changes they could understand.
It also prohibited agents from acting in project spaces without human approval, while allowing some reviewed uses. Generated documentation that a person checked and edited was an example. The old text explicitly treated maintainers' time as a cost: a contribution needed to bring enough benefit to justify reviewing it.
The earlier document also warned that acceptance of LLM-created code remained unsettled. Its human-review requirements governed interactions with the project. They shouldn't be read retrospectively as an unconditional promise to merge generated code that passed a contributor's checks.
That policy left reviewers judging individual submissions. The diff removes those instructions and replaces them with a prohibition. QGIS has changed the default before the reviewer starts assessing a patch's merits.
In the proposal discussion, contributor uclaros reported roughly 50 pull requests tagged as AI assisted, about 40 of them closed without merging. Those are a participant's approximate counts, rather than a systematic audit. Dawson said the previous process hadn't worked and that the project had already lost a highly valued contributor.
Why maintainers wanted to change the default
Dawson's initial mailing-list proposal, posted in September, described hurt and disappointment within the developer community. He wanted an immediate moratorium, followed by discussion of which uses might be acceptable. His argument was that gentler policies hadn't helped enough to justify keeping the existing arrangement while that debate continued.
The same email separated that moratorium from another proposal: requiring new contributors to demonstrate that they were real people. Dawson floated a small donation or an in-person meeting. Those ideas were proposals for discussion, not provisions of the approved AI code ban.
In a follow-up reply, Dawson explained that he wanted people seeking permission to use AI to make the case for allowing it. David Koňařík had asked what specifically was causing the community harm and whether restrictions on unfamiliar contributors would suffice. Dawson's answer changed who would have to justify a departure from the default.
This exchange helps explain the policy's structure. Dawson's stated approach would let maintainers stop debating every possible use while supporters developed narrower proposals. It does not supply a measurement of how much review time the ban will save.
Protecting reviewers without pricing out newcomers
Célia Buira's September 19 response raised a different cost: barriers to joining the project. She objected to requiring a financial contribution and recalled a clean QGIS build taking an entire night on her laptop when she started contributing. Her alternative was a screencast showing the result and the build's commit.
Buira also urged caution about removing tools that might prove useful, and discussed allowing LLM use after a contributor had built a track record. Her message shows that protecting maintainers and keeping contribution accessible were both questions inside the project. Neither donations nor a track-record exemption appears in the adopted code policy.
Sutton's steering committee perspective was to clear obstacles from developers' work, including an AI ban if needed. He wanted neutral policy language rather than derisive wording in contribution instructions. That matters for a newcomer trying to follow the rules: a prohibition can be direct without making the contributor the target of a public argument.
A passing test suite still needs a reviewer
QGIS's code submission and merge rules require appropriate unit tests, with extensive testing for changes to the core, analysis and server modules, subject to stated exceptions. Pull requests must pass existing continuous integration checks and receive approval from a core contributor with repository write permission.
The submission policy says anyone may propose a change without special status. Developers generally cannot approve their own submissions, with narrow exceptions for specified circumstances. Access to the review queue and permission to merge are separate steps, so a contributor's confidence never supplied the final approval.
Those merge rules also require unresolved change requests to be addressed. Ordinarily a pull request must stay open for at least 24 hours, even after approval, to allow wider feedback across time zones. Backports, emergencies and trivial fixes have exceptions. The review process already accounts for work that automated checks can't finish.
The developer guide explains why QGIS develops features in branches before merging them: as the codebase grew, side effects became harder to anticipate, and restoring stability had contributed to long release cycles. That is an existing software maintenance problem which reviewers still have to consider when a patch appears to solve the reported bug.
For someone preparing a contribution, the developer guide offers a practical route: announce a proposed feature, check whether another developer is working on it, and use an enhancement proposal when architecture changes are involved. It asks authors to follow their pull requests through review and respond to questions. That obligation continues after writing the patch.
The guide also says repository write access normally follows substantial patches demonstrating competence and understanding of QGIS conventions. This is why a project's contribution process has a second job alongside accepting code: it helps establish who can later review somebody else's work. The stated path to write access still requires evidence of that understanding.
QGIS has described the ban as an initial position that could later be narrowed. The next thing to watch is a concrete proposal for an exception, with a defined use and a review burden maintainers are willing to accept. Until such a change is approved, developers preparing code for the main repository have the current prohibition to work with.