QGIS enacts moratorium on AI contributions

QGIS, the open-source mapping platform that powers everything from city planning departments to disaster response teams, just enacted a moratorium on AI-generated contributions. If you’ve been using Copilot or ChatGPT to help write that QGIS plugin, your pull request is getting rejected before it even hits the review queue. It’s a blunt move that shouldn’t be controversial, but here we are.

I’ve spent the last year watching open-source maintainers drown in AI-generated code that looks convincing but falls apart under scrutiny. The volume is staggering, and the quality control is nonexistent. QGIS isn’t the first project to face this problem, but they’re one of the first major ones to draw such a clear line, formally categorizing AI output separately from human work rather than pretending they’re the same thing.

What’s interesting is that this isn’t just about rejecting bad code. QGIS is navigating a legal minefield around copyright and liability that most projects are still ignoring. They’re essentially saying: we don’t know who owns this, and we don’t want to find out in court. But that leaves us with an uncomfortable question. If we ban AI contributions now to protect maintainers, what happens when the tools become genuinely indistinguishable from human work? And who gets to decide where that line sits?

Technical Overview

The gap between generating code and understanding a system shows up immediately when you try to clone something with AI. You can prompt an LLM to reconstruct a project's file structure in minutes, but you're left with orphaned logic, hardcoded values that made sense in context, and architectural decisions that look arbitrary without the history. That's why the commit message matters more than the diff. When someone says "read the updated commit for the full message," they're pointing at the only place where the original author explains why the code is shaped this way instead of that way. The AI doesn't know. It only knows patterns.

Cloning from scratch with AI means accepting a trade-off: speed for context. You get a working skeleton fast, but you lose the accumulated debugging sessions and the dead ends. This is genuinely confusing because the generated code often looks cleaner than the original. It compiles. It passes basic tests. But it's missing the scar tissue: those weird workarounds that exist because of a production incident you don't know about.

Before you let the AI loose on a repo, inspect what you're actually cloning:

git log --follow --patch -- path/to/critical/file.py

git show --no-patch --format=fuller <commit-hash>

The output tells you things the code can't. You'll see messages like "temporary fix until we figure out the race condition" or "reverting this because it breaks IE11." That context changes how you should approach the clone. If you're using AI to regenerate the project, feed it those commit messages as part of the prompt. Otherwise you're asking it to guess at intent, and it will guess confidently and incorrectly.

Industry Impact

I think treating AI releases like framework releases — mapping them onto the adoption curves of React or Kubernetes — is both a useful crutch and a potentially dangerous simplification. On one hand, it gives engineering teams a vocabulary for what they're actually looking at when a new model or agent framework drops. The hype cycle becomes legible: you can point to "the plugin ecosystem phase" or "the enterprise integration slog" and know roughly what comes next based on how Docker or Terraform played out. That predictability matters when you're trying to convince a CFO that this isn't just another crypto winter waiting to happen.

But I'm skeptical that AI follows those precedents cleanly. Framework releases improved incrementally on established patterns; AI releases keep rewriting the underlying substrate. When we categorize them the same way, we risk calibrating expectations to a timeline that doesn't exist — assuming that "production-ready" is eighteen months away because that's how it worked with container orchestration, when the actual bottleneck might be something we haven't named yet, like evaluation infrastructure or data governance at scale. The categorization helps with procurement and planning, but it might obscure the parts of AI adoption that don't fit the framework mold.

What this really signals is a shift in how the industry talks about AI: from "breakthrough" to "infrastructure." That's healthy for adoption, but it also means we're about to see the same boring, necessary work that follows every framework release — migration tooling, security audits, vendor lock-in debates. I don't think we're heading toward a plateau; I think we're heading toward a very long, unglamorous implementation phase where the winners aren't the ones with the best models, but the ones with the best integration stories. The question worth sitting with is whether that integration phase will look like the last twenty years of enterprise software, or whether AI's non-determinism will force us to invent a different kind of reliability altogether.

Conclusion

QGIS didn't just tighten its AI policy—it reversed course entirely. QEP428, merged as PR #387 by Nyall Dawson, replaces Even Rouault's earlier QEP-408, which had adapted LLVM's human-in-the-loop framework to allow AI-assisted contributions with mandatory review. Now there's no loop, no oversight clause, just a flat prohibition. That's a hard reversal from a project that, until recently, seemed willing to meet AI halfway.

I'm still not sure how they plan to enforce this. The old policy at least acknowledged that AI tools were already in contributors' workflows; the new one seems to assume they can be detected or deterred, which strikes me as optimistic. You can ban AI-generated code in theory, but proving a pull request is human-written rather than AI-assisted is nearly impossible without invasive scrutiny of contributors.

Watch what happens to the developers who were using AI tools under QEP-408. They don't disappear—they either learn to hide it better or they leave. And if QGIS, with its institutional weight, decides the risk isn't worth it, expect other open source projects to copy this move before long.