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

Wed Apr 1 04:30:56 PDT 2026

Hi all,

I'm happy that this discussion arises in such a constructive way

## Regarding the "AI slop" Github label, I had a look at the marked PR 
and issues.

We clearly have students and beginners launching 7 PR in a fex days. 
This is AI slop.

But we also have some long time contributors like Marcu that use AI as a 
way to try to get into core contribution, with full disclosure and 
explicitly mentioning mentoring with core devs in local hackfest.

I have hard time finding out who is behind a PR, sometimes from long 
time contributors and friends, so I would propose that we encourage 
contributors to use clear usernames

To sum up this triaging topic, I'd be in favor of :

- a neutral "AI generated"  label

- a second "PR Slop !! " label reserved to tag bad behavior only

- Incentives over the community to introduce itself and take care that 
reviewers can easily identify the PR/Issue author to a real person. The 
authors must understand we can't make an investigation on each 
discussion to identify contributors, and they may badly be tagged  as 
"Slop" involuntarily.

## On the AI use ban

For reference, I found this repo starting to lists the projects that 
stated antiAI policies : https://github.com/thatshubham/no-ai  Libreoffice

You probably saw Copilot inserting ads into PR's where asked for review 
last week. As always in open source, if we accept AI reviews, we 
probably should take care of preserving our independence and our 
capacity to move away from GH/Microsoft ecosystem that locks us in. So 
whatever we choose, let's keep in mind our independence and capacity to 
migrate somewhere else.

You also saw the dramatic 90 % service continuity from Github. AI in 
highly complex environments is a danger.  This seconds the idea that we 
can't let vibe code do massive changes to the core, from core 
contributor or not.

I would also add to our policy that no direct contribution to the repo 
is accepted from an AI agent. Which is inlined with the "human in the 
loop" policy. I wouldn't like to see Github copilot's or Claude avatar 
in the lists of the contributors.

So I have no hard point of view here. But if I understand well current 
jurisprudence, we are fully responsible of IP infringement in our code 
base, whatever the tool we use. I would suggest we back our backs by 
setting up scanners in our CI and IDE to catch potential dependencies or 
source code infringements.   SCANOSS pretends to be able to catch 
snippets level licence infringement at least.
  I know they are weak tools. But maybe they could be a proof of good 
will for the future to defend us?

Lastly, Collabora  proposes an alternative way that could work.
https://www.collaboraonline.com/blog/tdf-ejects-its-core-developers/
Let's get rid of humans. Happy 1st April all :)

Cheers

Bien cordialement,
Régis Haubourg

