A patch is a request for another person's attention, not merely a piece of code. Someone must reconstruct the problem, assess side effects and support the result after merging. QGIS's decision to prohibit AI-assisted code contributions makes that review relationship the central issue for developers using agents on open-source projects.
The adopted policy, approved on October 7, 2026 according to the source reporting, applies to code contributions in the main QGIS repository. It warns of reversion and contributor sanctions if prohibited assistance is discovered later. The text should not be expanded into an invented ban across every QGIS issue, translation or documentation channel.
Disclosure cannot override an exclusion
QGIS previously tried allowing labeled AI involvement with human responsibility. Participants said that approach failed to protect maintainer time. One discussion estimate described about 50 labeled pull requests and roughly 40 closed without merging; those figures were not a formal audit. They explain the discussion without establishing a measured failure rate for AI code generally.
Under the adopted boundary, labeling an agent-written patch does not make it eligible. A contributor who accepts personal responsibility also cannot unilaterally waive the project's rule. Before generating a proposed upstream change, read the current repository policy and make sure the intended workflow qualifies.
Count the reasoning the reviewer must supply
Passing tests is valuable but incomplete. A change can miss data-format assumptions, performance constraints or interactions with other providers. The QGIS project overview describes a broad geospatial ecosystem, where apparently local edits can affect many workflows.
The author must be able to explain the mechanism, reproduce the problem, defend the test and respond to new evidence. If a reviewer must rebuild all that reasoning, a polished patch transfers rather than removes work. High submission volume can then outpace the community's ability to develop new maintainers.
Compare policies without mixing them
The Linux coding-assistant guidelines permit disclosed assistance under human review and certification. An agent does not take the human sign-off responsibility. QEMU's provenance policy rejects generated contributions while distinguishing certain supporting activities. These are different project choices, not interchangeable permissions.
QGIS's short restriction leaves debated edges around research, private review and autocomplete. Contributors should not assume an exception simply because another repository allows it. At the same time, authorship suspicion based only on polished style is weak evidence. Clear explanations and proportionate enforcement matter when sanctions are possible.
Build contribution around durable ownership
Organizations relying on QGIS should assign someone who understands the affected subsystem, can maintain the change and can work within the repository's rules. Funding experienced contributors or developing internal expertise may do more for acceptance than generating more candidate patches.
For maintainers, useful policy evidence includes review backlog, time spent, accepted-change quality and whether newcomers become continuing contributors. A smaller submission count alone does not prove success. For developers, the immediate obligation is simpler: respect the local boundary, submit work you can explain and remain available for its consequences. AI capability does not create a right to volunteer review, and a contribution process succeeds only when it sustains the people who decide what ships.
