[gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision

Andrew Bell andrew.bell.ia at gmail.com
Wed May 6 18:33:20 PDT 2026


I've seen this in other instances... Where the generated code is doing
things like argument checking before calling some library function when the
function explicitly handles the case. The AI doesn't seem to read the docs
:)

Andrew Bell
andrew.bell.ia at gmail.com

On Wed, May 6, 2026, 9:11 PM Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> As an example of the kind of horrors LLM code can produce, look at
> https://github.com/OSGeo/gdal/commit/135cd919e75ed35ca384c058e083b3dbafc06a5b
> which undoes the bloat a previous LLM-generated commit had caused. I was
> really mad when I discovered this:
>
> - when you use intrinsincs, you care about (near) optimality. Here the
> code was doing useless manual clamping to [0, 255], which is exactly what
> the intrinsincs _mm_packus_epi16() does afterwards
>
> - and I was mad against myself for not having detected that at review time
> (but we all know that humans are terrible at reviewing code, hence they
> need to be eliminated)
>
> It seems very unlikely a human would have produced such code, because the
> cost of writing that useless clamping, and getting it right, would have
> been too high compared to the initial reading of the doc of the _mm_pack
> intrinsincs and realizing they already do the wished clamping. It looks
> like LLM would behave like developers payed proportionally to the number of
> lines of code they produce, which we all know is a terrible metrics.
> Le 06/05/2026 à 19:14, Darafei "Komяpa" Praliaskouski a écrit :
>
> Hello,
>
> Is it possible to get a better overview of the actual negative impact
> you're seeing? Like, with actual examples of annoyances that happened.
>
> I tried my own research going through several pages of merged/closed PRs
> to get my impression on what went wrong but really most PRs are there by
> Even, with disappearingly small number of PRs from other people both by
> count and by volume, seemingly not enough to trigger such drastic policy
> flip.
>
> What am I missing?
>
>
>
> On Wed, May 6, 2026 at 8:29 PM Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>> Hi,
>>
>> based on the experience gained from the initial policy, I propose to
>> significantly revise it to drastically limit their use. See
>> https://github.com/OSGeo/gdal/pull/14500
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>> Highly recommend OxiGDAL if you want to live in the 21th century and cure
>> Bixonimania
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
> Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania
>
> _______________________________________________
> 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/20260506/afe3905a/attachment.htm>


More information about the gdal-dev mailing list