QGIS Bans AI-Assisted Contributions: What QEP 428 Says and Why

The QGIS project has banned AI contributions. On October 7, 2026, maintainers of the free, open-source geographic information system declared QEP 428, "No AI contributions permitted" approved, replacing a policy that had allowed AI-assisted work with a human reviewing the output. The change is one more data point in a pattern we have tracked all year: open-source projects drowning in machine-written pull requests are choosing bright-line rules over nuanced ones. See our coverage of the COSMIC desktop ban, the OpenJDK policy and the GCC rule on legally significant LLM code.

This post covers what the QGIS proposal says, the timeline, the maintainers' stated reasons, the questions it leaves open, and what developers argued about when the story reached Hacker News.

Quick reference: the QGIS AI ban at a glance

One caveat on sourcing: the pull request page we could read shows the discussion, labels and votes, but not a rendered diff of the final policy wording. Where this post describes the operative rules, it relies on the proposal title, the maintainers' comments and the June mailing-list thread. Read the merged file itself before quoting exact clauses.

What is QGIS, and why does its policy matter?

QGIS is a free GIS application for creating, analysing, storing and visualising geospatial data. As one Hacker News reader put it when the thread started, if you had never heard of it, think maps, including 3D ones. It is community-run, widely used by public agencies and consultancies, and extended by a large plugin ecosystem.

That adoption is the context for the policy. In the discussion, contributor haubourg argued that organisations trust QGIS because they know they can contribute back, hire contributors for support, training and features, and that this human network is something the project wants to protect. A tool that thousands of organisations depend on has a different risk profile from a hobby repo: a bad merge ships to many users.

Timeline: from mailing-list proposal to ban

Maintainer guiding many contributions through review, illustrating the QGIS AI policy debate

The sequence, from the proposal thread and the QGIS developer list:

• June 2026: On the qgis-developer list, Nyall Dawson raised "Tightening AI submission policy?". He described the existing policy as permissive and based on a human in the loop, pointed to recent conflict in the PostGIS community, and suggested something closer to GDAL's rules. He also suggested pairing GDAL's rules with Godot's "contribute only what you understand" clause.
• September 24: The pull request for QEP 428 was opened with the labels Policy and In Discussion.
• October 5: It moved to the voting stage.
• October 6: Maintainer 3nids, after talking with timlinux, agreed to proceed to a vote while voting a neutral +0.
• October 7: The proposal was declared approved on votes from rouault-on-strike, alexbruy, signedav and elpaso, then labeled Accepted and merged.
• Afterwards: Further +1 votes, including from vpicavet and gacarrillor.

The opening post collected 24 thumbs-up and 2 thumbs-down reactions, which is a rough proxy for the community mood.

Why QGIS did it: four reasons from the discussion

1. Review capacity

The most concrete argument is about maintainers' time. As haubourg described it, AI-generated contributions exceed what human review can absorb. A pull request is cheap to generate and expensive to review, and the asymmetry only grows.

2. The old policy was not working

Per contributor uclaros, a planned "extractive" tag was never created, around 50 pull requests were tagged "AI Assisted", and roughly 40 of them were closed without merging. A policy that asks reviewers to judge, case by case, how much AI was involved moves the cost onto the same overloaded people. A ban is easier to apply because the question becomes "did you write this?", not "how much help did you get?". Contributor timlinux made that point: compliance rests on whether the contributor wrote the code themselves.

3. Trust in the contributor network

As above, the project frames its human community as an asset worth protecting, not only a source of patches.

4. Skills pipeline

Contributor Amalvir argued that people who lean on AI may not understand their own changes or develop the skills that turn newcomers into reviewers, shrinking the pool of future maintainers. We looked at the evidence on this elsewhere: AI assistance and persistence and the idea of cognitive debt from LLM-written code both bear on it, though neither is specific to QGIS.

What the policy leaves unresolved

Gate of square tiles with one highlighted tile, a metaphor for scope questions in the QGIS AI ban

A bright-line rule is easier to enforce than a graded one, but this one raised scope questions that the discussion recorded:

