[gdal-dev] Tightening AI based submission policy

[Kurt Schwehr]

In the spirit of discussion, I've created this PR to CONTRIBUTING.md to
make that file more direct. I didn't know (or maybe it's just my bad
memory) the attempt to trick LLMs was in that file. I've made the PR draft
as I don't think it should be submitted until there is discussion about it.
There are a couple types of feedback that should be called out w.r.t. this
PR:

1) Given the current policy, what text should go in that file?
2) Where and how should GDAL document the policy so that there is a better
chance of PRs being outside of what the policy allows.
3) The discussion here about what the policy should be --> I would
appreciate keeping these types of comments in this thread

https://github.com/OSGeo/gdal/pull/15415
CONTRIBUTING.md: Be more direct about vibe coding and autonomous agents.
[ci skip]

Please feel free to comment on the PR even if you aren't on the reviewer
list.

On Sun, Oct 18, 2026 at 7:41 AM Greg Troxel <gdt at lexort.com> wrote:

> Michael Sumner via gdal-dev <gdal-dev at lists.osgeo.org> writes:
>
> > 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.
>
> I think there are three issues, super roughly
>   - "dealing with LLM text"
>   - "LLM text in the project is bad for the project's social structure"
>   - "a broad culture of LLM use is bad for society".
> and I think you are referring the the third as "ideological".  However,
> I think most of the concerns are reachable from the first two parts
> alone.
>
> With 'dealing with', there are two problems, and pro-LLM people have
> not, to my knowledge, made any significant argument/approach to fix
> them.
>
> One is that LLM-wielders produce bits that need maintainer attention at
> a high rate with much less effort.
>
> The biggest one in my view is that LLM-generated submissions are overly
> verbose and both appear plausible and are often subtly wrong.  The
> review burden for such a subsmission is vastly higher than for a PR
> created soley by a (competent) human.  Hard to estimate, but 10-20x as
> hard seems about right.  To "fix" an LLM submission, it needs to be
> understood by a human, the subtle bugs removed, and rewrittento be as
> conscise as a human (who is qualified to work on the codebase in
> question) would make it.
>
> The above leads to "no LLM text in what is submitted".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261018/cb604227/attachment.htm>