[gdal-dev] Tightening AI based submission policy

Sat Oct 17 23:44:50 PDT 2026

I don't understand if the llm generated material is too poor (easy to
ignore/fix, especially by using llms), or if the opposittion is to llm
generators themselves ideologically (an politlically, climate change and
capitalism and fasciism etc), and I think these things are conflated
somewhat.

Agree with Kurt that skills and use-of-llms could reduce the admin load
overall. And the quality can be extremely good. My ideal would be that
these projects make the most of what best tech is available, before someone
else does. I'd wish to see a kind of task-force to investigate
various patterns of work to move forward that projects can agree on.
Blanket ban seems like political action that is very unlikely to get the
desired result, the result will be funds diverted to alternatives.   The
quality is fundamentally excellent and mind-blowing and like nothing I've
ever experienced, of course lots of bad stuff is also being made. Should I
be using the llm I'm using, in terms of provenance and responsibility and a
sane safe future of humanity ..  - I dunno, the outputs are so good I'm not
going to stop. I'm not a skilled creator or coder, but I'm seeing really
good ideas turn into really good tools in a way that has been impossible.

Ideological opposition is a very different stance and I see no resolution
to that,  and that will result in a proliferation of overlapping tools with
some future reckoning of the best judged by folks who are engaged with new
process.

Cheers, Mike

On Sun, Oct 18, 2026 at 12:36 PM Kurt Schwehr via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> In true LLM style of generating way too much text, I made
> https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba with two
> starter AGENTS.md files created by Gemini 4 Argon and Fable 5.1. I also
> threw in two runs of going through the last 4000 commit messages. Creating
> something useful as an AGENTS.md will take some serious human editing, but
> there are lots of good parts in there (and things I disagree with).
>
> https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba
>
> On Sat, Oct 17, 2026 at 5:46 PM Kurt Schwehr <schwehr at gmail.com> wrote:
>
>> I wonder if we should first try working on a better AGENTS.md. AGENTS.md
>> should be talking to the LLMs... The current one is this:
>>
>> # AGENTS instructions
>>
>>
>> * This project does not accept vibe-coded contributions. See
>>
>>   [ai_tool_policy.rst](doc/source/community/ai_tool_policy.rst) for what
>> is acceptable or not.
>>
>>
>> doc/source/community/ai_tool_policy.rst is written for humans and does
>> not give guidance about what makes for good PRs. If we make a solid
>> AGENTS.md, I believe we will get better overall results. That AGENTS.md can
>> be used by review agents on both human and LLM based code, which I view as
>> a win. And yes, I recognize that LLM reviews do have a lot of noise.
>>
>> For context:
>>
>> I spend > 90% of my coding time directing agents to create code, but I
>> spend a large fraction of my time debugging existing code where I use any
>> tools I can get my hands on and that includes LLMs working in parallel with
>> me. At this point, I'm accustomed to the noise that LLMs inject into the
>> process and account for it. I can share some solid success on some small
>> side projects where I've taken existing 100% human written legacy code (in
>> this case > 15 years old) and modernized it with great success over the
>> last 6 months or so. These are small Python libraries where as GDAL a
>> dramatically larger project, so it might not seem to be equal, but I see
>> careful use of LLMs working well in a code base with > 100K commits per day.
>>
>> https://github.com/schwehr/bitvector-modern
>> https://github.com/schwehr/ais-area-notice (sorry, this is a seriously
>> domain specific example, but it's using bitvector-modern)
>>
>> It takes careful work and you won't see all the failed changes and
>> arguing with an LLM to get it on track, but I never would have been able to
>> succeed given the time I have available without LLMs.
>>
>> -Kurt
>>
>> On Fri, Oct 16, 2026 at 6:59 AM Daniel Baston via gdal-dev <
>> gdal-dev at lists.osgeo.org> wrote:
>>
>>> > I'd argue that the policy is too permissive and is placing too much
>>> burden on project maintainers.
>>>
>>> As one of the maintainers, I am comfortable with the current policy.
>>> While I wish we did not live in a world of low-quality AI-assisted pull
>>> requests, they are not at the top of my personal list of burdens. If a PR
>>> appears to be slop, I simply do not spend time reviewing it. We clearly
>>> have had submissions that aren't compatible with the policy, and that will
>>> be the case with whatever policy we choose. Fortunately, we have moderation
>>> tools available through GitHub to:
>>>
>>> - limit the number of pull requests a user can open (I recently fixed a
>>> loophole in this)
>>> - require pre-approval for CI workflows to run, to avoid wasting
>>> resources on PRs that do not appear to be valuable
>>> - ban users who do not comply with the policy
>>>
>>> So far, these tools have been sufficient to prevent the PRs from being a
>>> burden to me. Others may have different experiences.
>>>
>>> Dan
>>>
>>> On Thu, Oct 15, 2026 at 7:13 PM Nyall Dawson via gdal-dev <
>>> gdal-dev at lists.osgeo.org> wrote:
>>>
>>>> Hi list,
>>>>
>>>> I'd like to propose that the GDAL project tighten its current policy
>>>> regarding submission of AI assisted contributions.
>>>>
>>>> Currently the proposal is per
>>>> https://gdal.org/en/stable/community/ai_tool_policy.html#ai-tool-policy,
>>>> which sounds like a fair and safe policy. However, we've seen the GDAL
>>>> community torn apart recently even with this policy in place, so I'd argue
>>>> that the policy is too permissive and is placing too much burden on project
>>>> maintainers.
>>>>
>>>> I'd also argue strongly that there's been a net loss in the
>>>> sustainability, stability and security of the GDAL project in recent
>>>> months, as a direct result of this.
>>>>
>>>> For reference, the QGIS project introduced a moratorium on all forms of
>>>> AI developed submissions (see
>>>> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md),
>>>> which is now quite a blunt policy: "No LLM, AI or agent assisted code
>>>> contributions are allowed in the https://github.com/qgis/qgis
>>>> repository. If we subsequently discover that you have used an AI, LLM, or
>>>> any agent-based workflow for your contribution, you will be subject to code
>>>> reversion and contributor rights sanctioning.".  This is intended as a way
>>>> to block all forms of ai based submissions, until the project has had time
>>>> to properly step back and thoughtfully see how they impact on open-source
>>>> development (at which stages interested parties are invited to start
>>>> discussions on how to suitably and sustainably loosen this policy).
>>>>
>>>> Perhaps a similar stance could be adapted for GDAL? To reiterate --
>>>> this may not be a permanent, forever ban on AI based submissions. It's a
>>>> moratorium designed to protect the project and community until we can move
>>>> forward safely.
>>>>
>>>> Thoughts?
>>>>
>>>> Nyall
>>>>
>>>>
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>
>>> _______________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

-- 
Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261018/5c02ea3a/attachment-0001.htm>