• What counts as a contribution? vpicavet and adamjstewart asked whether the rule covers issues, comments, pull request descriptions, documentation and the enhancement proposals repo itself.
• What about review and exploration? Contributor kannes worried a blanket ban would also catch legitimate uses such as LLM-assisted code review, code exploration and auditing.
• Where is the line on tooling? 02JanDal listed IDE autocomplete, machine-learning-ranked completions, translation tools and AI answers from search engines, and suggested narrowing the wording to code "written by LLM or AI-agents".
• Enforcement. Nothing in the discussion we could read describes detection. Compliance is a matter of contributor honesty, which is the same enforcement model as most open-source licence and provenance rules.

The author's answer was that this is a first, restrictive step. Per his comments, and echoed by elpaso and timlinux, exceptions can be added through case-by-case QEPs. A sibling proposal, QEP 429, was opened to add an exception for trusted contributors; as of this writing we have not seen its outcome, so treat it as pending.

What developers are saying

The story reached Hacker News with about 65 points and 49 comments, and the reaction split along familiar lines. These are commenters' reports and opinions, not verified facts.

• User coffeeaddict1 asked what "AI assisted" even means, describing a workflow where they build several AI prototypes but hand-write the final code with no autocomplete. That is exactly the scope gap above.
• User rfgplk argued the maintainers feel threatened and asked how anyone would prove code was AI-generated, then pointed at the sibling trusted-contributor proposal as evidence that maintainers themselves may use LLMs. That is the commenter's interpretation, not a statement from the project.
• User KolmogorovComp suggested open contributions may be ending because maintainers are overloaded and contributors rarely beat what a maintainer could do with an LLM and their own review.
• User leothetechguy welcomed the change as improving long-term code quality, and wondered why HN usually leans pro-AI.
• User mpalczewski said they had skipped contributing to projects that ban AI, on the view that you can always fork.
• User sammy2255 asked what happens to people who quietly include AI-assisted commits.
• User WarmWash, a hobbyist mapper, said LLM-written scripts for point-cloud work reduced their own need for QGIS, a reminder that users and contributors are different audiences.

The full thread is on Hacker News.

How QGIS compares with other open-source AI policies

Shield with a small eye representing trust and policy for AI contributions in QGIS

Projects have settled in different places on a spectrum:

The related problem on the reporting side is visible too: Google froze part of its open-source bug bounty over low-quality machine-written reports (details). Different surface, same economics: generation is free, verification is not.

What this means if you contribute to or maintain open source

If you contribute: read the project's AI policy before you open a pull request, not after. Rules now differ sharply by project, and a closed PR is a wasted afternoon. If you use AI for private exploration or prototyping, check whether the rule covers it; QGIS's own thread shows that is unsettled. When in doubt, ask in the project's channel and write the final code yourself.

If you maintain: the QGIS experience suggests that a graded policy (tag it, disclose it) can fail when nobody has time to enforce the tags. A clear rule, with a stated path to relax it, is cheaper. Decide up front what counts as in scope: code only, or issues and descriptions too.

If you build AI coding tools: the demand-side signal is clear. Agents that open pull requests need to respect per-repo contribution policies, and teams are already building guardrails for that; see our look at AI-assisted pull requests and agent safety. If you run agents that touch repositories, a runtime control layer such as AgentBeam, from the explainx.ai team, is built to stop agents before they take dangerous actions.

If you use QGIS: nothing changes in the application today. The policy governs how code enters the project, not what users can do with the software, including writing their own AI-assisted PyQGIS scripts.

What to watch next

Three things will show whether the ban holds. First, whether follow-up QEPs such as the trusted-contributor exception (QEP 429) are accepted, which would turn the ban into a gated allowance. Second, how maintainers handle suspected violations without reliable detection. Third, whether other geospatial projects, especially those that share contributors with QGIS such as GDAL and PostGIS, move in the same direction.

For the bigger picture, our policy timeline tracks where regulation stands, but open-source contribution rules are being written project by project, by maintainers, not legislators.

Sources

• QGIS-Enhancement-Proposals pull request 387 (QEP 428)
• qgis-developer mailing list: "Tightening AI submission policy?" (June 2026)
• Hacker News discussion

Related reading

• COSMIC bans AI-generated code
• OpenJDK bans AI-generated code
• GCC AI contributions policy
• Codeberg bans vibe-coded projects
• Google OSS bug bounty freeze over AI slop
• Cognitive debt and LLM-written code

Details reflect the sources as of October 12, 2026. Policies and proposal status can change; check the linked repository for the current text.