[gdal-dev] Tightening AI based submission policy

Sun Oct 18 13:03:11 PDT 2026

I believe the term is "meat proxy" :)
https://not-an-llm.com/meat-based-llm-proxies /
https://gruhn.me/blog/2026-08-03/

And that's basically what I was doing with
https://gist.github.com/schwehr/aafff40637236e1ba924495a947e00ba

But TIL https://en.wikipedia.org/wiki/Meat_puppet

On Sun, Oct 18, 2026 at 12:41 PM Nyall Dawson via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

>
>
> 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
>>
> _______________________________________________
> 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/8f8b1725/attachment.htm>