On 01/04/2026 11:02, Alessandro Pasotti via QGIS-Developer wrote:
> Hi,
>
> I am currently using Copilot as an autocompleter/copy-paster on
> steroids, I find it useful to generate repetitive tasks (like handling
> the different cases of a switch statement) and for writing test cases
> but I've never tried to generate a full class or a full method.
>
> Knowing its limitations I think it speeds up my work but I have to
> carefully review every single line because sometimes it "hallucinates"
> badly.
>
> I don't feel that we have an IP issue for this kind of usage: the
> generated code it too trivial and too limited in the amount to be
> considered an infringement and also I noticed that 99% of the times it
> basically copy-pastes code from the other parts of QGIS or GDAL and
> many times it's code I've written myself.
>
> Regarding the policy in QGIS I also believe that the main goal is to
> reduce the SNR (signal-noise-ratio) in the PRs, given the limited time
> the reviewers have.
>
> I think a total ban is not enforceable and probably not useful at all,
> also I don't feel right that only core developers could use these
> tools.
>
> I second Denis' idea that the important thing is that the contributor
> checks that:
> - I have reviewed every single line of code.
> - I fully understand all the code produced.
>
> I would probably summarize that in the rule "do not submit anything
> that I could not have written myself without any AI tool", not sure
> how this could be enforced though but I think that if someone is
> caught cheating the current policy should cover the case.
>
> Cheers
>
> Alessandro Pasotti
>
>
>
> On Wed, Apr 1, 2026 at 10:37 AM Denis Rouzaud via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>> Hi everyone,
>>
>> 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.
>>
>> 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.
>> 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.
>>
>> (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?)
>>
>>  From my experience, I think the most important thing is to ensure these two points:
>> - I have reviewed every single line of code.
>> - I fully understand all the code produced.
>> 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.
>>
>> I also share the concerns of not introducing a differentiation between the type of authors to avoid frustration.
>> 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).
>>
>> Kind regards,
>>
>> Denis Rouzaud
>>
>>
>> Le mer. 1 avr. 2026 à 09:35, Julien Cabieces via QGIS-Developer <qgis-developer at lists.osgeo.org> a écrit :
>>>
>>> Hi,
>>>
>>> Thank you Nyall for raising this topic. I don't have well established
>>> position on this and I don't think there is a good obvious solution
>>> here.
>>>
>>> I'm also deeply concerned about the increased number of AI Pull Requests,
>>> often of poor quality. I have also lost time trying to review some of
>>> these...
>>>
>>> But I don't like having different rules for core developers and non core
>>> developers. We would be allowed to use a (supposedly) powerful tool, but
>>> not new contributors ? I don't like the message that we send to the
>>> community. It doesn't seem very welcoming, and people could rightfully
>>> say that we are gate keeping.
>>>
>>> So, If we don't want people proposing AI Pull Requests, I'd prefer
>>> banning AI Pull Requests at all. Maybe we could allow the chatbot use but not
>>> the code generation? But that's maybe the position of someone who actually
>>> doesn't use code generation...
>>>
>>> In any case, I'd like we stay welcoming and rename the "AI slop" label
>>> and its tooltip to something more neutral ("AI generated", "This PR
>>> contains AI generated code and needs to be thoroughly reviewed" ? ).
>>>
>>> Especially when the contributor has explicitly written that he used AI
>>> and how he used it.
>>>
>>> Regards,
>>> Julien
>>>
>>>
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I second all the wise words from Even. I am particularly worried by
>>>> the impact it would have on growing our contributor base. QGIS already
>>>> has a problem with welcoming new contributors, and a policy giving
>>>> more special rights to core contributors will only make the situation
>>>> worse. Especially while the rules for core contributors are not really
>>>> well defined. A retired core contributor could launch an agent to
>>>> throw slop PRs at QGIS while a recurrent non-core contributor would
>>>> not even be allowed to review his own code with an LLM ?
>>>>
>>>> I also note that the current situation is bad for our community
>>>> atmosphere : the "AI slop" label seems really offensive for newcomers
>>>> if not sustained with explanation and clear rules on expectations. I
>>>> have recently seen contributors feeling bad after their work has been
>>>> marked as slop without any discussion and care.
>>>>
>>>> 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.
>>>>
>>>> Right now the legal risk is really high, and while there is still no
>>>> real legal law case which would indicate that we actually have the
>>>> right to include LLM-generated code as GPL into an OpenSource software
>>>> as QGIS, each week show new signs that this topic is risky ( supreme
>>>> court refusing to handle copyright issue, new laws coming for AI legal
>>>> control in France and Europe, the chardet debacle, new law cases and
>>>> settlements, wikipedia banning AI-aided contributions…).
>>>>
>>>> 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.
>>>>
>>>> I would be in favor of having a - at least - temporary ban on AI-generated code for all.
>>>>
>>>> Vincent
>>>>
>>>>
>>>> On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote:
>>>>> Nyall,
>>>>>
>>>>> As often with that topic, I'm undecided about the best course of action.
>>>>>
>>>>> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider:
>>>>>
>>>>> - restricting AI tool use to core contributors will make the process
>>>>> of becoming core contributor harder. Core contributors would be able
>>>>> to improve their capabilities further (questionable claim in terms
>>>>> of quality. But in quantity&speed, definitely), which will make it
>>>>> harder to grow new core contributors. There's a high chance the new
>>>>> generation learning coding today will not be able to produce any
>>>>> working code without such tools (like I'm 100% dependent on Valgrind
>>>>> to write working non-trivial C++ code).
>>>>>
>>>>> - besides the issue with new comers to the project, we most
>>>>> certainly have regular experienced contributors who haven't the
>>>>> status of core contributor, probably because nobody thought about
>>>>> proposing them (btw, I've no idea how to determine who is a core
>>>>> contributor and who isn't...  is there a public list somewhere
>>>>> ?). Why would they be discriminated further?
>>>>>
>>>>> - I would say that we should restrict your proposal even further:
>>>>> "only core contributors are allowed to use AI tools, only in the
>>>>> areas where they (feel they) are experts  ", possibly relaxed with
>>>>> "or for contributions involving non-production code (e.g. CI scripts
>>>>> (*), etc.)". If I use a AI tool in a part of QGIS I've never
>>>>> touched, there's a high risk I will produce low quality code with
>>>>> it.
>>>>>
>>>>> - There's an increased risk that non-core contributors would still
>>>>> use AI tools, but without telling us. Naive ones will be easily
>>>>> caught; smarter ones will go under our detection radar. But is there
>>>>> a difference between good/non-perfect/bad code written with or
>>>>> without AI assistance that still passes CI and human review...? At
>>>>> the PR unitary level, I'd say none. The issue is more the about the
>>>>> increased volume of bad contributions with AI help that can saturate
>>>>> our review bandwidth.
>>>>>
>>>>> - Side point: I'm wondering if the nature of the tool would make a
>>>>> difference. I haven't personally used AI tools that can operate on a
>>>>> whole code base (Claude code and the like), only chat tools that can
>>>>> work/produce limited code fragments. I'd suspect the former are the
>>>>> ones where you can vibe code an entire feature, whereas with chatty
>>>>> ones, you need to iterate much more and thus have hopefully more
>>>>> critical eye. On the other hand, maybe tools that operate at the
>>>>> whole code base level can have a better global view... Likely none
>>>>> of those approaches is fundamentally better than the other
>>>>> one. Different drawbacks.
>>>>>
>>>>> To me it looks like we are caught in an arm race we haven't decided
>>>>> to be part of but can't easily escape.  So, half joking/half
>>>>> serious, let's use AI tools to detect bad AI output ?!? (ignoring
>>>>> who has used the tool). I suspect that AI companies would love such
>>>>> outcome...  Or maybe, until the AI industry collapses entirely,
>>>>> let's temporarily go back to sending patches on 3.5 inches floppy
>>>>> disks (1.44 MB ones only, not extended 2.88 MB ones)  through (post)
>>>>> mail.
>>>>>
>>>>> At the same time I'm writing this, I'm caught in a situation where
>>>>> I'm questioning the need for a GDAL PR whose quality isn't
>>>>> necessarily bad (I haven't done the in-depth analysis), but which is
>>>>> likely not strictly needed (premature optimization/complication),
>>>>> and would have most certainly not be submitted at all if AI didn't
>>>>> exist. From my experience with recent AI assisted PRs to GDAL,
>>>>> that's actually the main problem. Too much code being written in a
>>>>> too short period of time, that will make us totally dependent on AI
>>>>> tools to be able to contribute further.
>>>>>
>>>>> 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.
>>>>>
>>>>> Even
>>>>>
>>>>> (*) Because I've just played this afternoon with Gemini chat to come
>>>>> up with some python clang AST code to write custom code checkers to
>>>>> verify project specific code rules (like pairing Reference() in
>>>>> constructor and Release() in destructor). The result is
>>>>> .. well... AI typical. Mostly sort of works after a couple
>>>>> iterations, but definitely not something that would be of the
>>>>> quality that clang-tidy or similar serious tools would expect. But
>>>>> good enough for the purpose it was created. Or at least I was
>>>>> tricked into believing it was good enough...
>>>>>
>>>> _______________________________________________
>>>> 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
>>> --
>>>
>>> Julien Cabieces
>>> Senior Developer at Oslandia
>>> julien.cabieces at oslandia.com
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
>
>