One of the world's most popular open-source GIS applications has decided that AI-assisted contributions are not welcome at all, in any form, and the merged policy document is shorter than most pull request templates. QGIS enhancement proposal QEP428, titled "No ai contributions permitted," was merged on October 7, 2026, and it formally replaces the project's previous "human in the loop" AI policy with a strict NOT ALLOWED policy. When it hit the Hacker News front page it collected hundreds of points and hundreds of comments in a few hours, most of them arguing about whether a volunteer community can even enforce a rule like this.
The arguments about enforcement are fair. But they miss the two most interesting documents in the whole story: a confession from a contributor whose own AI-assisted pull requests pushed the project over the edge, and a follow-up proposal that would require every new contributor to prove they are a living human being before their first commit is accepted.
Full disclosure: I have never contributed to QGIS, and I use AI coding agents daily, which probably makes me exactly the kind of contributor this policy is aimed at. Everything below comes from the merged QEP, the QGIS developer mailing list, and the discussion threads. Where I am giving an opinion rather than a sourced fact, I say so.
What the policy actually says
The merged QEP is deliberately blunt. The old policy asked contributors to keep a human in the loop over AI-generated content. The new one does not ask anything. The discussion that led to it gives the reasoning in three points from one of the project's core contributors:
- The review burden is unbearable. AI use from external contributors puts what the discussion calls a massive and unbearable pressure on maintainers, who already had a tough job before the LLM era.
- The volume exceeds human review capacity. The stream of AI-assisted submissions is higher than what human reviewers can take seriously, so the project faces a choice between a growing pile of unreviewed pull requests and reviews that are not really reviews. Both options degrade quality.
- Free software runs on human networks. Organizations trust and fund QGIS because they know they can contribute back, hire contributors for support and training, and influence features. That economic and social loop only works if actual humans stay in it.
The comment section will tell you the policy is unenforceable, and the project itself agrees. In the mailing list discussion that preceded the QEP, Tim Sutton, a member of the QGIS Project Steering Committee, drafted the operative language himself: "No LLM assisted code contributions are allowed" in the repository, and, in his own words, "We know this is difficult to enforce, but if we subsequently discover that you have used an LLM for your contribution, you risk code reversion and contributor rights sanctioning." The same discussion proposes wiring the policy into a contributor license agreement workflow, so every pull request carries an explicit attestation.
That is the same enforcement model OpenJDK chose earlier this year: you cannot detect AI text reliably, so you make contributors affirm compliance and carry the liability themselves. The policy works on the honor system and backs the honor system with consequences.
The confession
Here is the part of the merge discussion that deserves more attention than any policy debate. A contributor named Amalvir commented during the QEP discussion, and the comment is a plus-one for the ban, from the person it directly affects:
"I am directly concerned by this new policy, and it's also a +1 for me. When I created my 2 AI-assisted regressions-fix PRs to investigate the cause of the bugs, suggest fixes, and review the code, I didn't realize the harm this could cause to QGIS's already fragile reviewer community. I'm clearly not yet skilled enough to fix bugs in a project as complex as QGIS, but LLMs give you the illusion that it's possible."
Read that again, because it compresses the entire AI-contribution debate into four sentences. A motivated developer found bugs, wanted to help, used the tools available, produced two plausible-looking fix pull requests, and then realized that what felt like contribution was closer to load-shedding onto volunteers. The model made a hard problem feel solved. The reviewer still had to do the actual work of verifying whether it was.
This is the failure mode the gentle policies never accounted for. A "human in the loop" rule assumes the human is supervising the AI. It does nothing about the human who cannot independently judge whether the AI's output is correct, which in a codebase as complex as QGIS is most humans, including well-meaning ones. The illusion of competence is not a discipline problem you can policy your way around with guidelines. Hence the flat ban.
There is an uncomfortable mirror here for those of us who work with these tools professionally. The difference between my AI-assisted work and the pull requests in that confession is not that the model got smarter about QGIS. It is that I can usually tell when the output is wrong, because I already know the system it is changing. In an unfamiliar codebase, that safety net is gone, and the confession shows what is left.
The "proof of life" proposal
The ban was only half of what Nyall Dawson, the QEP's author and one of QGIS's most prolific contributors, originally proposed. The other half is stranger, and it has not been adopted yet.
In the mailing list thread from late September, he proposed requiring a "proof of life" from all new contributors before their first contribution is accepted in any form. One suggestion was a small financial contribution to the project, deliberately tiny, just enough to deter what he called karma farmers who do not care about the project. Any amount, he argued, would be sufficient to block the bots. The alternative floated was more radical: a face-to-face meeting with an existing contributor before a newcomer can submit changes.
The pushback was immediate and reasonable. One respondent pointed out that contributing to QGIS already requires thousands of dollars of hardware and often follows years of education, so the project already has inequality barriers, and adding a payment gate makes another one. They shared their own memory of starting out: a clean build of QGIS once took an entire night on their old laptop.
Nothing in the merged QEP includes proof of life. It remains an idea in circulation, which is itself worth noticing. An established open-source project, one of the pillars of the FOSS GIS world, is seriously discussing whether anonymous first commits from unverified humans are still sustainable. Whatever you think of the specific proposals, the direction of travel is clear: the era of walk-in anonymity in major volunteer projects is ending, and AI floods are the reason.
The pattern, and how QGIS breaks it
I went through OpenJDK's AI policy in detail a week ago, so the shape of the QGIS decision looked familiar and then, on the second look, did not. Lining the projects up shows something interesting:
- OpenJDK (Oracle): AI-generated content is banned in part or in full, across code, bug reports, wiki pages, and email. Reading, debugging, and reviewing with AI is explicitly fine. The stated reasons are reviewer burden, safety, and, decisively, intellectual property: the contributor agreement requires you to grant rights you may not legally hold in AI output.
- GraalVM (also Oracle): The opposite rule, under the same contributor agreement. AI assistants may draft, transform, and review code, tests, and documentation, with accountability as the bar: if you cannot explain and defend the change in review, it gets rejected.
- QGIS (volunteer community): The flattest ban of the three, with the narrowest justification. No IP argument appears anywhere in the discussion. The entire case is reviewer attention and community health.
That third row is the signal. Oracle's ban, whatever else it was, had a corporate legal logic underneath it. QGIS has no legal motive at all. Its contributors signed no assignment agreement that AI output would contaminate. The community looked at its own review queue and its own burnout level and concluded that AI-assisted volume, even good-faith AI-assisted volume, costs more than it delivers. It is a pure labor economics decision, made by the people doing the labor.
One Hacker News commenter put the underlying shift well: the bottleneck is no longer writing code but staying aligned with it, knowing what it does and whether it does what you meant, and for maintainers reviewing large pull requests from strangers that problem is much worse. Another reached for Peter Naur's old essay "Programming as Theory Building," the argument that a program is valuable mainly as a theory in the minds of the people who understand it. AI-assisted contributions accelerate the artifact and do nothing for the theory. A volunteer project is mostly theory, held by a handful of tired people. QGIS is protecting the theory.
If you want one prediction out of this: watch whether other volunteer-run projects adopt similar bans over the next six months, and notice which ones. Corporate-backed projects with paid maintainers will keep tolerating, or embracing, AI contributions. The projects running on donated evenings will keep closing the door. The divide will not be about beliefs about AI. It will be about who pays for review.
What I would actually do if you contribute to open source
Whether or not any project you touch has a formal policy yet, the QGIS story suggests a working set of rules for AI-assisted open-source contribution in 2026:
- Read the contributing guide before the first line of code. Policies are moving fast this year. OpenJDK's interim policy landed in April, QGIS QEP428 merged in October, and both flipped previous norms. The rule you remember from 2024 may be the opposite of the rule on the page today.
- Default to read-only AI in unfamiliar codebases. Using an LLM to understand, navigate, and debug a large project is the use case even the strictest policies explicitly allow. It also happens to be where these tools do their best work.
- Never submit a fix you cannot explain line by line. This is the GraalVM accountability bar, and it is the right bar everywhere. If you cannot defend the change in review without the model's help, the change is not ready, no matter how green the tests are.
- Do not file AI-drafted issues. Both OpenJDK and QGIS treat non-code content as in scope. A maintainers-eye view: a well-written issue is a gift of attention, a plausible-sounding AI issue is a withdrawal from the same account.
- Disclose, even where it is legal. Some projects still allow AI-assisted code. Saying "this change was drafted with an AI assistant and reviewed by me, here is my reasoning" costs nothing and buys trust. The Amalvir confession is what honesty looks like after the fact; disclosure is what it looks like before.
And if you are on the other side of the table, a maintainer watching your queue fill up: QGIS's sequence is a usable template. Gentle policy first, then measure, then a hard rule with teeth, written short enough that nobody can claim they did not understand it.
The takeaway
QGIS did not ban AI because AI code is bad. Some of it is fine. It banned AI because a volunteer project's scarcest resource is not code, it is the attention of the few people willing and able to review code, and AI turned a trickle of contributions into a flood that no review process can absorb honestly. The confession in the merge discussion is the whole story in miniature: tools that create the feeling of contribution without the capacity for responsibility behind it.
The question every open-source project will answer one way or another over the next year is not "is AI code good?" It is "who reviews it, and did they agree to?" QGIS just answered loudly.
I write about AI tools, developer workflows, and the open-source world every week. Subscribe, it's free.
Have you submitted an AI-assisted contribution to an open-source project this year? Did the maintainers know? The comments are open.
Top comments (0)