[QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers?

[Even Rouault]

Nyall,

Actually, I deeply sympathize with your position after having received 3 
Claude-generated GDAL PRs today (haven't time yet to read the 3rd one). 
Human maintainers aren't just able to cope with that. It is so 
disturbing and nerve-breaking to read code that looks plausible, but 
you've that instinct it must be somehow wrong and you have to figure out 
how and where exactly. And it's sometimes damn painful to figure that. 
It is not like 100% human code was immune to be wrong, but the failure 
modes are different. Interestingly, I observe those tools are actually 
"good" at adding "working" hacks in already too much hacky/complicated 
code. Whereas a human reaction would have been "what a mess!" and would 
have started by refactoring it. So if you aren't careful enough, you may 
end up in a code base that only machines can maintain (likely that's the 
whole plot). Maybe that's the future of our "industry" (after all, we 
rarely look at assembly code nowadays....) ?

I'd wish that we could go back to times where that stuff didn't exist. 
Maybe time to open that bar at Foo pass 
(https://en.wikipedia.org/wiki/Foo_Pass) that we discussed with Matthias 
around a beer in Vienna a couple years ago. Orders will be registered on 
punch cards. In vino veritas! (l'abus d'alcool est dangereux pour la 
santé, et tout ça - soft beverages also available on request)

Nothing constructive to propose of course. Shear ranting :-)

Even

Le 01/04/2026 à 01:24, Nyall Dawson via QGIS-Developer a écrit :
> Hi list,
>
> I'd like to float an idea for discussion: that we explicitly block all 
> AI based contributions from non-core developers.
>
> As background, currently we have the "human in the loop" policy in 
> place regarding AI contributions (see 
> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md 
> ). This policy was already locked in, with the feeling that it was a 
> good first step that we could later refine and build upon.
>
> I've been giving this a lot of thought, and I personally now think 
> that we need to further tighten our AI policy. To be clear upfront, I 
> am not approaching this from societal or environmental 
> perspectives, but rather from my own direct experience with using and 
> testing these tools. In my direct experience, regardless of the tool 
> used (including Claude, gemini, etc), the results are NOT reliable in 
> all situations. There's still massive amounts of hallucinations, 
> missteps, convoluted and unstable code generated.
>
> Yes, in the *right hands* these tools can be a time saver. But to do 
> this safely you *have* to have a thorough understanding of the code 
> you're working on. And that doesn't mean just understanding the small 
> piece of the code that you're feeding into the tool, but rather a wide 
> understanding of the WHOLE codebase and architecture.
>
> QGIS isn't some little toy hobby project that's appropriate for people 
> to learn open-source, git, vibe coding, or to build their personal 
> portfolio from. It's a *professional tool* which is used for real 
> world applications, and those applications potentially impact projects 
> with million $$ budgets, or with potential risk to human life and 
> safety. That's not hyperbole -- it's exactly what GIS is for!
>
> So, as a practical way to protect the QGIS application and its users, 
> I think we could refine our AI policy to be "contributions using AI 
> tools for development are banned for all non-core contributors".
>
> By wording things this way, we don't explicitly prevent AI driven 
> development from all contributors. Rather we limit it to the subset of 
> contributors who we've formally recognised as having an extensive 
> understanding of QGIS code, architectural design and development 
> practices. These contributors are those who *do* have the skills 
> required to critically analyse the output of LLMs and guide them when 
> the results they give are unsuitable.
>
> I fully admit that this isn't a perfect policy. But I can't think of 
> any other practical way to differentiate AI developed contributions 
> which HAVE been critically assessed vs someone just slopping together 
> a fix for their immediate needs. It would be a ridiculously huge 
> burden and responsibility on the overworked review team to expect them 
> to do this at review time 😱.
>
> Soo.... before I try to propose it as a formal revision to QEP 408, 
> what's everyones thoughts on this? Does anyone have any alternative 
> policy ideas to propose?
>
> Nyall
>
>
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
http://www.spatialys.com
My software is free, but my time generally not.