LLM policy
Greg Troxel
gdt at lexort.com
Tue Jun 9 03:16:38 PDT 2026
A human recently told me to make this a new thread :-)
Recently qgis and gdal have discussed and adopted policy about
LLM-generated content in mostly PRs.
After "human must be in control and really understand" was agreed to in
gdal, somewhat (in my fuzzy view) as a compromise between the "just no"
camps and those that were somewhat more welcoming, somewhat as an
interim, a new policy of pretty much "just no" (except for fancy
autocomplete by those with clue) was proposed and adopted. Basic issues
were limited human maintainer bandwidth, humans not being happy about
interacting with machines, and code that looks very plausible but isn't
quite right, in a way that's very hard to identify.
qgis policy:
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
revised gdal policy, after a brief experiment with a policy like qgis's:
https://gdal.org/en/stable/community/ai_tool_policy.html
My own experience was in seeing hamlib (not geo) get a vibe-coded PR
while talking about policy, and I and several others reviewed it. Both
code and PR text were very wordy, in a way that wasn't helpful, and in
the end we decided the PR was off base. But it took a lot of time, it
was hard to determine if it was right or not, and a (trained software
engineer) human would have made much smaller changes and explained them
far more concisely. This experiment left me thinking that it wasn't ok
to ask humans to review, read, or otherwise deal with LLM output.
Thus, I favor the gdal approach. I suspect that after a few vibe-coded
PRs, those reviewing them will prefer that too.
Regardless of how the consensus ends up, postgis should state the rules
in CONTRIBUTING, and IMHO the rules should include up-front disclosure
of *any* LLM use in making a contribution, beyond the human contributor
gaining understanding.
More information about the postgis-devel
mailing list