[gdal-dev] Tightening AI based submission policy

Sun Oct 18 12:32:00 PDT 2026

Don't know if I should burden you with this - am not involved party,
interested only.
But submitted the conversation (don't shoot me) to deepseek and got the
following. It seems reasonable.
There is the gdal community, they have (probably) had some issues with ill
advised pull requests containing 'vibe coding'. But the going on regulating
LLM contributions (direct or indirect) is clearly hard. What would you say
about this?
On the GDAL AI-contribution thread: a hard problem, and the mailing list
shows why

This is genuinely hard, and the thread is valuable precisely because it
exposes how many *different* problems are being bundled under one policy
question. My read of the exchange:
The strongest argument in the thread isn't "AI is bad" — it's asymmetric
review burden

Greg Troxel and Javier Jimenez Shaw land the most defensible point: the
cost of *producing* a submission has collapsed while the cost of *reviewing*
it has not. A plausible-but-subtly-wrong, verbose PR costs a maintainer
10–20x what a competent human-written patch does, because it must be fully
understood and effectively rewritten. That's an economic argument about
maintainer time, not an ideological one, and it survives regardless of how
good the models get. Andrew Bell's point about test bloat (more test lines
than code change, slowing an already-slow CI) is the same argument in a
different register.

Notably, Daniel Baston — an actual maintainer — says the current policy
plus GitHub moderation tools (PR rate limits, CI pre-approval, bans) has
been *sufficient* for him. That's important counter-evidence: the "burden"
claim is not uniformly experienced, and the thread would be better if it
surfaced concrete PRs rather than abstractions. Andrew Bell's closing
request for real examples is exactly right.
The QGIS-style moratorium is a blunt instrument with a real cost

Nyall's proposal is honest about being a time-limited moratorium, not a
forever ban, which is more defensible than a permanent prohibition. But
Andrew C Aitchison's objection is the one I'd press hardest: *if the
problem is reviewer resources, a total ban doesn't obviously protect
reviewer resources* — it just relocates the judgment call to "did they use
AI?", which is unverifiable and invites the same policing burden. And his
concrete case — using an LLM to *find* a bug, then understanding and taking
responsibility for the fix — is exactly the kind of use a blanket ban
criminalizes. A policy that can't distinguish "LLM helped me debug, I
understand and own this" from "agent spat out a 2000-line PR I never read"
is doing blunt work where precision is available.
Michael Sumner's framing conflates things, and Greg's three-way split is
the right correction

Sumner asks whether opposition is about quality or ideology, and suggests a
blanket ban is "political action." Greg's decomposition — (1) dealing with
LLM text, (2) LLM text damaging the project's social structure, (3) LLM use
being bad for society — is the cleanest analytical move in the thread.
Points (1) and (2) are sufficient to justify *some* policy without touching
(3), and that matters: it means people who are enthusiastic LLM users (like
Kurt Schwehr, who is candid about spending >90% of coding time directing
agents) can still support a tightened policy on non-ideological grounds.

Sumner's own position — "the outputs are so good I'm not going to stop" —
is honest but is a statement about *his* experience producing code, not
about the receiving end. Javier's distinction is the sharpest thing in the
thread: *you* using an LLM on *your* project with care is not the same as
*strangers* firing agents at *your* project. The externalities run one
direction.
What a good policy probably looks like

The thread implicitly sketches something better than either pole:

   1.

   *Keep the current disclosure-based policy, but make non-compliance cheap
   to close.* Greg's observation is the operational crux: in proj and gdal,
   likely-LLM PRs get labeled and left *open*. A policy whose enforcement
   is "label and wait" is worse than useless — it signals tolerance. The fix
   is procedural: undisclosed/likely-LLM submissions get closed quickly, not
   labeled and parked. That's a moderation-culture change, not a policy-text
   change.
   2.

   *Put the guidance where the models read it.* Kurt's AGENTS.md idea is
   the most constructive proposal in the thread. If the policy document is
   written for humans and the agents never see it, you get exactly the failure
   mode you're trying to prevent. A well-edited AGENTS.md plus a blunter
   CONTRIBUTING.md (his draft PR #15415) attacks the problem at the source
   rather than at review time. Caveat: an AGENTS.md is advisory to a
   stochastic system, not a filter — it will improve the distribution, not
   eliminate slop.
   3.

   *Separate "disclosure + human ownership" from "volume."* The defensible
   core rule is: *a named human must write the issue/PR description,
   understand the change, and take responsibility for it.* That covers
   Andrew Aitchison's debugging case, covers translation/refactor use cases,
   and excludes agent-fire-and-forget. Pair it with rate limits and CI
   pre-approval (which Dan says already work) to handle volume.
   4.

   *Distinguish contribution types.* A driver submission that a human has
   tested and understands is not the same as a drive-by typo PR generated by
   an agent. Policy that treats all code equally will either over-block or
   under-block.

Where I'd push back on the thread

   -

   Nyall asserts "net loss in sustainability, stability and security in
   recent months" and "community torn apart" without examples. That may be
   true, but as written it's an assertion that can't be evaluated — and
   Daniel, a maintainer, disputes the burden framing. The moratorium case
   needs evidence, not just frustration.
   -

   The QGIS precedent is cited as if its bluntness were a virtue; it's
   better read as "they hadn't solved the hard part either."
   -

   Nobody has proposed a *measurement*: e.g., time-to-review or revert-rate
   on disclosed-AI vs. human PRs. Without that, this debate will keep cycling
   between "slop is drowning us" and "I just close the slop."

Bottom line

The moratorium is a defensible *emergency brake* if the maintainer burden
is real and unmanageable — but the thread doesn't establish that it is, and
one maintainer says it isn't. The more promising path is the unglamorous
one the thread keeps circling: close non-compliant PRs fast instead of
labeling them, write the policy for the agents as well as the humans, and
make "a human owns and understands this" the load-bearing rule. That
threads the needle between Nyall's protect-the-maintainers instinct and
Aitchison's legitimate "I used a tool to debug, sue me" case — which a
blanket ban cannot.

On Sun, Oct 18, 2026 at 9:14 PM Andrew Bell via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> On Sun, Oct 18, 2026 at 10:41 AM Greg Troxel via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
>
>>
>> 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.
>>
>
> I think this discussion is pretty difficult without real examples. I've
> seen some translation and updating of projects that seem pretty amazing. On
> the other hand, most of the non-trivial fixes that I've seen haven't been
> good IMO. We had one recently in PDAL where the issue description was an
> outright lie.
>
> Personally, I think a real person should *always* write the descriptive
> text of an issue or a PR. If they can't do that (succinctly), then they
> don't understand enough to be submitting a PR. I'm also concerned with test
> bloat. The GDAL CI loop takes forever already and adding tests for small
> and probably unimportant fixes (as AI seems set on doing) only makes this
> worse -- sometimes there are way more lines of test than code change. The
> tests become a burden.
>
> Anyway, perhaps someone could point out some AI PRs that they think are OK
> and some that they find objectionable so that the discussion can move
> beyond the theoretical.
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com
> _______________________________________________
> 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/20261018/972c53ed/attachment-0001.htm>