QGIS Bans AI Contributions Entirely: A Contributor's Confession

QGIS, one of the world's most popular open-source GIS applications, has officially decided to stop accepting AI-assisted contributions in any form. The proposal, known as QEP428, was merged on October 7, 2026. In a policy document shorter than most PR templates, it replaced the previous mild "human-in-the-loop" stance with a single clear rule: AI contributions are banned, period.

The news quickly climbed Hacker News, accumulating hundreds of points and hundreds of comments. The debate largely converged on one question: can a volunteer community actually enforce a rule like this?

The skepticism about enforcement is reasonable. But what really deserves close reading are two other documents from this whole affair — a contributor's confession, and a follow-up proposal requiring new contributors to prove they are human.

What the Policy Actually Says

The merged QEP is blunt. The old policy required contributors to maintain "human-in-the-loop" oversight of AI-generated content. The new policy drops even that requirement. The core contributor driving the change gave three reasons in the discussion:

The review burden has become unbearable. AI use from outside contributors places "enormous and unsustainable pressure" on maintainers, and this work was already hard enough before the LLM era.

Submission volume exceeds human review capacity. The flood of AI-assisted submissions exceeds what human reviewers can seriously process. The project is forced to choose between "a mountain of unreviewed PRs" and "review in name only" — both paths damage quality.

Free software depends on human networks. Organizations trust and fund QGIS because they know they can give back to the community, hire contributors for support and training, and influence feature direction. This economic and social loop only works when real people are involved.

The comment section will tell you this policy can't be enforced — and the project itself admits as much. In the mailing list discussion before the QEP, QGIS Project Steering Committee member Tim Sutton personally drafted the enforcement clauses: "LLM-assisted code contributions" are "not allowed" in the repository, and, in his own words, "we know this is hard to enforce, but if we subsequently find out you used an LLM, you risk having your code reverted and contributor rights sanctioned." The same discussion proposed wiring the policy into the contributor license agreement process, so every PR carries an explicit declaration.

This is exactly the enforcement model OpenJDK chose earlier this year: since you can't reliably detect AI text, make contributors self-certify compliance and bear the corresponding responsibility. The policy rests on an honor system — one backed by consequences.

The Confession

The most notable moment in the merge discussion wasn't any policy debate — it was a comment from a contributor named Amalvir. The comment came from someone directly affected by the policy, yet it was a +1 in favor of the ban:

"I am directly affected by this new policy, but I also vote +1. When I created those two AI-assisted regression-fix PRs to investigate the bug cause, suggest a fix, and review the code, I didn't realize what harm this would do to QGIS's already fragile reviewer community. I clearly don't yet have the ability to fix bugs in a project as complex as QGIS, but LLMs give you the illusion that it's possible."

This passage deserves to be read several times, because in four sentences it compresses the entire AI contribution debate. A motivated developer found a bug, wanted to help, used the tools at hand, produced two plausible-looking fix PRs — and then realized that this behavior, which looks like contributing, is closer to dumping the burden onto volunteers. The model made a hard problem seem solved, while reviewers still had to do the real work of verifying whether it actually was.

This is precisely the failure mode the mild policy never accounted for. The "human-in-the-loop" rule assumed the human was supervising the AI. It had no answer for the other case: the human cannot independently judge whether the AI output is correct. In a codebase as complex as QGIS, that covers most people — including well-intentioned contributors. The illusion of competence isn't a discipline problem and can't be avoided with guidelines. That's where the blanket ban comes from.

For those of us who work with these tools professionally, there's an uncomfortable mirror here. The difference between my AI-assisted work and the PRs in that confession isn't that the model got smarter about QGIS — it's that I can usually tell when output is wrong, because I already understand the system it's changing. In an unfamiliar codebase, that safety net doesn't exist, and the confession shows what remains.

