@swannodette Christophe’s lengthy review resonates with my experience reviewing design docs and code that was largely llm generated by a skilled colleague.
The meta comments he makes about the fatigue of reading due to the error rate, confident language, and structure transcends subject matter, in my experience. The knowledge that a stochastic machine is a intimate interlocutor between you and the other participant is tiring. You lose signals about where the submitter has spent attention and time, and where machine extrapolation has convinced them upon initial review.
I have seen this also in professional work, reviewing PRs from senior devs who have been , to be blunt, degraded by this type of LLM interaction.
Our approach at work has been to hold the submitter personally responsible for the quality of work and communication, and ask for transparency in the use of the tools, while making it clear that they are accountable for the quality and also the clarity of communication around it.
Software is easier to fix than relationships, so I appreciate the way SBCL handled this. I caution others against conflating this proposal with the slop PRs curl and others get which overwhelm them.
@craigbro @swannodette I appreciate this kind of comment/pushback because while I'm staunchly opposed to LLMs on social grounds, I do see that Chrstophe and Stas both still deeply care about maintaining a quality compiler. Anthony Green, the one driving the implementation of fibers is not a nobody but it definitely seems like Claude is in the driving seat based on the commits of their branch. They do seem to be taking it seriously though.
Still its hard to tell whether or not one should be staunchly opposed to LLMs even in cases like this where the project is still in quality hands. Do we ignore the social chaos of LLMs even when they're used 'appropriately' (and is that something that can be done?). Genuine questions I'm unsure of.
@zyd @craigbro @swannodette For me, the answer is yes, they should be rejected because of the source. If you could do an ethical LLM (still unsure about that) then I would probably be fine with them when used responsibly (meaning "not spamming with submissions").
When Claude and friends are the source these should be rejected outright. The social cost is too high.
@gwozniak @craigbro @swannodette Just in case I wasn't clear, and to make sure I understand your own position: what I meant is, if a given project starts accepting LLM contributions like these, and the maintainers response is to critically evaluate them, perhaps with extra scrutiny like what is happening in this list thread, should you be staunchly opposed to even using this project now that it is incorporating LLM contributions?
I'm always going to be opposed to LLMs at all times no matter what, especially when it comes to using them: that's my own hardline. What I'm extremely unclear about is whether this hardline then should be extended to software I use, such as SBCL. It's a case where the maintainers themselves are not vibecoding and have talked about how they themselves do not use LLMs but they will accept such patches.
Even when 'software quality is still in command' so to speak, should projects like SBCL still be rejected (in use, promotion/recommendation etc) on the basis of the social ramifications of LLMs?