[gdal-dev] Tightening AI based submission policy

Sun Oct 18 13:17:30 PDT 2026

On Mon, 19 Oct 2026, 6:03 am Kurt Schwehr, <schwehr at gmail.com> wrote:

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

Ah that's right. Just treat it as proof of my humanity 😂

Nyall

> 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/20261019/9f914f8c/attachment-0001.htm>