Peter Naur's "Theory Building": In his 1985 paper "Programming as Theory Building," computer scientist Peter Naur argued that the value of a program lies not primarily in the source code itself, but in the mental theory developers build in their heads about how the program works and why it was designed that way. When a team loses the people who hold this theory, the program dies in spirit — even if the code still runs. AI-assisted contributions can rapidly generate plausible-looking code artifacts, but they cannot participate in building this theory — and may accelerate its dilution. For volunteer projects, the theory often lives only in the minds of a few long-term maintainers. This is the deeper reason QGIS is so wary of AI contributions: it doesn't just consume review resources, it can leave the project without anyone who truly understands it.

The "Proof of Humanity" Proposal

The ban was only half of QEP author Nyall Dawson's original proposal. The other half is stranger, and hasn't been adopted yet.

In the late-September mailing list discussion, he proposed requiring all new contributors to provide "proof of humanity" before their first contribution is accepted. One suggestion was a small financial contribution to the project — deliberately tiny, just enough to block what he called "karma farmers who don't care about the project." He figured any amount would deter bots. Another, more radical alternative: newcomers would need an in-person meeting with an existing contributor before submitting changes.

Objections came immediately, and for good reason. One respondent pointed out that contributing to QGIS already requires thousands of dollars in hardware, plus usually years of education. The project already has unequal barriers; adding a paywall would just create another one. He shared his own memory of getting started: a full build of QGIS on an old laptop once took him an entire night.

The merged QEP does not include "proof of humanity." It remains an idea in circulation — which is itself notable. A mature open-source project, one of the pillars of the FOSS GIS world, is seriously discussing whether anonymous first-time submissions can still be sustained. Regardless of how you feel about the specific proposals, the direction is clear: the era of "casual anonymous entry" for large volunteer projects is ending, and the AI flood is the reason.

Patterns and How QGIS Breaks Them

Line up the AI policies of various projects and something interesting emerges:

• OpenJDK (Oracle): Partial or full bans on AI-generated content, covering code, bug reports, wiki pages, and mailing lists. But explicitly permits using AI to read, debug, and review. The reasons include review burden, security, and a decisive intellectual property issue — the contributor agreement requires you to grant rights to AI output you may not legally hold.
• GraalVM (also Oracle): Under the same contributor agreement, the opposite rule. AI assistants may draft, transform, and review code, tests, and documentation, with accountability as the threshold: if you can't explain and defend the change during review, it gets rejected.
• QGIS (volunteer community): The most sweeping ban of the three, with the narrowest rationale. The IP argument never appears in the discussion at all — the entire rationale is reviewer attention and community health.

The third row is the signal. Oracle's ban has corporate legal logic behind it. QGIS has no legal motive — contributors don't sign a rights assignment that could be contaminated by AI output. The community simply looked at its review queue and its burnout levels and concluded that the volume of submissions AI assistance produces, even when well-intentioned, costs more than it's worth. This is a pure labor-economics decision, made by the people doing the labor.

One Hacker News commenter described the underlying shift well: the bottleneck is no longer writing code, but staying aligned with code — knowing what it does and whether it does what you want. For maintainers reviewing large PRs from strangers, this problem is even more severe. Another quoted Peter Naur's old paper "Programming as Theory Building," whose argument is that a program's value lies primarily in the "theory" in the minds of the people who understand it. AI-assisted contributions accelerate artifacts while contributing nothing to the theory. Volunteer projects are mostly theory, held by a few exhausted people. QGIS is protecting the theory.

If I had to make a prediction: watch over the next six months to see whether other volunteer-run projects adopt similar bans, and which ones. Corporate-backed projects with paid maintainers will continue to tolerate or even embrace AI contributions, while donation-funded, spare-time projects will keep closing the door. The divide isn't about belief in AI — it's about who pays for review.

