Re: Common Lisp with no AI (that's ironic I suppose)

Hayley Patton <[email protected]> Fri, 27 Feb 2026 22:08:31 +1100
Newsgroups gmane.lisp.steel-bank.devel
Message-ID <[email protected]>
On 27/2/26 19:15, Scott L. Burson wrote:
> You're seriously suggesting you would stop using SBCL if it contained 
> any LLM-generated code whatsoever, no matter how thoroughly tested and 
> painstakingly reviewed?  I think that's silly.  Everyone here knows 
> that LLMs can screw up, just like us humans, and that all submissions 
> need to be thoroughly vetted.  Though I'm not on the SBCL team, I have 
> complete confidence that everything they accept into the code base 
> will be of the highest possible quality.  That's how they've done 
> things for 20+ years, and there's no reason it would change now.

I think, from a quality standpoint, anything which is adequately 
reviewed is fair play. But two thoughts: being able to generate a lot of 
code in a short time is firstly how you exhaust the maintainers.

That infamous OCaml PR got dropped on the floor for being unreviewable: 
https://github.com/ocaml/ocaml/pull/14369#issuecomment-3556593972

LLVM maintainers are coming up with policies to keep their code review 
sustainable: 
https://discourse.llvm.org/t/rfc-llvm-ai-tool-policy-start-small-no-slop/88476

> Two things are happening rapidly: LLMs are getting better at 
> programming, and people are learning how to get better work out of 
> them.  The attitude you are taking has been defensible until very 
> recently, but I think it no longer is, or won't be for long.

I don't think it is yet, judging by the recent Claude-authored patches 
and emails here. It's very arguable that LLMs screw up more than the 
median SBCL contributor, so patches generated by LLMs demand more scrutiny.

I'll leave the moral arguments to others, but at minimum and secondly I 
like the principle that a contributor should be able to "own" and 
explain their contributions. That's less of a given with LLM generation.



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