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