Contributor License Agreements (CLAs) and the AI Copyright Dilemma: Corporate projects like OpenJDK require contributors to sign legal agreements assigning copyright of their contributions to the project. But the copyright status of much AI-generated code is unclear — training data may include copyrighted code, and whether the output can be legally licensed by the contributor is disputed. So Oracle-family projects often restrict AI contributions on IP grounds to avoid downstream legal risk. QGIS has no CLA; contributors license code directly under an open-source license, and the community focuses more on reviewer labor burden and community health than on legal compliance. This difference explains why similar technological phenomena lead to radically different policies in projects with different governance structures.

If You Contribute to Open Source, Here's What to Actually Do

Whether or not the project you're working with has a formal policy, the QGIS story offers a workable set of rules:

Read the contribution guidelines before writing a single line of code. Policies have changed fast this year — OpenJDK's interim policy landed in April, QGIS QEP428 merged in October, and both overturned prior norms. The rules you remember from 2024 may be the exact opposite of what's on the page today.

Default to read-only AI use in unfamiliar codebases. Using LLMs to understand, navigate, and debug large projects is explicitly permitted even by the strictest policies. It's also exactly where these tools perform best.

Never submit a fix you can't explain line by line. This is GraalVM's accountability threshold, and it's the standard everywhere should adopt. If you can't defend the change during review without the model's help, it's not ready — no matter how green the tests are.

Don't submit AI-drafted issues. OpenJDK and QGIS both include non-code content in scope. From a maintainer's perspective: a well-written issue is a gift of attention; a plausibly-sounding AI issue is a withdrawal from the same account.

Disclose even when it's legal. Some projects still allow AI-assisted code. Saying "this change was drafted by an AI assistant, reviewed by me, and here's my reasoning" costs nothing and buys trust. Amalvir's confession is what honesty looks like after the fact; disclosure is what it looks like beforehand.

If you're on the other side of the table — a maintainer watching the queue fill up: QGIS's sequence is a usable template. Start with a mild policy, measure, then a hard rule with teeth, written short enough that no one can claim they misunderstood.

Conclusion

QGIS didn't ban AI because AI code is bad — some of it is quite good. It banned AI because the scarcest resource in volunteer projects isn't code — it's the attention of the few people both willing and able to review it. AI turned a trickle into a flood that no review process can honestly absorb. The confession in the merge discussion is the whole story in miniature: the tool creates the feeling of contributing, without the capacity to bear responsibility behind it.

The question every open-source project will answer in some way over the coming year isn't "is AI code good?" but "who reviews it, and did they agree to?" QGIS just answered loudly.

Background Notes

"Human-in-the-Loop" in Open Source Projects: In AI contribution policy, this term refers specifically to a mild governance strategy: AI tools may be used to generate content, but human contributors are required to supervise, verify, and take responsibility for the output. QGIS's old policy was based on this, but it carried a key hidden assumption — that humans are capable of judging whether AI output is correct. In a GIS codebase as complex as QGIS, most outside contributors lack this capability, so "oversight" becomes a formality, and the review burden is quietly shifted onto core maintainers. This failure mode pushed QGIS toward a blanket ban, and it reminds us: the effectiveness of human-in-the-loop depends on whether the human truly understands the domain they're supervising.

One-line Summary

QGIS bans AI contributions entirely to protect volunteer reviewers' attention and community health.

Paragraph Summary

QGIS merged QEP428 in 2026, banning all AI-assisted contributions, citing review burden and community health. Proponents noted that AI submission volume exceeds human review capacity, and that volunteer projects depend on an economic and social loop of real human participation. The policy is enforced through an honor system, requiring contributors to declare compliance in the contributor license agreement. One contributor's confession reveals the core problem: LLMs create the illusion of capability in people who lack it, shifting the verification burden onto volunteers. An unadopted "proof of humanity" proposal shows that large volunteer projects are seriously considering ending anonymous first-time submissions. The article predicts the divide isn't about belief in AI, but about who pays for review: corporate projects with paid maintainers will tolerate AI, while volunteer projects will keep tightening policies.