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

To also throw in my 2 cents as someone who (occasionally) reviews and merges patches submitted by contributors, and has optimistically volunteered for vetting the llm-assisted coroutines change:

What matters to me is that the signal-to-noise ratio stays manageable. A new feature that would not otherwise have been written or landed is a very strong contribution that shouldn’t be dismissed purely on the basis of what tools were used to create that contribution. What does merit additional caution is that the contributor should be responsible for pointing out places that they don’t quite understand what is happening. This is mostly a courtesy to reviewers who can save time and focus on problematic areas. People have always relied on some sort of ethos when reviewing things others have done; a domain-expert’s changes will not be scrutinized as someone who is doing it for the first time. LLM contributions with little-to-no supervision need to be treated the same way or even harsher than the first timer, as most first-timers do not show crazy confidence in things that are wrong.

So if there were a policy, I would make just one wish: contributors using LLM-assisted tools to please be careful and respect the time of maintainers when it comes to submissions to keep the signal-to-noise ratio manageable, since this project has very little capacity for reviewing contributions already. Follow-up questions on what something does from a reviewer to a contributor should rather be answered with “I don’t know” than an LLM-produced-answer-passing-as-human-answer that might be completely wrong. Even a disclaimer that an explanation is LLM-confident (Something like “I don’t understand, but LLM xyz when asked provided the following answer: …”) rather than something a human spent time to look at goes a long way to giving a reviewer context over how much time to pour into a particular detail. I’m not sure if there’s any enforceable rule to help approximate a policy like this (which is probably why many projects have gone the blanket-ban route, understandably so) but for something like sbcl it still seems like for the time being that good-intent actors are sending things in that are overall signal rather noise, so things policy-wise can still carry on mostly as before. We can evaluate a different approach in the future if this state of affairs changes significantly. After all, the landscape is still rapidly evolving.

I don’t really understand the legal or environmental issues too much, so I won’t comment on that. It’ll be difficult to sue a public domain project though.

> On 27. Feb 2026, at 15:26, Stas Boukarev <[email protected]> wrote:
> 
> 
>> 
>> I seem to recall a commit made about 1 week ago to SBCL whose rationale was written by AI and turned out to be completely wrong. In a sane world that would be considered the final straw.
> 
> That's a misrepresentation. The commits in question were confined to
> the new, not previously existing, port to arm64 windows. And then what
> happened next? The real issues were identified and the correct
> solutions were inserted. Who was harmed?
> 
> If you want to stop using SBCL because of "AI", you have my
> endorsement. Because I myself too am using LLMs (the free ones). Not
> to edit files in the vibe fashion, but as a smarter google.
> 
> The ship has sailed, you won't be able to find things that pass your
> purity tests.
> 
>> On Fri, Feb 27, 2026 at 1:33 PM Brett Mahar <[email protected]> wrote:
>> 
>>> On Fri, 27 Feb 2026 00:15:03 -0800
>>> "Scott L. Burson" <[email protected]> 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?
>> 
>> Yes.
>> 
>> 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.
>> 
>> I seem to recall a commit made about 1 week ago to SBCL whose rationale was written by AI and turned out to be completely wrong. In a sane world that would be considered the final straw.
>> 
>> That's how they've done things for 20+ years,
>>> and there's no reason it would change now.
>>> 
>>> Two things are happening rapidly: LLMs are getting better at programming,
>>> and people are learning how to get better work out of them.
>> 
>> "The plane crashed, but the pilot is getting better all the time. Trust me bro"
>> 
>> Brett.
>> 
>> 
>> 
>> _______________________________________________
>> 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

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