And of course their prose is awful and can't see the forest for the trees, which besides being written by AI just make them overall bad comments to have.
> On 14 Oct 2026, at 14:06, Rodrigo Mesquita <[email protected]> > wrote: > > In my experience, any comments generated by AI are tiring to read exactly > just because they were written by AI. > > Instead of the comments being a guiding line of thought, they become > adversarial things that also need to be distrusted and validated for “does > this make sense”, “is this insightful”. > This just results in having to double check every (imprecise, natural > language) comment with the same level of discernment required for code. > If there is no guiding line of thought we might as well let the code be its > own explanation alone, since that is objective. > > I don’t think we’d be worse off by using LLMs which are forbidden from > writing comments altogether. > > Rodrigo > >> On 14 Oct 2026, at 14:00, Simon Jakobi via ghc-devs <[email protected]> >> wrote: >> >> Thanks for your message and your review efforts, Andreas! >> >> This is an issue I've been struggling with, primarily in my own >> patches. Recently I've often spent more time and effort trying to get >> the prose into an acceptable shape than on any other aspect of a >> patch. While I believe that this has been fairly effective at removing >> unnecessary context, the readibility of the result is often still not >> great, so I'd be very interested to learn how other contributors >> manage to achieve good quality comments with their LLM-assisted >> workflows. >> >> Regarding your MR feedback: Do you think you could point out >> relatively precisely _what_ you regard as a problem, e.g. bad wording, >> unnecessary factoids, etc? >> >> For example, in >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16543#note_700940 >> you complained about the "LLM Rambling", but I couldn't tell which >> comments or commit messages you actually found confusing, and why. (I >> had actually invested several hours into them.) >> >> I understand that my request takes even more effort from you – I will >> try to make it pay off. >> >> Thanks! >> Simon >> >> >> >> >> >> Am Mi., 14. Okt. 2026 um 13:08 Uhr schrieb Andreas Klebinger via >> ghc-devs <[email protected]>: >>> >>> Hello Devs, >>> >>> Given the use of AI has increased recently I think this deserves discussion. >>> >>> There are certain texts that are, ultimately, transient, or read less >>> frequently as time moves on. >>> This broadly includes tickets, which generally become mostly irrelevant >>> once resolved. >>> >>> While reading AI tickets can be exhausting, I'm willing, within reason, to >>> accept them as a fact of live. >>> >>> But there are parts of the code base in which we have prose that is written >>> once and read >>> often. I'm primarily concerned with Notes, Commit messages, and to a lesser >>> degree code comments. >>> >>> I've noticed more people have been posting LLM generated bug fixes (fine, >>> it's policy) where >>> seemingly little work went into polishing texts other devs will read many >>> times. I consider this a problem. >>> >>> I think it's important for certain parts of the code base to be written >>> concisely. Something LLMs >>> are terrible at today, and even skills make it marginally better. This is >>> just a fact. >>> >>> I think especially with the release of Opus 5.5 this has become *more* of >>> an issue as the prose is >>> now only bad in a myriad ways that are not immediately obvious rather than >>> being obviously atrocious at a glance. >>> Which leads people to take it as-is without putting effort into writing it >>> by hand, or at least trimming it down after the fact. >>> >>> This is obviously bad for human consumers of these texts. But even if you >>> are "all in" on AI these texts >>> are also objectively garbage for future AI use as they are bloated with >>> irrelevant facts, meaningless past >>> history, repeating things obvious from context and generally wordy for no >>> benefit. >>> >>> They are simply bad. >>> >>> Is it fair to expect people to put in more effort into these? I think yes. >>> >>> Notes are *the* way to understand the code base. And making them worse >>> permanently >>> degrades the ability of newcomers to understand the codebase. Similarly >>> commit messages >>> are hugely important to be able to determine when changes where introduced, >>> quickly find >>> ranges of commits to bisect for new bugs and many more regular maintenance >>> tasks. >>> >>> My plan is to aggressively request improvement of prose during MR review >>> going forward. >>> >>> Accepting bad prose is worse for maintainers because they have to read >>> texts three times to understand what is going on. >>> It's worse for agents because it fills context windows with irrelevant >>> facts and pointless trivia that poison their >>> reasoning ability. >>> >>> It's just worse, and it takes little effort to fix. >>> >>> But maybe I'm alone in feeling this way. If everyone else is happy to read >>> Opus text output all, or at least to have opus read opus >>> output all day long. Then I will surrender this fight and move to another >>> hill to die on. >>> >>> But if people are feeling similarly then please let me know and do likewise. >>> >>> I don't think it's a big ask either. If you are prompting already just type >>> a draft in your commit message/note and let claude do >>> formatting/typo/alignment fixes. A sloppy text pushed through claude will >>> in most cases beat what any model today >>> will generate on it's own. Maybe this changes in 2 years. But it's not >>> changing today. >>> >>> It's not just a question of length. You can make a LLM generate shorter >>> texts with a skill file or otherwise. >>> But they are terrible at understanding what the tricky parts are, what is >>> worth highlighting, what can >>> be dropped because it is obvious from wider context. >>> >>> I think it's *easy* for every contributor who knows what is happening in >>> their patch to reach a reasonable standard. >>> But we have to ask them to do it and to set the expectation. And I hope we >>> can do so. >>> >>> Andreas, >>> >>> freshly back from reading some claude output. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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] > _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
