Re: Official policy on LLM-assisted contributions

And here I thought adding
Co-Authored-By: GNU Emacs 30.2 <[email protected]>
as a gag.

On Thu, Feb 19, 2026 at 11:48 PM Christophe Rhodes via Sbcl-devel
<[email protected]> wrote:
>
> Richard Westhaver <[email protected]> writes:
>
> > Figured it'd be worth starting a discussion on this - what do you guys
> > think about adding some language to the HACKING file (under Patch
> > Submissions) to guide future contributors?
>
> I'm not sure it's worth it (yet, if ever).  I don't see a distinction in
> principle betwen LLM-assisted contributions and emacs-assisted
> contributions; in both cases the important part for me is being able to
> engage with the person contributing to ask questions like: "why?" and
> "why this way?" and questions of that sort.  (And, again, I don't mind
> too much whether they use ispell or grammarly or an LLM to reply, but I
> my actions and judgment will be affected by the intellectual content of
> those replies).
>
> So whatever process leads to a person's (or an organization's)
> contribution, it stands in the context of the people proposing it, who
> need to be responsive, and (usually) very, very patient, because the
> bottleneck is rarely the pace of offered contributions (bug reports,
> patches, bug fixes) -- it's the time that maintainers can spend
> assessing them.
>
> Some of this list's older readers might remember USENET (or, more
> modernly, "Usenet").  I personally caught the tail end of its "mostly
> useful" phase, and learnt about Lisp there.  But, from 1994, the commons
> of Usenet started to be tragedied, with the first unsolicited commercial
> e-mail, until the whole network collapsed under the noise.  (I'm eliding
> a whole bunch of history; please don't take this as the definitive
> story.)  The problem was a change in the cost-benefit tradeoffs: more
> people on Usenet, along with decreased bandwidth and access costs, meant
> both more eyeballs to view any messages, and lower costs to send them,
> with the (in retrospect) inevitable result.  e-mail survives, just
> about, despite having the same structural problem, but it is radically
> different from its original conception, is very difficult to run an
> interoperable node in the network, and large amounts of resources go
> into making the typical e-mail signal tolerable despite the absurd
> volume of noise.
>
> The development of LLMs and their application to programming is, I
> think, a similar change: a change in the economics.  We (more widely as
> free software developers) have already seen some of this: the advent and
> growth of programmes such as Google Summer of Code, security bug
> bounties, and the like lead to incentives to participants that might be
> surprising to those not participating: CVE requests, insistence on the
> importance of getting a pull request merged, that kind of thing.  LLMs
> change the costs more than the benefits, but we would expect to see
> similar effects (for recent examples, the stories of curl and matplotlib
> in this week's Linux Weekly News are worth reading).
>
> But what can we do about it?  We, just like USENET adminstrators, cannot
> control what people send, and trying to is essentially pointless.  We
> can, though, continue to behave reasonably: assume good intent, and
> engage to the extent of our capacity with the people considering
> contributions, and insisting as far as we can on the correctness of what
> is merged -- while reminding people that anyone who thinks they can do a
> better job for themselves (and any community they engage) is free to
> take what is provided and build on it on their own terms.
>
> Christophe
>
>
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel