Re: Official policy on LLM-assisted contributions

Thank you for the thoughtful response Christophe. We'll agree to disagree
on the finer points but I respect your decision.

On Thu, Feb 19, 2026, 3:52 PM Stas Boukarev <[email protected]> wrote:

> 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