Re: Common Lisp with no AI (that's ironic I suppose)
"Scott L. Burson" <[email protected]> Fri, 27 Feb 2026 15:38:06 -0800
| Newsgroups | gmane.lisp.steel-bank.devel |
|---|---|
| Message-ID | <CAF5LJ4AVNk7bUeqOjNOKrUS86j3JYF4d-cR590p99KACSB=RAg@mail.gmail.com> |
On Fri, Feb 27, 2026 at 3:59 AM Christophe Rhodes <[email protected]> wrote: > [ speaking personally, not officially in any capacity ] > > "Scott L. Burson" <[email protected]> writes: > > > Everyone here knows that LLMs can screw up, > > [I]f we say that that is the fault of the LLM, even as shorthand, we > fail in insisting that the people making choices take responsibility for > those choices. Someone taking "LLMs can screw up" as relieving themselves of responsibility for choosing to use one is reading my statement in the opposite way from how I intended it. But, perhaps you're right that some will take it that way. Unfortunately [...] the quality of error is > different in generic LLM output for a prompt or scenario compared with > generic, or even expert, human for a similar scenario. In particular, > with humans errors tend to be correlated -- a person not paying > attention to a particular aspect of a problem is also, all other things > being equal, more likely to leave typos in, fail to use technical terms > correctly, and so on. These markers of poor attention to detail are > essentially absent, or so different as to > Can I tease you a little about forgetting to end a sentence whose subject was attention to detail? :-) :-) Now [...] the vetting is harder. It is *exhausting* to have to read > everything in a patch line by line with adversarial suspicion. > I see. All that being the case, and apropos of the earlier conversation about whether you should formally adopt a policy on AI-generated submissions, I think you are making a strong case for doing so. I think you could fairly insist on disclosure. As a secondary point, I am also finding it less likely that people > actually respond to factual correction Oof. That's a disturbing trend. -- Scott _______________________________________________ Sbcl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sbcl-devel