QGIS bans AI assisted contributions

Hi, maybe this strong take deserves a bit of context of why we want to go further than the previous "Human in the loop" policy

• AI use from external contributors puts a massive and unbearable pressure on the shoulders of our maintainers, who already had a though job before the era of LLM's
• AI stream is a lot higher than what human review can take seriously, leading to either a longer list of un-reviewed PR's or not fully reviewed code and quality issues. Both thing we don't want in the project.
• Free software communities are build on human network . QGIS is trusted by organisations because they know they can contribute back, they can hire contributors for support, training and feature. As a community project, this is something we really want to protect, and keep having enough bandwith to be welcoming to human contributions.

So, for this reason, a huge +1 for me.
Thanks a lot for opening the QEP, given the pressure context you are in @nyalldawson , much appreciated.

I'd like to open another topic about the usage of LLM for review, auditing and security purposes, but I think this is a very separate thread, and we'll open discussions at the user conference before any formal discussions. Things are moving so fast, let's first tackle this QEP.

Thank you @nyalldawson - hopefully having a short paragraph like this rather than a long essay cut out any confusion!

Does that include any contribution to issue content, comments, PRs ?

Also, we should also include the QEP repository at least.

Hi,
I am directly concerned by this new policy, and it’s also a +1 for me.

When I created my 2 AI-assisted regressions-fix PRs to investigate the cause of the bugs, suggest fixes, and review the code, I didn’t realize the harm this could cause to QGIS’s already fragile reviewer community.

I’m clearly not yet skilled enough to fix bugs in a project as complex as QGIS, but LLMs give you the illusion that it’s possible. A few tokens later, and the bug is fixed. By doing this, we’ve broken a trust contract between the reviewer and the contributor. The contract that, to contribute at such a big project, you know what you're doing.

I guess there’s a second effect but I didn't read much online: by making this kind of ease available, contributors using AI learn very little/nothing and don’t build up their skills on the project. They can never really hope to become reviewers themselves, and the community stagnates.

This is the point of view of a passionate open-source user but beginner developer, trying to find my place in today’s world, where AI doesn’t really make things easier. Let's learn to walk before running.

Does that include any contribution to issue content, comments, PRs ?

I would agree with this, though 100% of the submitted security advisories are written using AI since we started with this system. ( most concern our websites, not QGIS core though)

Please do not misunderstand my criticism below. I consider the current craziness around "AI" to be a huge problem in many ways, ethical, societal, economical etc. And I see the huge and unfair pressure that its abuse creates on maintainers and developers. I wish it all had never happened but here we are.

I want to highlight some technical benefits though, which this policy would disallow, at least as I understand it. I am deliberately ignoring everything else here.

I could also absolutely understand if it was more of a "political" move to ban something considered unethical. But is that the intention? Is it to reduce pressure on developers? Or to make a strong statement against "AI"? In any case, I think it could more clear and probably be stronger.

As it is written now, I would understand the policy to not allow usage of LLM for review, auditing and security purposes either. The words assisted and used are very broad and I am afraid that they might throw out the baby with the bathwater (if the baby is AI usage that yields things that are functionally and logically fit for integration in QGIS, that are human-reviewed and that do not create more after-merge-maintenance-hassle than those 100% sourced from human brains).

As someone who sometimes feels brave enough to make tiny steps into the C++ world of QGIS core, I have found LLMs to be useful for discovering additional, non-obvious context in the code. They are often wrong, but it is my strong belief that the results can be used by humans to gain further understanding of code and actually help creating better contributions.

I also sometimes find LLMs useful to get a simulation of a reviewer. Throw your code at it for review, get some listicle back, discard some of it garbage or unrelated, look at the rest, maybe find an actual issue, fix it, then go to your co-workers with a slightly less bad PR. A "Clippy" in your IDE, that gives some - sometimes useful - feedback or criticism on your development, can also help reduce errors and improve robustness. Like a web search will yield false information alongside true information, a LLM will do the same. It is up to the human to critically verify whatever they output.

Such uses would be disallowed by my understanding of this policy.

The words assisted and used are very broad and I am afraid that they might throw out the baby with the bathwater

yes, we are aware we might throw the baby with the bathwater, but the baby might be non-viable, so...
This QEP is a stop gap measure. Two years ago the world was just fine without AI sucked less than today, so there's no reason to allow it without fully understanding the consequences. We might have to wait for the burst of the AI bubble to fully understand what a fair AI use might be.

@kannes

The intention is not that this becomes the "written in stone, forever" policy. It's rather a "lets start with a closed door, which we can then selectively open a little if/when it's safe and proper discussion has been made on that".

