[gdal-dev] Tightening AI based submission policy

[Kurt Schwehr]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261017/6d853604/attachment.htm>