<div dir="ltr"><div>Hi everyone,</div><div><br></div><div>I am personally a user of AI-generated code. I find it works exceptionally well for medium-sized libraries, especially in terms of quality of code produced and for writing tests, despite the quantity of code as observed by others. </div><div><br></div><div>Regarding QGIS, I have mixed feelings. It works great for the migration of settings: since it's a repetitive task, I could fine-tune a precise prompt which works well while it still requires some attention to review everything. The challenge was really to give all the tiny details, which in the end translates to the capability of grasping (and writing) the whole complexity.<br>For more complex and isolated tasks, while the explanations from it always sound super convincing, I agree that it's still quite often not relevant if not completely wrong in some parts of it. And it takes a lot of time to detect this because it's well hidden in the complexity.</div><div><br></div><div>(But this statement would have been the same for small librairies a couple of months ago. So, where will we be in a couple of months?)</div><div><br></div><div>From my experience, I think the most important thing is to ensure these two points:</div><div>  - I have reviewed every single line of code.</div><div>  - I fully understand all the code produced.</div><div>In my opinion, checking these two boxes is more important than knowing whether or not AI was used, which is not as black and white either (as already stated, there is a quite wide brand of usage from code completion to full automatic coding). Like cheating/doping in sports, it's a bit subjective.</div><div><br></div><div><div><div>I also share the concerns of not introducing a differentiation between the type of authors to avoid frustration. </div></div><div>So I'd be in favor of introducing the 2 checkboxes above and fine tuning the AI use checkbox (not sure exactly how, but to give a better vision on how it has been used).</div></div><div><br></div><div>Kind regards,<br></div><div><br></div><div>Denis Rouzaud</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 1 avr. 2026 à 09:35, Julien Cabieces via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi,<br>
<br>
Thank you Nyall for raising this topic. I don't have well established<br>
position on this and I don't think there is a good obvious solution<br>
here.<br>
<br>
I'm also deeply concerned about the increased number of AI Pull Requests,<br>
often of poor quality. I have also lost time trying to review some of<br>
these...<br>
<br>
But I don't like having different rules for core developers and non core<br>
developers. We would be allowed to use a (supposedly) powerful tool, but<br>
not new contributors ? I don't like the message that we send to the<br>
community. It doesn't seem very welcoming, and people could rightfully<br>
say that we are gate keeping.<br>
<br>
So, If we don't want people proposing AI Pull Requests, I'd prefer<br>
banning AI Pull Requests at all. Maybe we could allow the chatbot use but not<br>
the code generation? But that's maybe the position of someone who actually<br>
doesn't use code generation... <br>
<br>
In any case, I'd like we stay welcoming and rename the "AI slop" label<br>
and its tooltip to something more neutral ("AI generated", "This PR<br>
contains AI generated code and needs to be thoroughly reviewed" ? ).<br>
<br>
Especially when the contributor has explicitly written that he used AI<br>
and how he used it.<br>
<br>
Regards,<br>
Julien<br>
<br>
<br>
<br>
<br>
<br>
> Hi,<br>
><br>
> I second all the wise words from Even. I am particularly worried by<br>
> the impact it would have on growing our contributor base. QGIS already<br>
> has a problem with welcoming new contributors, and a policy giving<br>
> more special rights to core contributors will only make the situation<br>
> worse. Especially while the rules for core contributors are not really<br>
> well defined. A retired core contributor could launch an agent to<br>
> throw slop PRs at QGIS while a recurrent non-core contributor would<br>
> not even be allowed to review his own code with an LLM ?<br>
><br>
> I also note that the current situation is bad for our community<br>
> atmosphere : the "AI slop" label seems really offensive for newcomers<br>
> if not sustained with explanation and clear rules on expectations. I<br>
> have recently seen contributors feeling bad after their work has been<br>
> marked as slop without any discussion and care.<br>
><br>
> I have already casted my opinion recently, but let me restate it : I personally think we should ban any LLM-generated code entirely from QGIS codebase.<br>
><br>
> Right now the legal risk is really high, and while there is still no<br>
> real legal law case which would indicate that we actually have the<br>
> right to include LLM-generated code as GPL into an OpenSource software<br>
> as QGIS, each week show new signs that this topic is risky ( supreme<br>
> court refusing to handle copyright issue, new laws coming for AI legal<br>
> control in France and Europe, the chardet debacle, new law cases and<br>
> settlements, wikipedia banning AI-aided contributions…).<br>
><br>
> We should keep a look at Debian policy. For now they said it was too early for a position, but I guess as for all risks, when in doubt then no doubt.<br>
><br>
> I would be in favor of having a - at least - temporary ban on AI-generated code for all.<br>
><br>
> Vincent<br>
><br>
><br>
> On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote:<br>
>> Nyall,<br>
>><br>
>> As often with that topic, I'm undecided about the best course of action.<br>
>><br>
>> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider:<br>
>><br>
>> - restricting AI tool use to core contributors will make the process<br>
>> of becoming core contributor harder. Core contributors would be able<br>
>> to improve their capabilities further (questionable claim in terms<br>
>> of quality. But in quantity&speed, definitely), which will make it<br>
>> harder to grow new core contributors. There's a high chance the new<br>
>> generation learning coding today will not be able to produce any<br>
>> working code without such tools (like I'm 100% dependent on Valgrind<br>
>> to write working non-trivial C++ code).<br>
>><br>
>> - besides the issue with new comers to the project, we most<br>
>> certainly have regular experienced contributors who haven't the<br>
>> status of core contributor, probably because nobody thought about<br>
>> proposing them (btw, I've no idea how to determine who is a core<br>
>> contributor and who isn't...  is there a public list somewhere<br>
>> ?). Why would they be discriminated further?<br>
>><br>
>> - I would say that we should restrict your proposal even further:<br>
>> "only core contributors are allowed to use AI tools, only in the<br>
>> areas where they (feel they) are experts  ", possibly relaxed with<br>
>> "or for contributions involving non-production code (e.g. CI scripts<br>
>> (*), etc.)". If I use a AI tool in a part of QGIS I've never<br>
>> touched, there's a high risk I will produce low quality code with<br>
>> it.<br>
>><br>
>> - There's an increased risk that non-core contributors would still<br>
>> use AI tools, but without telling us. Naive ones will be easily<br>
>> caught; smarter ones will go under our detection radar. But is there<br>
>> a difference between good/non-perfect/bad code written with or<br>
>> without AI assistance that still passes CI and human review...? At<br>
>> the PR unitary level, I'd say none. The issue is more the about the<br>
>> increased volume of bad contributions with AI help that can saturate<br>
>> our review bandwidth.<br>
>><br>
>> - Side point: I'm wondering if the nature of the tool would make a<br>
>> difference. I haven't personally used AI tools that can operate on a<br>
>> whole code base (Claude code and the like), only chat tools that can<br>
>> work/produce limited code fragments. I'd suspect the former are the<br>
>> ones where you can vibe code an entire feature, whereas with chatty<br>
>> ones, you need to iterate much more and thus have hopefully more<br>
>> critical eye. On the other hand, maybe tools that operate at the<br>
>> whole code base level can have a better global view... Likely none<br>
>> of those approaches is fundamentally better than the other<br>
>> one. Different drawbacks.<br>
>><br>
>> To me it looks like we are caught in an arm race we haven't decided<br>
>> to be part of but can't easily escape.  So, half joking/half<br>
>> serious, let's use AI tools to detect bad AI output ?!? (ignoring<br>
>> who has used the tool). I suspect that AI companies would love such<br>
>> outcome...  Or maybe, until the AI industry collapses entirely,<br>
>> let's temporarily go back to sending patches on 3.5 inches floppy<br>
>> disks (1.44 MB ones only, not extended 2.88 MB ones)  through (post)<br>
>> mail.<br>
>><br>
>> At the same time I'm writing this, I'm caught in a situation where<br>
>> I'm questioning the need for a GDAL PR whose quality isn't<br>
>> necessarily bad (I haven't done the in-depth analysis), but which is<br>
>> likely not strictly needed (premature optimization/complication),<br>
>> and would have most certainly not be submitted at all if AI didn't<br>
>> exist. From my experience with recent AI assisted PRs to GDAL,<br>
>> that's actually the main problem. Too much code being written in a<br>
>> too short period of time, that will make us totally dependent on AI<br>
>> tools to be able to contribute further.<br>
>><br>
>> So, all in all, not opposed to your proposal, but we need to be careful how we phrase it to not scare away non-core contributors or increase unwanted discrimination.<br>
>><br>
>> Even<br>
>><br>
>> (*) Because I've just played this afternoon with Gemini chat to come<br>
>> up with some python clang AST code to write custom code checkers to<br>
>> verify project specific code rules (like pairing Reference() in<br>
>> constructor and Release() in destructor). The result is<br>
>> .. well... AI typical. Mostly sort of works after a couple<br>
>> iterations, but definitely not something that would be of the<br>
>> quality that clang-tidy or similar serious tools would expect. But<br>
>> good enough for the purpose it was created. Or at least I was<br>
>> tricked into believing it was good enough...<br>
>><br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
-- <br>
<br>
Julien Cabieces<br>
Senior Developer at Oslandia<br>
<a href="mailto:julien.cabieces@oslandia.com" target="_blank">julien.cabieces@oslandia.com</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>