So we start by being ultra-restrictive, and then, later, someone (else) argues for cases like "ai can be used as a replacement for ide autocomplete" / "ai can be used for language translations" / etc , all to be considered on a singular case-by-case basis.

@uclaros

It's intended as a correction to the earlier QEP. That clearly didn't work (as you've pointed out, the process didn't happen in reality, and we've already lost at least one extremely high value contributor as a result).

So as noted above, we correct by slamming the door shut, and then choosing later how far we want to inch it open.

This has now passed the discussion period and has moved to the voting stage

would it be possible to keep it open by the end of the week. Reasons for this

• the contributor meeting is happening now
• I personnally wanted to reply (I know I'm late)

would it be possible to keep it open by the end of the week. Reasons for this

I'll let @timlinux make that call.

@nyalldawson I had a discussion with Tim this morning. I'm ok with moving forward to voting and will open another QEP to raise another discussion.

Its +0 for me

Please keep in mind that this QEP is meant to establish an initial policy, it doesn't mean that AI contributions will be banned forever and in any form.

+1

Sorry for also being late...

I have a big worry with this policy; it's not particulary clear what's actually prohibited. Using Claude Code/Github Copilot CLI/etc.? Sure, that's clear that it's not allowed. But what about LLM-backed autocomplete? What about non-LLM AI (for example, Jetbrains-based IDEs have long used ML models to rank auto-completion results)? Using ChatGPT to brainstorm a design? Searching for an error message and unintentionally seeing the answer in Googles AI answer? Asking Claude for a help with an issue in some PyQGIS, realizing it's actually a QGIS Core bug and going on to fix that manually? What if I can't think of the a term in English and use Google Translate to translate from my native language and subsequently use that in code?

I realize that there's a fear that giving even a little bit of leway here will result in the problem persisting, but I think it's very important that the policy is very clear, especially considering the penality.

To offer a suggestion:

No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository.

(removes the very broad "AI" term which makes e.g. Jetbrains ranking model questionable, and explicitly spells out "written" so that e.g. searching/brainstorming/etc. is allowed)

Preferably the policy would also contain informative examples of what is/isn't allowed.

Sorry for also being late...

I have a big worry with this policy; it's not particulary clear what's actually prohibited. Using Claude Code/Github Copilot CLI/etc.? Sure, that's clear that it's not allowed. But what about LLM-backed autocomplete? What about non-LLM AI (for example, Jetbrains-based IDEs have long used ML models to rank auto-completion results)? Using ChatGPT to brainstorm a design? Searching for an error message and unintentionally seeing the answer in Googles AI answer? Asking Claude for a help with an issue in some PyQGIS, realizing it's actually a QGIS Core bug and going on to fix that manually? What if I can't think of the a term in English and use Google Translate to translate from my native language and subsequently use that in code?

I realize that there's a fear that giving even a little bit of leway here will result in the problem persisting, but I think it's very important that the policy is very clear, especially considering the penality.

To offer a suggestion:

No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository.

(removes the very broad "AI" term which makes e.g. Jetbrains ranking model questionable, and explicitly spells out "written" so that e.g. searching/brainstorming/etc. is allowed)

Preferably the policy would also contain informative examples of what is/isn't allowed.

I think the measure of compliance is "did you in good conscience write the code yourself" - we are not set up to peer into your computer and look at what you did. You will know if your brain made the code you want to share or someone else's brain did.

@nyalldawson and others watching this QEP - as @3nids mentioned we had some discussions about this here at UC2026 - lets go ahead with the vote as scheduled. We will surely have some new QEP's looking to crack that door open once / if this goes through....but let's tackle one use case at a time so that we can all stay in the same boat and keep it rowing in the same direction.

No code contributions written by LLM or AI-agents are allowed in the https://github.com/qgis/qgis repository.

I would highly recommend including documentation, bug reports, discussions, PR descriptions, comments, and basically all written interactions on GitHub. These are often even more verbose and extractive than the code itself.

As I wrote already in the mailing list. I believe a moratorium to get time until we have a good solution for every human being won't hurt.

So +1

I think the measure of compliance is "did you in good conscience write the code yourself" - we are not set up to peer into your computer and look at what you did. You will know if your brain made the code you want to share or someone else's brain did.,

@timlinux Yes, but there you also included the verb "write" which is missing from the current proposal. It might certainly be implied, but explicit is better than implicit (to cite the Zen of Python).

Edit to clarify: I don't mind the intention of the policy (especially when it's just about writing), it's just the wording I'm worried about.

+1

+1 (Even Rouault)

For what it's worth, that's a +1 from me.

Declared as approved with votes from @rouault-on-strike @alexbruy @signedav @elpaso

For the record, +1 from me as well, thanks @nyalldawson