[gdal-dev] Tightening AI based submission policy

[Nyall Dawson]

On Mon, 19 Oct 2026, 5:32 am Jan Heckman via gdal-dev, <
gdal-dev at lists.osgeo.org> wrote:

> 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.
>

That is literally the WORST thing you could have contributed to this
discussion. 👎

Regardless of the stance on AI contributions, it is NEVER appropriate or
socially acceptable to be a meat puppet and share an llm response like this
in a human led discussion.

Nyall

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
>>
> _______________________________________________
> 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/20261019/067eb970/attachment-0001.htm>