Hi folks, I appreciate everyone's thoughts.
I would urge everyone to avoid using LLM generated text in any communication intended to be read by another person, which includes tickets, notes, commit descriptions, PR descriptions and changelog entries. Why is that? 1. Writing is a tool for thought and a skill that needs to be practised. By writing things out, from your own perspective, you gain better understanding and that better understanding can help steer you to even clearer communication! It might seem like a silly suggestion to make for tickets, since if you are opening a ticket, you clearly have some sort of issue that needs addressing. But I have often found that upon writing out my issue in the textbox, that my solution becomes clear. At other times, I would have benefited from thinking more before opening an issue! You also gain a better and better sense of what is signal and what is noise. 2. I can only describe the experience of reading LLM generated text as quite often painful for me. This is partly due to seeing this sort of thing quite often on the Internet and at work (similar to banner ad blindness). I will glance through a sentence and my eyes will glaze over and I will think "that looks ok", only to re-read it and think "this sentence says nothing". I would much prefer something less grammatically correct written by a person. I do not object to people making issues that have reproducers generated with LLMs or to machine translation. I like this slop-as-log metaphor. Logs and slop are indeed both low signal-to-noise. But there is one crucial difference: a log is a primary source, slop is a secondary source. I think LLM output being prose obfuscates its nature. It is rarely helpful to copy and paste the first page of Google search results that come up from keywords and while it is often more helpful to paste LLM output than that, but it is still the same sort of thing. Part of why this is unhelpful is because we all have access to LLMs. We can simply search ourselves. In a similar way (this is purely hypothetical), it is helpful to open an issue with a link to an academic paper you think would be cool to implement in GHC. If you understand GHC internals, it is helpful to map it onto GHC. But it is generally not helpful, in my opinion, to paste LLM output into the ticket, within a collapsible section or otherwise. Including these things creates a bad dynamic. Either you are acting as a meat proxy, in which case the other people in the conversation should just interact with the LLM directly, or it isn't adding much value, in which case it should be cut. It also encourages a mode of engagement that is passive and LLM led, which is not the dynamic we want for our community, I feel. It is very important to draw a line between using LLMs as a tool and using LLMs as a replacement for thought. I am not accusing anyone of doing this here, but this is a very slippery slope. The affordances of this technology really push you towards this direction, and we as a community need to put safeguards in place to gently avoid us falling into these traps. The way I see it, the only legitimate way to use an LLM to write a ticket is to produce or minimize a reproducer. Everything else should be written by a person. If the person has little context, that's OK! Tickets can be short, and I have seen many tickets produced with LLMs that are basically just a reproducer, and I personally find that much better than having lots of noise in there. I think these resources from Oxide are good: _https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers_ _https://bcantrill.dtrace.org/2026/09/05/the-revolt-of-the-reader/_ Cheers, Teo On Fri, 23 Oct 2026, at 10:14 AM, Mikolaj Konarski via ghc-devs wrote: > I'm guessing, the situation Kazu describes, of contributing > to a package, like Haddock, one doesn't maintain nor does > necessarily understand deeply, may be another case were > the "embrace the slop" aka "slop-as-log dumps" procedure > can be fruitful. > > The procedure is: > 1. tell your user story, why important to you, how urgent > 2. name the LLM and any special overrides applied to it > 3. give the sloppy blob verbatim, as you'd do with a log > 4. state clearly you don't take responsibility for the slop > and so you don't propose to merge/apply/follow the slop > > I've already seen a valuable GHC contribution done this way, > via an MR that was understood as never intended for merging, > but just an idea and a proof of concept. > > I think this beats any mixed approaches, e.g., asking > the drive-by contributor to fix the slop, which may introduce > errors both because the contributor does not necessarily > follow all that LLM is doing nor does understand the project > that deeply. This only deepens the misunderstanding and masks > the mismatch of expectations. The question remains if slop > contributions are valuable at all in the context of the scarcity > of maintainers of the given packages. I suppose a "no MR > is entitled to a review" rule lets the answer emerge naturally. > > Anyway, what I'm saying is let's avoid at least the part of the LLM > contributions friction that comes from misunderstandings. > Let's try to clearly distinguish the old style contributions > from the new, which are at once a signal of need and urgency > and a (possibly misguided) idea and a proof of concept, > but not a promise of, through MR coaching, becoming expert > enough to land the MR competently. > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
