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

[ speaking personally, not officially in any capacity ]

"Scott L. Burson" <[email protected]> writes:

> Everyone here knows that LLMs can screw up, 

My contention is: in their current (virtual) incarnation, LLMs cannot
screw up.  They have no agency, they have no capacity for choice: they
are tools.

Those tools can be misused; they can be used well, for purposes that
someone designed them for; those purposes can be generally positive for
humanity, or generally negative; they can allow people (including
fictitious people like limited-liability companies) to externalize
certain costs because of an inadequate legal or regulatory framework.
But if 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.

> just like us humans

Unfortunately I don't think this is the case: 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 

> and that all submissions need to be thoroughly vetted.

For my own practice: I have found it more necessary to read submissions
to anything I care about much more closely, and with much more
suspicion.

There has always needed to be a generic amount of suspicion, because
people are imperfect, don't always have the same context or constraints,
or are motivated by different, possibly antagonistic incentives.  It's
generally been reasonable, though, to assume that potential contributors
have good intent, and that it is worth investing time to review
contributions and communicate because even if the contribution is
ultimately not accepted there is capacity for the counterparty, and
other people, to learn.  I think until now this has served us reasonably
well, modulo the general lack of that time to invest.  (I hope that
there has not been an as-yet-undetected sophisticated supply-chain
attack similar to the xz compromise as a result of this general policy).

Now, however, the vetting is harder.  It is *exhausting* to have to read
everything in a patch line by line with adversarial suspicion.  It is so
*easy* to skim something, see the markers of fluent competence in a
well-formatted commit message, well-commented code, glance that the code
seems plausible and not consider even for a moment that none of the edge
cases are covered, or that the tests are not actually testing what they
seem, or that the patch that purports to fix a threading issue in fact
does nothing.

As a secondary point, I am also finding it less likely that people
actually respond to factual correction about what they have written or
otherwise produced, whether that's in the domain of recent history or
specific technical points; it seems even more futile than
https://xkcd.com/386/ to attempt to correct misinformation.  That won't
stop me from trying.

> 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.

If I'm allowed to be included in the team, I thank you for your
confidence, and it's certainly my intent to help maintain standards, but
there *are* reasons why it would change now: the effort required from
people to produce plausible but wrong things is much, much lower than it
used to be.  I think it's inevitable that maintainers will make
mistakes, and it'll be more important than ever for everyone who can to
call out those mistakes as quickly as possible.

Christophe