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.
Hi Andreas, I think this is a great plan! Thank you! Best Magnus On 10/14/26 13:08, Andreas Klebinger via ghc-devs wrote:
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 --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
Andreas Klebinger wrote:
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.
Andreas, you’re definitely not alone with this. I think and feel the same, although I usually don’t have the “fun” of reading LLM output.
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.
I wouldn’t even think much about the effects those LLM-generated texts have for “all-in” approaches, as I consider these approaches misguided from the start.
Accepting bad prose is […] worse for agents because it fills context windows with irrelevant facts and pointless trivia that poison their reasoning ability.
[…]
[LLMs] are terrible at understanding what the tricky parts are, what is worth highlighting, what can be dropped because it is obvious from wider context.
LLMs don’t reason and don’t understand. You could perhaps say that classical, logic-based, AI reasons, but no AI understands. I think it is important to not overlook this, since it shows that the problems we’re facing here have deeper roots. All the best, Wolfgang
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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 <ghc-devs@haskell.org> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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 <rodrigo.m.mesquita@gmail.com> 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 <ghc-devs@haskell.org> 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Personally I found it quicker to write comments by hand, than to try and force the LLM to produce a sensible Note. The next best thing in my experience is to write a rough draft and let a LLM fill in the details. This way your input on what to emphasise, and what can be ignored will transfer over to the final text for the most part. Skills or instructions like "be concise" reduce the wordiness/rambliness but don't do much to guide the focus of the text. So they are an improvement. But they often also result in useful context being removed. ---------------------------------------------------------------------- About https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16543#note_700940 it's not *confusing*. It's just exhausting to read. There is terrible signal:noise ratio and a complete lack of focus. Since you asked, when looking at the commit message from a0539f8ed059a72186dc6fdeb5649ade4eb4ddbe and starting with the title:
Cmm: delete losing blocks in common block elimination What does this tell me. Cmm is fine. common block elimination is fine. But half of this sentence reads as noise. Deleting blocks is the point of CBE. so yes I would expect it to do that.
Something better would be something like Cmm: Drop duplicate blocks during common block instead of just rewriting labels. Likes yes it's not *terrible*. But it's not great. And what makes it terrible is that all of it is not great. Because if we move on:
Delete each merge's losing block in the pass itself, instead of leaving it in the graph, unreachable, until stack layout drops it. Just like any great novel it starts by repeating the title. I'm joking of course. Sometimes that can be fine but no one will read the body without the title. So again not *terrible* but lowkey bad. Then it rambles on: "Leaving them in the graph", where else would we leave them, if the graph is the only output. "unreachable", well yes or we couldn't drop them. "stack layout", I would have just said a later pass, because it doesn't matter much which one. But maybe I'm being nitpicky on that last one. This is safe: This is low key pointless again. If it were not safe why would we merge it. We are deleting duplicate blocks that are *already* dropped by another pass before this commit. Why would it not be safe? It does not say.
replaceLabels rewrites every in-graph reference to a loser to the end of its substitution chain, and chain ends never lie in the substitution's domain.
This is meaningless to anyone who hasn't already read the code. If they have read the code it's meaningless too. Because you already know this information. Which just makes this paragraph meaningless.
The one reference replaceLabels does not rewrite, info_tbls, holds only the entry block's info table at this stage, and the entry block never loses a merge -- see Note [Retain entry block during common block elimination.] What is info_tbls? What is replaceLabels? Again if I know the code enough to remember this then this is of zero value. If one doesn't know the code then it's a soup of references to things in the code we haven't seen before. It doesn't help anyone understand what the MR does without reading the code. But even if you read the code this is not really helpful to understand it.
At best this tells an LLM some keywords to grep for. But it will just look at the diff anyway. The information anyone will gain by looking at this will be near zero. Maybe the Note reference is relevant. Maybe ...
Also rewrite Note [unreachable blocks] in GHC.Cmm.Pipeline to state who actually removes unreachable blocks and when, and point at it from GHC.Cmm.ContFlowOpt. Who is this for? Who would read this and say "I'm glad I could glance from the git log that this Note was rewritten here". The note is related to the change so it was touched up. That should happen. But who wants to read about this in the commit message. I wouldn't. A LLM wouldn't. A maintainer cherry picking the commit wouldn't. Someone bisecting a bug wouldn't. A reviewer wouldn't. I think it's noise. Word shaped noise. Filling the commit message up to the length the LLM thinks it should have and nothing more. -------------------------- I have forgotten what this MR was about since I left the comment.
All that re-reading of the commit message told me was we drop some dead code in another place now. For unknown reasons. And unknown benefits. In ways I can't really gleam from the commit message either. It tells me almost none of the things I care about in a commit message, and a lot of things I don't care about. It's just bad. Bad in a myriad of tiny ways that I can point at exactly. And for any one of them one could say maybe it's not that bad. But once you throw enough pixels at a screen you get a picture. And clearly this picture is just bad. So I hope we can do better. One way or another. On 14/10/2026 15:00, Simon Jakobi 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<ghc-devs@haskell.org>:
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 --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
Am Mi., 14. Okt. 2026 um 17:59 Uhr schrieb Andreas Klebinger <klebinger.andreas@gmx.at>:
Personally I found it quicker to write comments by hand, than to try and force the LLM to produce a sensible Note.
This sounds terrifying, but I guess I'll have to give it a try. ;) And many thanks for the detailed feedback on that commit! This gives me a much clearer idea on how to improve my patches. The safety paragraph in particular was quite terrible indeed.
Also rewrite Note [unreachable blocks] in GHC.Cmm.Pipeline to state who actually removes unreachable blocks and when, and point at it from GHC.Cmm.ContFlowOpt.
Who is this for? Who would read this and say "I'm glad I could glance from the git log that this Note was rewritten here". The note is related to the change so it was touched up. That should happen. But who wants to read about this in the commit message. I wouldn't. A LLM wouldn't. A maintainer cherry picking the commit wouldn't. Someone bisecting a bug wouldn't. A reviewer wouldn't. I think it's noise. Word shaped noise. Filling the commit message up to the length the LLM thinks it should have and nothing more. -------------------------- I have forgotten what this MR was about since I left the comment.
Actually the deleteLosers addition doesn't fully motivate the docs changes. That's why I mentioned them in an "Also..." paragraph. In hindsight it would have been better to keep the docs addition in a separate commit. I'll do that when I re-submit this part of the MR. Cheers! Simon On 14/10/2026 15:00, Simon Jakobi 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 <ghc-devs@haskell.org>:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
*My plan is to aggressively request improvement of prose during MR review going forward.*
I think that's perfectly reasonable. For authors I strongly suggest simply starting from scratch, writing a fresh comment, drawing on LLM drafts iff that is helpful. That seems in line with our current policy <https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing/AI> Simon On Wed, 14 Oct 2026 at 12:08, Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I'd argue that code or documentation that is so void of meaning to the human reader isn't just low quality, but also violates P3 of the AI policy. So you shouldn't really by asking these questions here, but simply reject such contributions. They're disrespectful. What I disagree with is that issue text and comments shall be excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly. Especially now that the industry is changing, juniors are struggling to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does. On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> wrote:
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.
I’ve really been wondering if I want to engage with this. But here it goes anyway. I pretty much agree that we should in times of AI, just be expecting a higher bar and be more aggressive in rejecting poor quality. I’d even go so far to ban people after repeatedly pushing poor quality MRs. We are basically facing the same issue we face with email spam. And no, I still don’t believe there is a right to review. I still hold the position that anyone contributing will need to find a reviewer and that no one feel even remotely obliged to review MRs just because they show up on GitLab. And I would say that a poor PR is irrespective how it was conceived should be rejected. If the wording is poorly written, superfluous or does not try to hit a high bar, it’s not something anyone should entertain. Auto close. If someone comes to IRC, the mailing list, an in person event, … and tries to make their case for their contribution in an orderly manner, I’m sure there will be plenty of folks who would like to help someone engaged to contribute and support them in crafting a great contribution. Best, Moritz On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
I'd argue that code or documentation that is so void of meaning to the human reader isn't just low quality, but also violates P3 of the AI policy.
So you shouldn't really by asking these questions here, but simply reject such contributions. They're disrespectful.
What I disagree with is that issue text and comments shall be excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly.
Especially now that the industry is changing, juniors are struggling to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does.
On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Moritz, do you really think it's necessary to wave the ban hammer here?
We are basically facing the same issue we face with email spam.
Could you point out an MR that you think is essentially spam? I'm sure that there have been several low-quality LLM-generated MRs by now (some of mine included), but I still believe that every contributor is trying to make GHC better. I'm not even against firmly rejecting low-quality contributions. But I believe that essentially all contributors are fundamentally well-meaning people who will respond to nudges when being nudged. And that's just what Andreas is achieving with his email and his reviews. All this talk of banning contributors or banning certain types of contributions is IMHO just creating a hostile atmosphere that is plainly off-putting for current and future contributors. I also think it's important to keep in mind that most of us are still figuring out how to best work with LLMs. Making mistakes is an important if not essential part of this learning experience. I'm grateful to Andreas that he's willing to point out these mistakes, and I think it's the right way to grow this community. Thanks! Simon And no, I still don’t believe there is a right to review. I still hold the position that anyone contributing will need to find a reviewer and that no one feel even remotely obliged to review MRs just because they show up on GitLab.
And I would say that a poor PR is irrespective how it was conceived should be rejected. If the wording is poorly written, superfluous or does not try to hit a high bar, it’s not something anyone should entertain. Auto close. If someone comes to IRC, the mailing list, an in person event, … and tries to make their case for their contribution in an orderly manner, I’m sure there will be plenty of folks who would like to help someone engaged to contribute and support them in crafting a great contribution.
Best, Moritz
On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote:
I'd argue that code or documentation that is so void of meaning to the human reader isn't just low quality, but also violates P3 of the AI policy.
So you shouldn't really by asking these questions here, but simply reject such contributions. They're disrespectful.
What I disagree with is that issue text and comments shall be excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly.
Especially now that the industry is changing, juniors are struggling to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does.
On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Simon, We simply face the spam problem, due to the nature of the technology. It’s trivial today to create not just one, or two MRs, but hundreds easily. For trolls, bullies, or other folks just wanting to be a nuisance it’s utterly trivial to flood any service these days. The same as we have with email, you can just send anyone an email, whether or not they want any (if they have an email address). So yes, I think saying we are going to ban people who do not behave is perfectly reasonable. Same reason why we ban people on IRC and elsewhere. Do not: I didn’t say ban anyone who uses AI, far from it. What I said is: 1. Do not feel obligated to review PRs. 2. Have contributors engage with the project if they want reviews. 3. For contributors that show that they have no interest in good faith contributions (drive by, poor quality, relay chat meat proxies), ban them and ignore them. There is no point in letting poisonous folks into a community. 4. I consider a contributor that opens a MR, and does not engage on IRC, the mailing list or elsewhere with the community about their contribution a rather poor contributor. As per the earlier (no right to review) rules, their MR would just sit in the queue indefinitely. As such I expect we’d automatically sweep stale MRs that haven’t found a reviewer after a fixed period of time. Again, nothing in this says anything about the use of LLMs. This only says something about engagement in earnest and participation, as well as giving some guidance on keeping the house tidy. What’s the value of a MR from someone contributing not willing to engage with the community just to disappear again? Unless there is a core maintainer that takes enough interest in the contribution to take it over, merging it just leads to liability in the codebase. Just to reiterate: I do not believe that banning adversarial actors leads to a hostile atmosphere. On the contrary I believe it leads to a cohesive atmosphere where everyone who wants to contribute feels welcome and valued. Attention is all you have. Spend it wisely. Best, Moritz
On 19 Oct 2026, at 05:47, Simon Jakobi <simon.jakobi@gmail.com> wrote:
Moritz, do you really think it's necessary to wave the ban hammer here?
We are basically facing the same issue we face with email spam.
Could you point out an MR that you think is essentially spam? I'm sure that there have been several low-quality LLM-generated MRs by now (some of mine included), but I still believe that every contributor is trying to make GHC better.
I'm not even against firmly rejecting low-quality contributions. But I believe that essentially all contributors are fundamentally well-meaning people who will respond to nudges when being nudged. And that's just what Andreas is achieving with his email and his reviews.
All this talk of banning contributors or banning certain types of contributions is IMHO just creating a hostile atmosphere that is plainly off-putting for current and future contributors.
I also think it's important to keep in mind that most of us are still figuring out how to best work with LLMs. Making mistakes is an important if not essential part of this learning experience. I'm grateful to Andreas that he's willing to point out these mistakes, and I think it's the right way to grow this community.
Thanks! Simon
And no, I still don’t believe there is a right to review. I still hold the position that anyone contributing will need to find a reviewer and that no one feel even remotely obliged to review MRs just because they show up on GitLab.
And I would say that a poor PR is irrespective how it was conceived should be rejected. If the wording is poorly written, superfluous or does not try to hit a high bar, it’s not something anyone should entertain. Auto close. If someone comes to IRC, the mailing list, an in person event, … and tries to make their case for their contribution in an orderly manner, I’m sure there will be plenty of folks who would like to help someone engaged to contribute and support them in crafting a great contribution.
Best, Moritz
On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote:
I'd argue that code or documentation that is so void of meaning to the human reader isn't just low quality, but also violates P3 of the AI policy.
So you shouldn't really by asking these questions here, but simply reject such contributions. They're disrespectful.
What I disagree with is that issue text and comments shall be excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly.
Especially now that the industry is changing, juniors are struggling to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does.
On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I work in some fairly slop-tolerant environments, and even there I can't bear how bad LLMs currently fare at writing prose. The new rules make sense. That said, for anyone working on projects where it doesn't matter as much, I have found some guidance is more effective than others. I would link to what I use, but it was generated by an LLM (heh) and is itself kind of sloppy. It's along the lines of: * Don't repeat yourself: no repetition of ideas across code, comments, commit messages, or pull requests. Rewording counts as repetition. * Comments do not describe *what changed* or the *bug that was fixed*. That's what commit messages are for. * Comments do not restate code. Code should be self-documenting. * Commit messages are subject-line only (no body) unless the reason for the change would be non-obvious to somebody reading the diff. Never summarize the diff. It's a bit more nuanced than that (e.g. explaining what comments *are* for, rather than just what they are *not*), but I recommend trying out some variation of that. On Mon, 19 Oct 2026 at 08:48, Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Simon,
We simply face the spam problem, due to the nature of the technology. It’s trivial today to create not just one, or two MRs, but hundreds easily. For trolls, bullies, or other folks just wanting to be a nuisance it’s utterly trivial to flood any service these days. The same as we have with email, you can just send anyone an email, whether or not they want any (if they have an email address).
So yes, I think saying we are going to ban people who do not behave is perfectly reasonable. Same reason why we ban people on IRC and elsewhere.
Do not: I didn’t say ban anyone who uses AI, far from it. What I said is: 1. Do not feel obligated to review PRs. 2. Have contributors engage with the project if they want reviews. 3. For contributors that show that they have no interest in good faith contributions (drive by, poor quality, relay chat meat proxies), ban them and ignore them. There is no point in letting poisonous folks into a community. 4. I consider a contributor that opens a MR, and does not engage on IRC, the mailing list or elsewhere with the community about their contribution a rather poor contributor. As per the earlier (no right to review) rules, their MR would just sit in the queue indefinitely. As such I expect we’d automatically sweep stale MRs that haven’t found a reviewer after a fixed period of time.
Again, nothing in this says anything about the use of LLMs. This only says something about engagement in earnest and participation, as well as giving some guidance on keeping the house tidy. What’s the value of a MR from someone contributing not willing to engage with the community just to disappear again? Unless there is a core maintainer that takes enough interest in the contribution to take it over, merging it just leads to liability in the codebase.
Just to reiterate: I do not believe that banning adversarial actors leads to a hostile atmosphere. On the contrary I believe it leads to a cohesive atmosphere where everyone who wants to contribute feels welcome and valued.
Attention is all you have. Spend it wisely.
Best, Moritz
On 19 Oct 2026, at 05:47, Simon Jakobi <simon.jakobi@gmail.com> wrote:
Moritz, do you really think it's necessary to wave the ban hammer here?
We are basically facing the same issue we face with email spam.
Could you point out an MR that you think is essentially spam? I'm sure that there have been several low-quality LLM-generated MRs by now (some of mine included), but I still believe that every contributor is trying to make GHC better.
I'm not even against firmly rejecting low-quality contributions. But I believe that essentially all contributors are fundamentally well-meaning people who will respond to nudges when being nudged. And that's just what Andreas is achieving with his email and his reviews.
All this talk of banning contributors or banning certain types of contributions is IMHO just creating a hostile atmosphere that is plainly off-putting for current and future contributors.
I also think it's important to keep in mind that most of us are still figuring out how to best work with LLMs. Making mistakes is an important if not essential part of this learning experience. I'm grateful to Andreas that he's willing to point out these mistakes, and I think it's the right way to grow this community.
Thanks! Simon
And no, I still don’t believe there is a right to review. I still hold the position that anyone contributing will need to find a reviewer and that no one feel even remotely obliged to review MRs just because they show up on GitLab.
And I would say that a poor PR is irrespective how it was conceived
should be rejected. If the wording is poorly written, superfluous or does not try to hit a high bar, it’s not something anyone should entertain. Auto close. If someone comes to IRC, the mailing list, an in person event, … and tries to make their case for their contribution in an orderly manner, I’m sure there will be plenty of folks who would like to help someone engaged to contribute and support them in crafting a great contribution.
Best, Moritz
On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs <
ghc-devs@haskell.org> wrote:
I'd argue that code or documentation that is so void of meaning to the
human reader isn't just low quality, but also violates P3 of the AI policy.
So you shouldn't really by asking these questions here, but simply
reject such contributions. They're disrespectful.
What I disagree with is that issue text and comments shall be
excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly.
Especially now that the industry is changing, juniors are struggling
to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does.
On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs <
ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I find in myself that a lot of my aggression at LLMs is triggered via uncanny valley on an unconscious level and the similar "if you are so smart, why are you so dumb, making mistakes or permitting me to make them --- it must be to spite me" on the conscious level. So instead of trying to make LLMs behave (e.g., write) like a human co-worker would, I now instead embraced the slop. I let LLMs dump all the slop they want into commit messages and dedicated slop-files and state-files. This sometimes helps them not to be as dumb or protect me from being so dumb and it helps me remember they are not human. I find the GHC issue tracker organically evolved practice of wrapping particularly sloppy LLM texts in <details> very wise, similar to what you'd do to long logs appended to a message. I hope gitlab gets a <slop> tag soon. Would I file an issue ticket with just one sentence and a long <details> log? Probably not. Maybe if the log is totally self-evident? Maybe with five sentences? Are GHC devs justified to demand more than the log? Obviously so. Thank you for you patience, Mikolaj
Basically the same sentiment "machine output is raw data, log, sloppy outline" from mathematicians talking about LLM-generated proofs and how to embrace the slop there: https://youtu.be/LKrwhjOI8Nc?si=-qI0GbJo0rTSSWTW&t=1391 On Mon, Oct 19, 2026 at 1:43 PM Mikolaj Konarski <mikolaj@well-typed.com> wrote:
I find in myself that a lot of my aggression at LLMs is triggered via uncanny valley on an unconscious level and the similar "if you are so smart, why are you so dumb, making mistakes or permitting me to make them --- it must be to spite me" on the conscious level. So instead of trying to make LLMs behave (e.g., write) like a human co-worker would, I now instead embraced the slop.
I let LLMs dump all the slop they want into commit messages and dedicated slop-files and state-files. This sometimes helps them not to be as dumb or protect me from being so dumb and it helps me remember they are not human. I find the GHC issue tracker organically evolved practice of wrapping particularly sloppy LLM texts in <details> very wise, similar to what you'd do to long logs appended to a message. I hope gitlab gets a <slop> tag soon.
Would I file an issue ticket with just one sentence and a long <details> log? Probably not. Maybe if the log is totally self-evident? Maybe with five sentences? Are GHC devs justified to demand more than the log? Obviously so.
Thank you for you patience, Mikolaj
Am Di 20.10.2026 17:38 schrieb Mikolaj Konarski via ghc-devs:
Basically the same sentiment "machine output is raw data, log, sloppy outline" from mathematicians talking about LLM-generated proofs and how to embrace the slop there: […]
Why should one embrace slop if one can just avoid it?
Basically the same sentiment "machine output is raw data, log, sloppy outline" from mathematicians talking about LLM-generated proofs and how to embrace the slop there: […]
Why should one embrace slop if one can just avoid it?
Well, good luck sending a proof of a theorem to a conference, when this theorem has already been proved, in Lean, by AI. However, if the conference embraces the slop and accepts papers that treat the AI-generated proof only as raw data but explain the proof to humans, propose how to make the proof more beautiful, what next questions to ask in the domain, what theories to build thanks to the new insights stemming from the AI proof, etc., then you don't need a time machine or an Amish village to survive as a mathematician in the long run. The link again, because I'm mostly repeating its lines: https://youtu.be/LKrwhjOI8Nc?si=-qI0GbJo0rTSSWTW&t=1391
Am Mi 21.10.2026 10:12 schrieb Mikolaj Konarski:
Why should one embrace slop if one can just avoid it?
Well, good luck sending a proof of a theorem to a conference, when this theorem has already been proved, in Lean, by AI.
Luckily, I don’t have to send proofs to conferences.
[…] then you don’t need a time machine or an Amish village to survive as a mathematician in the long run.
Why do you present sticking to something that was mainstream just a few years ago as being like living in an Amish village? Doesn’t your apparent need to use such a gross exaggeration indicate that in reality my approach is not so crazy as you would like to depict it and perhaps not crazy at all? All the best, Wolfgang
Doesn’t your apparent need to use such a gross exaggeration indicate that in reality my approach is not so crazy as you would like to depict it and perhaps not crazy at all?
I expect that all I presume and say today will be invalidated a few times over in the next few years, so yes, I don't at all claim your approach is any way crazier than mine. :)
This is an incredibly unwelcoming proposition. AI proponents have fought on this ML vehemently for their right to not be discriminated against, which has lead to a rather favorable GHC AI policy. Their arguments have been heard and acknowledged. For those who are skeptics, either in terms of generative AI or AI as a whole, there must still be a way to contribute and be taken seriously. I'm also a bit surprised you're succumbing to the "you're going to be left behind" narrative. I wonder what it will do to our community or society if that is the main driver of our decisions. GHC isn't run by anthropic and while it does rely on funding, the project is free to make whatever decision it deems necessary to ensure its long-term health. There's plenty of people and projects (including compilers) that have decided that AI is unhealthy for them. Those are valid decisions and it's not helpful to belittle them as tech luddites. I find it exciting that GHC is trying to find a delicate balance between those groups. But it should start with mutual respect. Cheers, Julian On October 21, 2026 8:12:57 AM UTC, Mikolaj Konarski via ghc-devs <ghc-devs@haskell.org> wrote:
Basically the same sentiment "machine output is raw data, log, sloppy outline" from mathematicians talking about LLM-generated proofs and how to embrace the slop there: […]
Why should one embrace slop if one can just avoid it?
Well, good luck sending a proof of a theorem to a conference, when this theorem has already been proved, in Lean, by AI. However, if the conference embraces the slop and accepts papers that treat the AI-generated proof only as raw data but explain the proof to humans, propose how to make the proof more beautiful, what next questions to ask in the domain, what theories to build thanks to the new insights stemming from the AI proof, etc., then you don't need a time machine or an Amish village to survive as a mathematician in the long run.
The link again, because I'm mostly repeating its lines: https://youtu.be/LKrwhjOI8Nc?si=-qI0GbJo0rTSSWTW&t=1391 _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Am Mo., 19. Okt. 2026 um 07:48 Uhr schrieb Moritz Angermann <moritz.angermann@gmail.com>:
Simon,
We simply face the spam problem, due to the nature of the technology.
Could you please provide any evidence for this spam problem? My impression is that neither GHC nor any other Haskell project has seen a significant influx of spammy LLM-generated code contributions. So far, so good! However I'm concerned that by erecting further barriers against this hypothetical flood, we'd risk scaring away fresh contributors.
4. I consider a contributor that opens a MR, and does not engage on IRC, the mailing list or elsewhere with the community about their contribution a rather poor contributor. As per the earlier (no right to review) rules, their MR would just sit in the queue indefinitely. As such I expect we’d automatically sweep stale MRs that haven’t found a reviewer after a fixed period of time.
I think a drive-by bug-fix can still be a valuable and acceptable contribution. And you never know if a one-time contributor might come back and become a long-time asset for the project. I also don't think that any contributors should be expected to engage on these communication channels. At least I'm not aware of any channels that would be sufficiently active and welcoming that I'd recommend them to a newcomer. Discourse is alright I think, but not very GHC-specific. Cheers, Simon
Again, nothing in this says anything about the use of LLMs. This only says something about engagement in earnest and participation, as well as giving some guidance on keeping the house tidy. What’s the value of a MR from someone contributing not willing to engage with the community just to disappear again? Unless there is a core maintainer that takes enough interest in the contribution to take it over, merging it just leads to liability in the codebase.
Just to reiterate: I do not believe that banning adversarial actors leads to a hostile atmosphere. On the contrary I believe it leads to a cohesive atmosphere where everyone who wants to contribute feels welcome and valued.
Attention is all you have. Spend it wisely.
Best, Moritz
On 19 Oct 2026, at 05:47, Simon Jakobi <simon.jakobi@gmail.com> wrote:
Moritz, do you really think it's necessary to wave the ban hammer here?
We are basically facing the same issue we face with email spam.
Could you point out an MR that you think is essentially spam? I'm sure that there have been several low-quality LLM-generated MRs by now (some of mine included), but I still believe that every contributor is trying to make GHC better.
I'm not even against firmly rejecting low-quality contributions. But I believe that essentially all contributors are fundamentally well-meaning people who will respond to nudges when being nudged. And that's just what Andreas is achieving with his email and his reviews.
All this talk of banning contributors or banning certain types of contributions is IMHO just creating a hostile atmosphere that is plainly off-putting for current and future contributors.
I also think it's important to keep in mind that most of us are still figuring out how to best work with LLMs. Making mistakes is an important if not essential part of this learning experience. I'm grateful to Andreas that he's willing to point out these mistakes, and I think it's the right way to grow this community.
Thanks! Simon
And no, I still don’t believe there is a right to review. I still hold the position that anyone contributing will need to find a reviewer and that no one feel even remotely obliged to review MRs just because they show up on GitLab.
And I would say that a poor PR is irrespective how it was conceived should be rejected. If the wording is poorly written, superfluous or does not try to hit a high bar, it’s not something anyone should entertain. Auto close. If someone comes to IRC, the mailing list, an in person event, … and tries to make their case for their contribution in an orderly manner, I’m sure there will be plenty of folks who would like to help someone engaged to contribute and support them in crafting a great contribution.
Best, Moritz
On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote:
I'd argue that code or documentation that is so void of meaning to the human reader isn't just low quality, but also violates P3 of the AI policy.
So you shouldn't really by asking these questions here, but simply reject such contributions. They're disrespectful.
What I disagree with is that issue text and comments shall be excluded. Drafting a bug report or an elaborate feature request already constitutes a contribution that may be read by humans years later to understand context and decisions. Diluting this with low quality AI generated text is going to degrade the contribution experience significantly.
Especially now that the industry is changing, juniors are struggling to find jobs and meaning in this field... we should be even more obsessed with the contribution experience than ever before, so that there will still be a future generation of GHC maintainers who cares as deeply about GHC as the current roster does.
On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> wrote:
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Am So 18.10.2026 22:47 schrieb Simon Jakobi via ghc-devs:
I still believe that every contributor is trying to make GHC better.
Trying something is different from actually doing it, and thus the attempt alone is not enough.
I believe that essentially all contributors are fundamentally well-meaning people who will respond to nudges when being nudged.
In my opinion, being well-meaning and responding to nudges is not enough. There is a certain obligation to meet some minimum quality standard when making contributions.
All this talk of banning contributors or banning certain types of contributions is IMHO just creating a hostile atmosphere that is plainly off-putting for current and future contributors.
The atmosphere that has been created by the use of LLMs in GHC development is also off-putting for various contributors.
I also think it's important to keep in mind that most of us are still figuring out how to best work with LLMs.
Yet others have come to the conclusion that it’s best to not use LLMs, at least not for producing code or documentation. All the best, Wolfgang
Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> writes:
Hello Devs,
...
*My plan is to aggressively request improvement of prose during MR review going forward.*
Yes, this seems very sensible.
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.
Absolutely.
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.
For what it's worth, I agree that this is a hill to die on. While I am gradually growing more comfortable with LLM generated code, LLMs are truly awful at producing readable prose. The effort of reading and rewriting Notes and comments produced by an LLM will pay dividends in maintainability in the long run. Cheers, - Ben
On 10/14/2026 1:08 PM CEST Andreas Klebinger via ghc-devs <ghc-devs@haskell.org> wrote:
While reading AI tickets can be exhausting, I'm willing, within reason, to accept them as a fact of live.
I think this is absolutely a bad direction. When discussing a change, we generally link to a ticket. We do this even after the code was merged. It helps us understand the decision-making process around a change, concerns people voiced, and how they were addressed or reasons they weren't. AI making this process "exhausting" is unacceptable. From the current AI policy: "[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution" A person (often a volunteer hoping to help!) should never, ever need to read hallucinations which lead them in the wrong direction, or waste time reading large amounts of nonsense no human has taken responsibility for. This is a violation of the (in my view very tepid) current requirements of contributing to GHC with AI. For many people (particularly professional Haskell devs), reading tickets on GitLab is their _only_ source of information about changes to GHC. Taking a page from Simon's "How to write a great research paper," think of the number of eyeballs for a GHC contribution being something like: - Tickets and discussion - 1,000 readers - Commit messages and Notes - 100 readers - Code - 10 readers - Code, in enough detail to spot slop - 3 readers
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.
Even "polishing" is a low bar. Again, from the policy document: "You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line! It's not enough to think "this looks generally right" and expect a reviewer to then review every line."
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.
I agree with this, and would hope that it would be communicated that not only does the contribution need work, but that the existing contribution was the result of inconsiderate action (to put it bluntly). Cheers, Tom P.S. This phenomenon is precisely why some of us advocate a position of "use LLMs to assist and draft all you like, but actually write the ticket/Notes/code yourself."
"[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution"
This is precisely why I advocate to "embrace the slop", that is, treat LLM-generated content as raw data, as if the content was a log, a crash message, a debug session transcript. But let me start by describing my experience with LLMs and GHC so that my position can be better understood. I'm recently posting many GHC issues with LLM-generated data and, while I hope to over time improve the way I do it, I see that their quality is much better than when I I did not use LLM for two reasons: 1. Before, I was posting huge reproducers and bright minds were spending weeks minimizing them or sometimes they could not. Now LLMs miminize all my reproducers. 2. I have no clue about GHC internals, so I could only guess if my complaint is intended and/or known behaviour, which bugs are already reported in a way that I don't recognize, which defect is just a known difficult trade-off inherent in GHC heuristics biting me occasionally and so not worth a report if I don't have a body of statistical evidence to support a heuristic overhaul proposal. Today LLMs recognize each of these scenarios for me and I'm withdrawing half of my attempted defect reports. As a bonus, when I'm reading the slop to summarize it in a sentence or two at the issues' start, I'm learning GHC internals. I'm learning in particular from the often correct root cause analysis by LLMs and from the often incorrect fix proposals. This is one reason giving me hope my future GHC LLM-assisted contributions will be higher quality. Another is GHC devs' feedback. Yet another is, I hope, LLMs getting better. Back to embracing the slop: I can't "take full responsibility" for what LLM writes, because I'm clueless. It's the same as if I was posting a transcript of a clueless debug session --- I totally can't take responsibility for my working hypotheses. Neither, when I minimize a big performance regression, I can't take responsibility for the guess that the 3% slower minimized repo represents the same mechanism that slowed down my original big program by 30% (which is the only argument why it's worth looking at). What I can take full responsibility for is my user story and the dumb raw data. "This log is from commandline X". "This gdb output is from my program interrupted at Y". "This LLM output is from Z". I hope we can improve our understanding not only what kind of LLM-generated data is helpful, but also which kind of "Z" is most honest and most helpful to all people concerned. Is it mixing LLM-content with human-content? Certainly not for me, because I'm too clueless to correct an LLM and by mixing I'm diluting the attribution and introducing errors. Should Z be the prompt? A summary in my own often misguided words clearly separated from the slop (this is what I do currently)? All the best, Mikolaj
Perhaps I can add my perspective. This thread is largely about LLM generated tickets. Mikolaj in particular has been posting a series of a couple of dozen such tickets -- so many in fact that I started collecting them on a tab of my personal WIP spreadsheet. You can see it here <https://docs.google.com/spreadsheets/d/1o05HVgAnsSjuLNFyDZ78DJPIirw664i7i48g6aHan5w/edit?usp=sharing> (look at the Mikolaj tab). From this I have learned - All of them that I have investigated so far have proved genuine -- they expose genuine shortcomings in GHC. - It's pretty overwhelming, even discouraging, to get so many in a short time. And yet, and yet.... I would rather know than not-know. - The explanations are often long, but I zoom in on the reproducer, and only then refer back to the explanation. As Mikolaj says, these reproducers are far, far, far better than the gigantic reproducers he used to offer. Provided the ticket has a short statement of what is wrong, and a reproducer, I don't mind if there is AI-generated goop to accompany it. Indeed, once I can reproduce it, the goop is often somewhat helpful. - I say "somewhat" because once I have understood the problem, I can often come up with a much crisper summary myself Here's a concrete example <https://gitlab.haskell.org/ghc/ghc/-/work_items/25526#note_705423>, with my summary belo. - It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame. - *The biggest shortcoming is this: I have no idea how important the ticket is*. When all tickets were human generated, I knew that every single one was somewhat important to some human. I don't want to spend time fixing bugs that no one cares about, and I'm 100% against LLM's autonomously submitting tickets. Every ticket must have a human behind it. Meanwhile, I asked Mikolaj to prioritise his flood of tickets, which he has done as you'll see on the spreadsheet. - One way in which the flood can feel exhausting is simply because it exposes so many embarrassing shortcomings in the compiler on which I have lavished so much love and care. How can I have been so stupid in so many different ways? Why is GHC so over-complicated? It is humbling. But in a good way, I think. Finally, while tickets may have a lot of readers, they are ephemeral. What I *really *care about is the code and the Notes in the code. It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets. (There are occasional exceptions.) For the code and Notes I want every line to be human written, or so well studied, audited and revised that it might as well be human written. TL;DR: for me, provided a ticket has a human author who actively cares about, clear signposting and attribution, and a concrete reproducer, I'm pretty relaxed about accompanying slop. Relatedly, let me add that I have also been requesting *LLM reviews* for my MRs, through Simon Jacobi's good offices, and I have been astonished how good they are. They often identify genuine issues with my lovingly crafted MRs, and ones which both I and human reviewers have missed. At the time it's a bit "Oh no, I wanted to land this and now I can't", but again it must be better to know about the bugs than not to know. Again it's a humbling experience. So thus far, I have had a pretty positive experience of LLM-generated bug reports and reviews. But as I say above, I am much, much more cautious about contributions to GHC's code base and documentation. Simon On Thu, 22 Oct 2026 at 21:45, Mikolaj Konarski via ghc-devs < ghc-devs@haskell.org> wrote:
"[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution"
This is precisely why I advocate to "embrace the slop", that is, treat LLM-generated content as raw data, as if the content was a log, a crash message, a debug session transcript. But let me start by describing my experience with LLMs and GHC so that my position can be better understood.
I'm recently posting many GHC issues with LLM-generated data and, while I hope to over time improve the way I do it, I see that their quality is much better than when I I did not use LLM for two reasons:
1. Before, I was posting huge reproducers and bright minds were spending weeks minimizing them or sometimes they could not. Now LLMs miminize all my reproducers.
2. I have no clue about GHC internals, so I could only guess if my complaint is intended and/or known behaviour, which bugs are already reported in a way that I don't recognize, which defect is just a known difficult trade-off inherent in GHC heuristics biting me occasionally and so not worth a report if I don't have a body of statistical evidence to support a heuristic overhaul proposal. Today LLMs recognize each of these scenarios for me and I'm withdrawing half of my attempted defect reports.
As a bonus, when I'm reading the slop to summarize it in a sentence or two at the issues' start, I'm learning GHC internals. I'm learning in particular from the often correct root cause analysis by LLMs and from the often incorrect fix proposals. This is one reason giving me hope my future GHC LLM-assisted contributions will be higher quality. Another is GHC devs' feedback. Yet another is, I hope, LLMs getting better.
Back to embracing the slop: I can't "take full responsibility" for what LLM writes, because I'm clueless. It's the same as if I was posting a transcript of a clueless debug session --- I totally can't take responsibility for my working hypotheses. Neither, when I minimize a big performance regression, I can't take responsibility for the guess that the 3% slower minimized repo represents the same mechanism that slowed down my original big program by 30% (which is the only argument why it's worth looking at).
What I can take full responsibility for is my user story and the dumb raw data. "This log is from commandline X". "This gdb output is from my program interrupted at Y". "This LLM output is from Z".
I hope we can improve our understanding not only what kind of LLM-generated data is helpful, but also which kind of "Z" is most honest and most helpful to all people concerned. Is it mixing LLM-content with human-content? Certainly not for me, because I'm too clueless to correct an LLM and by mixing I'm diluting the attribution and introducing errors. Should Z be the prompt? A summary in my own often misguided words clearly separated from the slop (this is what I do currently)?
All the best, Mikolaj _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Hi, Encouraged by Simon's understanding message, I would like to share my own perspective. I am one of those who have submitted merge requests containing code generated directly by Claude Code. Unfortunately, this action caused some people discomfort. It is natural for a wide range of opinions to emerge during a period of significant change, so I am not surprised that some hold views diametrically opposed to mine. Furthermore, it is certainly not my intention to attack anyone with this message. I intend to follow GHC's development policies, and if I have violated them, I will make the necessary corrections. I maintain code related to networking. Over the past few months, I have received numerous reports of vulnerabilities identified by AI. Initially, I would personally analyze and fix these issues, or carefully review and merge the resulting pull requests. However, the volume eventually exceeded my capacity. As a countermeasure, I decided to use AI to proactively address these vulnerabilities myself, and I began using Claude Code since September 15th. Claude Code uncovered a vast number of vulnerabilities, a revelation that truly shocked me. It became clear to me that the only viable strategy is to run faster than bad guys. Just yesterday, a vulnerability concerning HTTP/3 header compression was disclosed. However, Claude Code had already addressed it in the Haskell "http3" library three weeks prior. While there may be differing opinions on this, I am proud of what was achieved in this instance. https://github.com/kazu-yamamoto/http3/issues/54 My current work involves developing a DNS server in Haskell. For a long time, I struggled with rare, intermittent bugs, specifically, workers stalling and the system exhausting its memory. Suspecting that these were not bugs in the DNS server itself, but rather issues within the GHC runtime, I utilized tools like Claude Code to analyze them. I have previously contributed to the GHC project, specifically regarding the IO Manager. In this recent process, Claude Code identified several bugs within the IO Manager. The migration of GHC development to gitlab raised the barrier to entry for contributors. However, Claude Code helped me understand the proper procedures, enabling me to submit merge requests. It was pointed out that my merge request description, commit messages, and code comments were overly verbose, so I rewrote them all. This was not an issue for me, as I am responsible for the IO Manager. Meanwhile, I have also been struggling with a bug in Haddock. A regression in Haddock has broken the structure of the documentation I manually wrote. I requested a fix multiple times, but as it remained unresolved, I used Claude Code to demonstrate how it could be fixed, though I later trimmed down the verbose explanations I had included. However, I would find it problematic to be held responsible for the code or comments within Haddock. I am not familiar with Haddock's internals, nor do I have the time to learn them. If I am expected to take responsibility for such areas, I will have to cease contributing to anything outside of the IO Manager, as it simply exceeds my capabilities. To date, I have never asked anyone to rewrite AI-generated text sent regarding my own software. I can simply have an AI summarize it, and I also fear that making such a request might discourage others from providing feedback altogether. As a native Japanese speaker, a language with a grammar entirely distinct from English, I find myself constantly grappling with the English used by others in this community. I rely on machine translation and dictionaries just to grasp the details. I am not even entirely confident that this very message has been translated accurately. Using AI to summarize content of issues/MRs for the purpose of understanding it is not significantly different from the methods previously used to understand English. From the perspective of someone who maintains network-related code, which is constantly exposed to external threats, the GHC community strikes me as being quite laid-back regarding the adoption of AI. --Kazu From: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> Subject: Re: Notes/Commit messages/Comments - A new AI discussion
Perhaps I can add my perspective.
This thread is largely about LLM generated tickets. Mikolaj in particular has been posting a series of a couple of dozen such tickets -- so many in fact that I started collecting them on a tab of my personal WIP spreadsheet. You can see it here <https://docs.google.com/spreadsheets/d/1o05HVgAnsSjuLNFyDZ78DJPIirw664i7i48g6aHan5w/edit?usp=sharing> (look at the Mikolaj tab). From this I have learned
- All of them that I have investigated so far have proved genuine -- they expose genuine shortcomings in GHC. - It's pretty overwhelming, even discouraging, to get so many in a short time. And yet, and yet.... I would rather know than not-know. - The explanations are often long, but I zoom in on the reproducer, and only then refer back to the explanation. As Mikolaj says, these reproducers are far, far, far better than the gigantic reproducers he used to offer. Provided the ticket has a short statement of what is wrong, and a reproducer, I don't mind if there is AI-generated goop to accompany it. Indeed, once I can reproduce it, the goop is often somewhat helpful. - I say "somewhat" because once I have understood the problem, I can often come up with a much crisper summary myself Here's a concrete example
<https://gitlab.haskell.org/ghc/ghc/-/work_items/25526#note_705423>, with my summary belo. - It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame. - *The biggest shortcoming is this: I have no idea how important the ticket is*. When all tickets were human generated, I knew that every single one was somewhat important to some human. I don't want to spend time fixing bugs that no one cares about, and I'm 100% against LLM's autonomously submitting tickets. Every ticket must have a human behind it. Meanwhile, I asked Mikolaj to prioritise his flood of tickets, which he has done as you'll see on the spreadsheet. - One way in which the flood can feel exhausting is simply because it exposes so many embarrassing shortcomings in the compiler on which I have lavished so much love and care. How can I have been so stupid in so many different ways? Why is GHC so over-complicated? It is humbling. But in a good way, I think.
Finally, while tickets may have a lot of readers, they are ephemeral. What I *really *care about is the code and the Notes in the code. It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets. (There are occasional exceptions.) For the code and Notes I want every line to be human written, or so well studied, audited and revised that it might as well be human written.
TL;DR: for me, provided a ticket has a human author who actively cares about, clear signposting and attribution, and a concrete reproducer, I'm pretty relaxed about accompanying slop.
Relatedly, let me add that I have also been requesting *LLM reviews* for my MRs, through Simon Jacobi's good offices, and I have been astonished how good they are. They often identify genuine issues with my lovingly crafted MRs, and ones which both I and human reviewers have missed. At the time it's a bit "Oh no, I wanted to land this and now I can't", but again it must be better to know about the bugs than not to know. Again it's a humbling experience.
So thus far, I have had a pretty positive experience of LLM-generated bug reports and reviews. But as I say above, I am much, much more cautious about contributions to GHC's code base and documentation.
Simon
On Thu, 22 Oct 2026 at 21:45, Mikolaj Konarski via ghc-devs < ghc-devs@haskell.org> wrote:
"[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution"
This is precisely why I advocate to "embrace the slop", that is, treat LLM-generated content as raw data, as if the content was a log, a crash message, a debug session transcript. But let me start by describing my experience with LLMs and GHC so that my position can be better understood.
I'm recently posting many GHC issues with LLM-generated data and, while I hope to over time improve the way I do it, I see that their quality is much better than when I I did not use LLM for two reasons:
1. Before, I was posting huge reproducers and bright minds were spending weeks minimizing them or sometimes they could not. Now LLMs miminize all my reproducers.
2. I have no clue about GHC internals, so I could only guess if my complaint is intended and/or known behaviour, which bugs are already reported in a way that I don't recognize, which defect is just a known difficult trade-off inherent in GHC heuristics biting me occasionally and so not worth a report if I don't have a body of statistical evidence to support a heuristic overhaul proposal. Today LLMs recognize each of these scenarios for me and I'm withdrawing half of my attempted defect reports.
As a bonus, when I'm reading the slop to summarize it in a sentence or two at the issues' start, I'm learning GHC internals. I'm learning in particular from the often correct root cause analysis by LLMs and from the often incorrect fix proposals. This is one reason giving me hope my future GHC LLM-assisted contributions will be higher quality. Another is GHC devs' feedback. Yet another is, I hope, LLMs getting better.
Back to embracing the slop: I can't "take full responsibility" for what LLM writes, because I'm clueless. It's the same as if I was posting a transcript of a clueless debug session --- I totally can't take responsibility for my working hypotheses. Neither, when I minimize a big performance regression, I can't take responsibility for the guess that the 3% slower minimized repo represents the same mechanism that slowed down my original big program by 30% (which is the only argument why it's worth looking at).
What I can take full responsibility for is my user story and the dumb raw data. "This log is from commandline X". "This gdb output is from my program interrupted at Y". "This LLM output is from Z".
I hope we can improve our understanding not only what kind of LLM-generated data is helpful, but also which kind of "Z" is most honest and most helpful to all people concerned. Is it mixing LLM-content with human-content? Certainly not for me, because I'm too clueless to correct an LLM and by mixing I'm diluting the attribution and introducing errors. Should Z be the prompt? A summary in my own often misguided words clearly separated from the slop (this is what I do currently)?
All the best, Mikolaj _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Claude Code uncovered a vast number of vulnerabilities, a revelation that truly shocked me.
Maybe this has some overlap with my comment that LLMs are astonishingly good at exposing our own shortcomings, and however good that may be, it has an emotional cost! However, I would find it problematic to be held responsible for the code or
comments within Haddock.
You can't be expected to do that. I am still hopeful that there are some human beings who care enough about Haddock to fix it. But your implicit question is: what if there is a subsystem that literally no one understands and no one wants to be responsible for? In the old days we'd be totally stuck. Now there is the possibility of using an LLM to directly maintain the code. Now no one understands it even more -- but perhaps that is not worse than the status quo. I hope we aren't in that position. But it may yet happen for bits of the Haskell ecosystem. I maintain code related to networking. Over the past few months, I have
received numerous reports of vulnerabilities identified by AI. Initially, I would personally analyze and fix these issues, or carefully review and merge the resulting pull requests. However, the volume eventually exceeded my capacity.
Can I ask: is this in a library for which you are responsible, or is it in GHC or its runtime? You are implicitly raising another interesting question. Suppose there is a system X which some group H of humans (in this case, you) *do *care about, and know intimately. And suppose there is a stream of bug reports that are both urgent, and that collectively exceed H's capacity to deal with. What is better? To leave them unfixed, or to get an LLM to assist, but risk introducing code permanently into X that even H doesn't quite understand? That's a pretty hard question. For GHC code-optimisation bugs, I leave them un-fixed, and get around them in due course. A missing code optimisation is not critical. For critical security vulnerabilities it's harder. And by discovering so many, so quickly, LLMs have raised the stakes considerably. I would say that it's up to H to make the judgement. H knows about X; they know about the importance or otherwise of the issue; they can review the proposed code patch to filter out egregiously complicated or incomprehensible fixes; and in any case it's not really an either/or choice, it's a continuum. It's a judgement call and I would not want to impose a blanket black-and-white judgement from outside. So, Kazu, in code which you love and care for and are solely responsible for, I'd be content for you to make a judgement. If others are co-responsible, you should obviously consult them. And you should be (and I'm sure you are) alive to the cost of building up technical debt for our successors. Bryan is right to say that things are moving fast. Claude is identifying bugs in my MRs that require deep insight. I'm boggled by how clever it is. And it's getting better. Simon On Fri, 23 Oct 2026 at 02:33, Kazu Yamamoto (山本和彦) via ghc-devs < ghc-devs@haskell.org> wrote:
Hi,
Encouraged by Simon's understanding message, I would like to share my own perspective. I am one of those who have submitted merge requests containing code generated directly by Claude Code. Unfortunately, this action caused some people discomfort. It is natural for a wide range of opinions to emerge during a period of significant change, so I am not surprised that some hold views diametrically opposed to mine. Furthermore, it is certainly not my intention to attack anyone with this message. I intend to follow GHC's development policies, and if I have violated them, I will make the necessary corrections.
I maintain code related to networking. Over the past few months, I have received numerous reports of vulnerabilities identified by AI. Initially, I would personally analyze and fix these issues, or carefully review and merge the resulting pull requests. However, the volume eventually exceeded my capacity.
As a countermeasure, I decided to use AI to proactively address these vulnerabilities myself, and I began using Claude Code since September 15th. Claude Code uncovered a vast number of vulnerabilities, a revelation that truly shocked me. It became clear to me that the only viable strategy is to run faster than bad guys. Just yesterday, a vulnerability concerning HTTP/3 header compression was disclosed. However, Claude Code had already addressed it in the Haskell "http3" library three weeks prior. While there may be differing opinions on this, I am proud of what was achieved in this instance.
https://github.com/kazu-yamamoto/http3/issues/54
My current work involves developing a DNS server in Haskell. For a long time, I struggled with rare, intermittent bugs, specifically, workers stalling and the system exhausting its memory. Suspecting that these were not bugs in the DNS server itself, but rather issues within the GHC runtime, I utilized tools like Claude Code to analyze them.
I have previously contributed to the GHC project, specifically regarding the IO Manager. In this recent process, Claude Code identified several bugs within the IO Manager. The migration of GHC development to gitlab raised the barrier to entry for contributors. However, Claude Code helped me understand the proper procedures, enabling me to submit merge requests. It was pointed out that my merge request description, commit messages, and code comments were overly verbose, so I rewrote them all. This was not an issue for me, as I am responsible for the IO Manager.
Meanwhile, I have also been struggling with a bug in Haddock. A regression in Haddock has broken the structure of the documentation I manually wrote. I requested a fix multiple times, but as it remained unresolved, I used Claude Code to demonstrate how it could be fixed, though I later trimmed down the verbose explanations I had included.
However, I would find it problematic to be held responsible for the code or comments within Haddock. I am not familiar with Haddock's internals, nor do I have the time to learn them. If I am expected to take responsibility for such areas, I will have to cease contributing to anything outside of the IO Manager, as it simply exceeds my capabilities.
To date, I have never asked anyone to rewrite AI-generated text sent regarding my own software. I can simply have an AI summarize it, and I also fear that making such a request might discourage others from providing feedback altogether.
As a native Japanese speaker, a language with a grammar entirely distinct from English, I find myself constantly grappling with the English used by others in this community. I rely on machine translation and dictionaries just to grasp the details. I am not even entirely confident that this very message has been translated accurately. Using AI to summarize content of issues/MRs for the purpose of understanding it is not significantly different from the methods previously used to understand English.
From the perspective of someone who maintains network-related code, which is constantly exposed to external threats, the GHC community strikes me as being quite laid-back regarding the adoption of AI.
--Kazu
From: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> Subject: Re: Notes/Commit messages/Comments - A new AI discussion
Perhaps I can add my perspective.
This thread is largely about LLM generated tickets. Mikolaj in particular has been posting a series of a couple of dozen such tickets -- so many in fact that I started collecting them on a tab of my personal WIP spreadsheet. You can see it here < https://docs.google.com/spreadsheets/d/1o05HVgAnsSjuLNFyDZ78DJPIirw664i7i48g...
(look at the Mikolaj tab). From this I have learned
- All of them that I have investigated so far have proved genuine -- they expose genuine shortcomings in GHC. - It's pretty overwhelming, even discouraging, to get so many in a short time. And yet, and yet.... I would rather know than not-know. - The explanations are often long, but I zoom in on the reproducer, and only then refer back to the explanation. As Mikolaj says, these reproducers are far, far, far better than the gigantic reproducers he used to offer. Provided the ticket has a short statement of what is wrong, and a reproducer, I don't mind if there is AI-generated goop to accompany it. Indeed, once I can reproduce it, the goop is often somewhat helpful. - I say "somewhat" because once I have understood the problem, I can often come up with a much crisper summary myself Here's a concrete example
<https://gitlab.haskell.org/ghc/ghc/-/work_items/25526#note_705423>, with my summary belo. - It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame. - *The biggest shortcoming is this: I have no idea how important the ticket is*. When all tickets were human generated, I knew that every single one was somewhat important to some human. I don't want to spend time fixing bugs that no one cares about, and I'm 100% against LLM's autonomously submitting tickets. Every ticket must have a human behind it. Meanwhile, I asked Mikolaj to prioritise his flood of tickets, which he has done as you'll see on the spreadsheet. - One way in which the flood can feel exhausting is simply because it exposes so many embarrassing shortcomings in the compiler on which I have lavished so much love and care. How can I have been so stupid in so many different ways? Why is GHC so over-complicated? It is humbling. But in a good way, I think.
Finally, while tickets may have a lot of readers, they are ephemeral. What I *really *care about is the code and the Notes in the code. It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets. (There are occasional exceptions.) For the code and Notes I want every line to be human written, or so well studied, audited and revised that it might as well be human written.
TL;DR: for me, provided a ticket has a human author who actively cares about, clear signposting and attribution, and a concrete reproducer, I'm pretty relaxed about accompanying slop.
Relatedly, let me add that I have also been requesting *LLM reviews* for my MRs, through Simon Jacobi's good offices, and I have been astonished how good they are. They often identify genuine issues with my lovingly crafted MRs, and ones which both I and human reviewers have missed. At the time it's a bit "Oh no, I wanted to land this and now I can't", but again it must be better to know about the bugs than not to know. Again it's a humbling experience.
So thus far, I have had a pretty positive experience of LLM-generated bug reports and reviews. But as I say above, I am much, much more cautious about contributions to GHC's code base and documentation.
Simon
On Thu, 22 Oct 2026 at 21:45, Mikolaj Konarski via ghc-devs < ghc-devs@haskell.org> wrote:
"[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution"
This is precisely why I advocate to "embrace the slop", that is, treat LLM-generated content as raw data, as if the content was a log, a crash message, a debug session transcript. But let me start by describing my experience with LLMs and GHC so that my position can be better understood.
I'm recently posting many GHC issues with LLM-generated data and, while I hope to over time improve the way I do it, I see that their quality is much better than when I I did not use LLM for two reasons:
1. Before, I was posting huge reproducers and bright minds were spending weeks minimizing them or sometimes they could not. Now LLMs miminize all my reproducers.
2. I have no clue about GHC internals, so I could only guess if my complaint is intended and/or known behaviour, which bugs are already reported in a way that I don't recognize, which defect is just a known difficult trade-off inherent in GHC heuristics biting me occasionally and so not worth a report if I don't have a body of statistical evidence to support a heuristic overhaul proposal. Today LLMs recognize each of these scenarios for me and I'm withdrawing half of my attempted defect reports.
As a bonus, when I'm reading the slop to summarize it in a sentence or two at the issues' start, I'm learning GHC internals. I'm learning in particular from the often correct root cause analysis by LLMs and from the often incorrect fix proposals. This is one reason giving me hope my future GHC LLM-assisted contributions will be higher quality. Another is GHC devs' feedback. Yet another is, I hope, LLMs getting better.
Back to embracing the slop: I can't "take full responsibility" for what LLM writes, because I'm clueless. It's the same as if I was posting a transcript of a clueless debug session --- I totally can't take responsibility for my working hypotheses. Neither, when I minimize a big performance regression, I can't take responsibility for the guess that the 3% slower minimized repo represents the same mechanism that slowed down my original big program by 30% (which is the only argument why it's worth looking at).
What I can take full responsibility for is my user story and the dumb raw data. "This log is from commandline X". "This gdb output is from my program interrupted at Y". "This LLM output is from Z".
I hope we can improve our understanding not only what kind of LLM-generated data is helpful, but also which kind of "Z" is most honest and most helpful to all people concerned. Is it mixing LLM-content with human-content? Certainly not for me, because I'm too clueless to correct an LLM and by mixing I'm diluting the attribution and introducing errors. Should Z be the prompt? A summary in my own often misguided words clearly separated from the slop (this is what I do currently)?
All the best, Mikolaj _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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.
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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Teo, I agree with a lot of what you are saying. If GHC devs, including you, based on their experience with my and other tickets recommend that I cut my slop to just a repro, I will gladly adhere to that. If they decide a single other LLM-generated signal from my tickets is also worth preserving and ideally offer a keyword to mark this other particular kind of slop, I will also do that eagerly. I think this is the way forward. One disagreement: how about proofs of concept? Does it have a value as in "it's probably badly done and nobody is expected to look at it, but it proves this may be done"? One use of this is putting pressure on devs, because if even a bot could do that, why can't you? But a more constructive use is triaging the upfront risk of putting effort into something that can't be done without an absurd effort or code bloat. I agree this falls under "a dev with LLM can do that trivially as well, so why do you paste slop", but we do paste logs that devs could reproduce with no or little effort. It's courtesy. On Fri, Oct 23, 2026 at 12:13 PM Teo Camarasu via ghc-devs <ghc-devs@haskell.org> wrote:
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?
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. 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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Am Fr 23.10.2026 09:18 schrieb Simon Peyton Jones via ghc-devs:
But your implicit question is: what if there is a subsystem that literally no one understands and no one wants to be responsible for? In the old days we’d be totally stuck. Now there is the possibility of using an LLM to directly maintain the code. Now no one understands it even more – but perhaps that is not worse than the status quo.
This is a bit like saying “What if I don’t have the strength to do certain tasks anymore? In the old days, I’d be totally stuck. Now there is the possibility to use some fancy new drug to make me energetic. Next day I’ll always be even weaker than in the beginning, but I can take a higher dose. Perhaps that is not worse than the status quo.”
Claude is identifying bugs in my MRs that require deep insight. I’m boggled by how clever it is. And it’s getting better.
To reiterate an important point: LLM systems don’t have insight and aren’t clever. If they find something, it is only by sucking it out from past utterances of clever humans using ridiculous amounts of energy. There’s likely a limit to what can be done with that. All the best, Wolfgang
On Fri, Oct 23, 2026 at 01:18:44PM +0300, Wolfgang Jeltsch via ghc-devs wrote:
To reiterate an important point: LLM systems don’t have insight and aren’t clever. If they find something, it is only by sucking it out from past utterances of clever humans using ridiculous amounts of energy. There’s likely a limit to what can be done with that.
I don't agree with the framing, but let's say that for whatever reason your conclusion is correct: there’s likely a limit to what can be done to improve LLMs. So what? What are the consequences for GHC development? Tom
Am Fr 23.10.2026 13:30 schrieb Tom Ellis via ghc-devs:
On Fri, Oct 23, 2026 at 01:18:44PM +0300, Wolfgang Jeltsch wrote:
To reiterate an important point: LLM systems don’t have insight and aren’t clever. If they find something, it is only by sucking it out from past utterances of clever humans using ridiculous amounts of energy. There’s likely a limit to what can be done with that.
I don't agree with the framing, but let's say that for whatever reason your conclusion is correct: there’s likely a limit to what can be done to improve LLMs. So what? What are the consequences for GHC development?
It may not be wise to overly rely on LLMs, lose skills this way, and finally have to do things by hand, because reasonably priced LLMs cannot meet our demands anymore. All the best, Wolfgang
Hi! It seems that there is a general story shining through what Kazu wrote: 1. We accidentally introduce lots of security issues into our software. 2. We don’t find these security issues but use LLMs to find them. 3. We cannot fix these security issues but use LLMs to fix them. 4. We don’t understand our codebases but use LLMs to make changes. 5. We cannot take responsibility for the changes made by LLMs but hope that they don’t introduce new issues. 6. We include LLM-generated text into our documentation that we don’t understand but let LLMs explain its meaning to us. This seems like an absolutely worrying state of affairs. I wonder why we got there: • Did we care too little about design? • Did we introduce too many features? • Did we care too much about development speed and too litle about quality? • Did we pay too little attention to detail? Apparently, the effects of multiple deficits have accumulated over the years, and now we use LLMs to somehow handle the outcome. This may well make our codebases even worse and at the same time lessen our abilities to construct quality software. All the best, Wolfgang Am Fr 23.10.2026 10:33 schrieb Kazu Yamamoto (山本和彦) via ghc-devs:
Hi,
Encouraged by Simon's understanding message, I would like to share my own perspective. I am one of those who have submitted merge requests containing code generated directly by Claude Code. Unfortunately, this action caused some people discomfort. It is natural for a wide range of opinions to emerge during a period of significant change, so I am not surprised that some hold views diametrically opposed to mine. Furthermore, it is certainly not my intention to attack anyone with this message. I intend to follow GHC's development policies, and if I have violated them, I will make the necessary corrections.
I maintain code related to networking. Over the past few months, I have received numerous reports of vulnerabilities identified by AI. Initially, I would personally analyze and fix these issues, or carefully review and merge the resulting pull requests. However, the volume eventually exceeded my capacity.
As a countermeasure, I decided to use AI to proactively address these vulnerabilities myself, and I began using Claude Code since September 15th. Claude Code uncovered a vast number of vulnerabilities, a revelation that truly shocked me. It became clear to me that the only viable strategy is to run faster than bad guys. Just yesterday, a vulnerability concerning HTTP/3 header compression was disclosed. However, Claude Code had already addressed it in the Haskell "http3" library three weeks prior. While there may be differing opinions on this, I am proud of what was achieved in this instance.
https://github.com/kazu-yamamoto/http3/issues/54
My current work involves developing a DNS server in Haskell. For a long time, I struggled with rare, intermittent bugs, specifically, workers stalling and the system exhausting its memory. Suspecting that these were not bugs in the DNS server itself, but rather issues within the GHC runtime, I utilized tools like Claude Code to analyze them.
I have previously contributed to the GHC project, specifically regarding the IO Manager. In this recent process, Claude Code identified several bugs within the IO Manager. The migration of GHC development to gitlab raised the barrier to entry for contributors. However, Claude Code helped me understand the proper procedures, enabling me to submit merge requests. It was pointed out that my merge request description, commit messages, and code comments were overly verbose, so I rewrote them all. This was not an issue for me, as I am responsible for the IO Manager.
Meanwhile, I have also been struggling with a bug in Haddock. A regression in Haddock has broken the structure of the documentation I manually wrote. I requested a fix multiple times, but as it remained unresolved, I used Claude Code to demonstrate how it could be fixed, though I later trimmed down the verbose explanations I had included.
However, I would find it problematic to be held responsible for the code or comments within Haddock. I am not familiar with Haddock's internals, nor do I have the time to learn them. If I am expected to take responsibility for such areas, I will have to cease contributing to anything outside of the IO Manager, as it simply exceeds my capabilities.
To date, I have never asked anyone to rewrite AI-generated text sent regarding my own software. I can simply have an AI summarize it, and I also fear that making such a request might discourage others from providing feedback altogether.
As a native Japanese speaker, a language with a grammar entirely distinct from English, I find myself constantly grappling with the English used by others in this community. I rely on machine translation and dictionaries just to grasp the details. I am not even entirely confident that this very message has been translated accurately. Using AI to summarize content of issues/MRs for the purpose of understanding it is not significantly different from the methods previously used to understand English.
From the perspective of someone who maintains network-related code, which is constantly exposed to external threats, the GHC community strikes me as being quite laid-back regarding the adoption of AI.
--Kazu
From: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> Subject: Re: Notes/Commit messages/Comments - A new AI discussion
Perhaps I can add my perspective.
This thread is largely about LLM generated tickets. Mikolaj in particular has been posting a series of a couple of dozen such tickets -- so many in fact that I started collecting them on a tab of my personal WIP spreadsheet. You can see it here <https://docs.google.com/spreadsheets/d/1o05HVgAnsSjuLNFyDZ78DJPIirw664i7i48g6aHan5w/edit?usp=sharing> (look at the Mikolaj tab). From this I have learned
- All of them that I have investigated so far have proved genuine -- they expose genuine shortcomings in GHC. - It's pretty overwhelming, even discouraging, to get so many in a short time. And yet, and yet.... I would rather know than not-know. - The explanations are often long, but I zoom in on the reproducer, and only then refer back to the explanation. As Mikolaj says, these reproducers are far, far, far better than the gigantic reproducers he used to offer. Provided the ticket has a short statement of what is wrong, and a reproducer, I don't mind if there is AI-generated goop to accompany it. Indeed, once I can reproduce it, the goop is often somewhat helpful. - I say "somewhat" because once I have understood the problem, I can often come up with a much crisper summary myself Here's a concrete example <https://gitlab.haskell.org/ghc/ghc/-/work_items/25526#note_705423>, with my summary belo. - It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame. - *The biggest shortcoming is this: I have no idea how important the ticket is*. When all tickets were human generated, I knew that every single one was somewhat important to some human. I don't want to spend time fixing bugs that no one cares about, and I'm 100% against LLM's autonomously submitting tickets. Every ticket must have a human behind it. Meanwhile, I asked Mikolaj to prioritise his flood of tickets, which he has done as you'll see on the spreadsheet. - One way in which the flood can feel exhausting is simply because it exposes so many embarrassing shortcomings in the compiler on which I have lavished so much love and care. How can I have been so stupid in so many different ways? Why is GHC so over-complicated? It is humbling. But in a good way, I think.
Finally, while tickets may have a lot of readers, they are ephemeral. What I *really *care about is the code and the Notes in the code. It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets. (There are occasional exceptions.) For the code and Notes I want every line to be human written, or so well studied, audited and revised that it might as well be human written.
TL;DR: for me, provided a ticket has a human author who actively cares about, clear signposting and attribution, and a concrete reproducer, I'm pretty relaxed about accompanying slop.
Relatedly, let me add that I have also been requesting *LLM reviews* for my MRs, through Simon Jacobi's good offices, and I have been astonished how good they are. They often identify genuine issues with my lovingly crafted MRs, and ones which both I and human reviewers have missed. At the time it's a bit "Oh no, I wanted to land this and now I can't", but again it must be better to know about the bugs than not to know. Again it's a humbling experience.
So thus far, I have had a pretty positive experience of LLM-generated bug reports and reviews. But as I say above, I am much, much more cautious about contributions to GHC's code base and documentation.
Simon
On Thu, 22 Oct 2026 at 21:45, Mikolaj Konarski via ghc-devs < ghc-devs@haskell.org> wrote:
"[E]very contribution must have an identifiable human author (or authors), who takes full responsibility for their entire contribution"
This is precisely why I advocate to "embrace the slop", that is, treat LLM-generated content as raw data, as if the content was a log, a crash message, a debug session transcript. But let me start by describing my experience with LLMs and GHC so that my position can be better understood.
I'm recently posting many GHC issues with LLM-generated data and, while I hope to over time improve the way I do it, I see that their quality is much better than when I I did not use LLM for two reasons:
1. Before, I was posting huge reproducers and bright minds were spending weeks minimizing them or sometimes they could not. Now LLMs miminize all my reproducers.
2. I have no clue about GHC internals, so I could only guess if my complaint is intended and/or known behaviour, which bugs are already reported in a way that I don't recognize, which defect is just a known difficult trade-off inherent in GHC heuristics biting me occasionally and so not worth a report if I don't have a body of statistical evidence to support a heuristic overhaul proposal. Today LLMs recognize each of these scenarios for me and I'm withdrawing half of my attempted defect reports.
As a bonus, when I'm reading the slop to summarize it in a sentence or two at the issues' start, I'm learning GHC internals. I'm learning in particular from the often correct root cause analysis by LLMs and from the often incorrect fix proposals. This is one reason giving me hope my future GHC LLM-assisted contributions will be higher quality. Another is GHC devs' feedback. Yet another is, I hope, LLMs getting better.
Back to embracing the slop: I can't "take full responsibility" for what LLM writes, because I'm clueless. It's the same as if I was posting a transcript of a clueless debug session --- I totally can't take responsibility for my working hypotheses. Neither, when I minimize a big performance regression, I can't take responsibility for the guess that the 3% slower minimized repo represents the same mechanism that slowed down my original big program by 30% (which is the only argument why it's worth looking at).
What I can take full responsibility for is my user story and the dumb raw data. "This log is from commandline X". "This gdb output is from my program interrupted at Y". "This LLM output is from Z".
I hope we can improve our understanding not only what kind of LLM-generated data is helpful, but also which kind of "Z" is most honest and most helpful to all people concerned. Is it mixing LLM-content with human-content? Certainly not for me, because I'm too clueless to correct an LLM and by mixing I'm diluting the attribution and introducing errors. Should Z be the prompt? A summary in my own often misguided words clearly separated from the slop (this is what I do currently)?
All the best, Mikolaj _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On 10/23/2026 12:58 PM CEST Wolfgang Jeltsch via ghc-devs <ghc-devs@haskell.org> wrote:
Hi!
It seems that there is a general story shining through what Kazu wrote:
1. We accidentally introduce lots of security issues into our software.
2. We don’t find these security issues but use LLMs to find them.
3. We cannot fix these security issues but use LLMs to fix them.
4. We don’t understand our codebases but use LLMs to make changes.
5. We cannot take responsibility for the changes made by LLMs but hope that they don’t introduce new issues.
6. We include LLM-generated text into our documentation that we don’t understand but let LLMs explain its meaning to us.
This seems like an absolutely worrying state of affairs. I wonder why we got there:
• Did we care too little about design?
• Did we introduce too many features?
• Did we care too much about development speed and too litle about quality?
• Did we pay too little attention to detail?
I think it's the same old open source story: many, many people use Kazu's software for mission-critical work, but very few people have contributed back to its development. I know of many private companies that could really be in trouble if Kazu's code had security flaws, yet when critical bugs are discovered, I'm not aware of much industrial urgency to fix them. The assumption is that Kazu or another developer (or an LLM) will fix them for free. Maybe we need to think about ways to support the work of comprehending these vital but sometimes-boring (sorry, Kazu! :) ) libraries. I don't necessarily mean in terms of money, but to fix the problem that the number of people dependent on a library is so much larger than the number who understand enough to fix it. - Tom
I'm afraid this is going to get worse. In the age of LLMs, understanding something is not the priority anymore. Productivity, not being "blocked" and quick drive-by contributions are the new norm. The technical leadership committee could absolutely fund the work of essential library maintainers like Kazu. But as you say, the solution is to increase institutional knowledge and inspire people to take it slow and understand something deeply. I'm not quite sure how... a bounty program may in fact attract more slop coders than interested long term maintainers. If you have ideas, please reach out: technical-leadership@haskell.foundation Sorry for the OT. On October 23, 2026 3:50:45 PM UTC, amindfv--- via ghc-devs <ghc-devs@haskell.org> wrote:
On 10/23/2026 12:58 PM CEST Wolfgang Jeltsch via ghc-devs <ghc-devs@haskell.org> wrote:
Hi!
It seems that there is a general story shining through what Kazu wrote:
1. We accidentally introduce lots of security issues into our software.
2. We don’t find these security issues but use LLMs to find them.
3. We cannot fix these security issues but use LLMs to fix them.
4. We don’t understand our codebases but use LLMs to make changes.
5. We cannot take responsibility for the changes made by LLMs but hope that they don’t introduce new issues.
6. We include LLM-generated text into our documentation that we don’t understand but let LLMs explain its meaning to us.
This seems like an absolutely worrying state of affairs. I wonder why we got there:
• Did we care too little about design?
• Did we introduce too many features?
• Did we care too much about development speed and too litle about quality?
• Did we pay too little attention to detail?
I think it's the same old open source story: many, many people use Kazu's software for mission-critical work, but very few people have contributed back to its development. I know of many private companies that could really be in trouble if Kazu's code had security flaws, yet when critical bugs are discovered, I'm not aware of much industrial urgency to fix them. The assumption is that Kazu or another developer (or an LLM) will fix them for free.
Maybe we need to think about ways to support the work of comprehending these vital but sometimes-boring (sorry, Kazu! :) ) libraries. I don't necessarily mean in terms of money, but to fix the problem that the number of people dependent on a library is so much larger than the number who understand enough to fix it.
- Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
This thread is somewhat timely, as I've just pushed up https://gitlab.haskell.org/ghc/ghc/-/work_items/28029, a LLM built fix to a uninitialised memory access issue in the WASM backend (I think). I ended up spending a couple of working days on it, rejecting an RTS only solution because I was pretty sure there was a problem in the code generator also (as the LLM had pointed out it only occurred in certain optimisation levels). If also directed it to write a variety of test cases in the draft-MR that it can. But I totally get what people are saying about the LLM generated prose in the comments, they are a bit painful to read. I would generally use the word that rhymes with banker to describe someone who wrote like that in real life. But the fact is, I haven't got either the time or the expertise to do much more with this. I haven't worked on GHC internals, and whilst I try to take the time to contribute back to the Haskell ecosystem so it remains and grows as a viable language in industry, I'm also trying to encourage my employer to continue to make the unusual decision of paying someone to keep and extend a Haskell system in production. Going off on weeks/months long study sessions to do proper study into how GHC works is not practical for me if I want to keep getting paid to write Haskell (and if I want my job to exist for others in the future as well). So the practical options are either a slop issue/draft-MR is submitted, or just keep it to myself. I don't expect this to be merged in its current state or even at all, I get that. But I still feel an AI slop issue with a reproducer for a bug is better than none at all. I think the guidelines as they are written are fine. There is the escape hatch of a draft-MR, to avoid the "understanding every line" requirement, which I have used. And I think it's reasonable to need to attribute AI usage. Unless you want to change the guidelines to just outright say NO to AI generated bug reports. But if you're going to do that, be honest and say "if an LLM finds a bug report and you can't explain it or write a fix yourself, run your own private fork and don't tell us about it because we don't want to know". If you don't want to go that way, sloppy issues/MRs are just going to happen because people are going to run into these issues more often, even when they're not looking for them (as in my case). The only difference now is that whilst previously I may have just used a workaround, or maybe just made a vague report "I think something is broke here but I'm not sure what/why", now you've got a draft-MR with 2 commits, the first with test cases that fail and the second with an AI slop fix with test cases that pass. Surely that's a better state of affairs? There's no obligation to put this slop straight into the codebase so I don't see how there's a downside of the current AI contribution policy. On Sat, Oct 24, 2026 at 11:01 AM Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
I'm afraid this is going to get worse.
In the age of LLMs, understanding something is not the priority anymore. Productivity, not being "blocked" and quick drive-by contributions are the new norm.
The technical leadership committee could absolutely fund the work of essential library maintainers like Kazu. But as you say, the solution is to increase institutional knowledge and inspire people to take it slow and understand something deeply. I'm not quite sure how... a bounty program may in fact attract more slop coders than interested long term maintainers.
If you have ideas, please reach out: technical-leadership@haskell.foundation
Sorry for the OT.
On October 23, 2026 3:50:45 PM UTC, amindfv--- via ghc-devs < ghc-devs@haskell.org> wrote:
On 10/23/2026 12:58 PM CEST Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Hi!
It seems that there is a general story shining through what Kazu wrote:
1. We accidentally introduce lots of security issues into our software.
2. We don’t find these security issues but use LLMs to find them.
3. We cannot fix these security issues but use LLMs to fix them.
4. We don’t understand our codebases but use LLMs to make changes.
5. We cannot take responsibility for the changes made by LLMs but hope that they don’t introduce new issues.
6. We include LLM-generated text into our documentation that we don’t understand but let LLMs explain its meaning to us.
This seems like an absolutely worrying state of affairs. I wonder why we got there:
• Did we care too little about design?
• Did we introduce too many features?
• Did we care too much about development speed and too litle about quality?
• Did we pay too little attention to detail?
I think it's the same old open source story: many, many people use Kazu's software for mission-critical work, but very few people have contributed back to its development. I know of many private companies that could really be in trouble if Kazu's code had security flaws, yet when critical bugs are discovered, I'm not aware of much industrial urgency to fix them. The assumption is that Kazu or another developer (or an LLM) will fix them for free.
Maybe we need to think about ways to support the work of comprehending these vital but sometimes-boring (sorry, Kazu! :) ) libraries. I don't necessarily mean in terms of money, but to fix the problem that the number of people dependent on a library is so much larger than the number who understand enough to fix it.
- Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Fri, Oct 23, 2026 at 05:50:45PM +0200, amindfv--- via ghc-devs wrote:
I think it's the same old open source story: many, many people use Kazu's software for mission-critical work, but very few people have contributed back to its development. I know of many private companies that could really be in trouble if Kazu's code had security flaws, yet when critical bugs are discovered, I'm not aware of much industrial urgency to fix them. The assumption is that Kazu or another developer (or an LLM) will fix them for free.
I've been one of the intermittent contributors to and reviewers of Kazu's work on, e.g., "crypton", "dns", "iproute", "network" and "tls". Most recently I've reviewed some of Kazu's substantially Claude-assisted work on "crypton". The involvement of an LLM in that effort did not get in the way of review, and the proposed changes were timely and important. I, for one, am glad that with Claude's assistance Kazu was able to take on and complete some more ambitious projects. Yes, one should ideally find meaningful independent review for such work, and to avoid merging code that is unclear (frustrates adequate review). -- Viktor. 🇺🇦 Слава Україні!
It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets.
I strongly disagree with this. Tickets are the main artifact for me to interact with GHC. That includes 15 years old tickets that are still unsolved today (there are plenty). GHC tickets are referenced in the GHC codebase itself, in cabal and all sorts of other places. I think you're looking at it from a "I'm a core GHC developer" perspective only. And for those your assessment might be true. But there's a large audience for whom tickets is the main source to understand what has been done and is still missing.
It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame
This is what we call the meat proxy phenomenon: https://meatproxy.me/ The bug report is still valuable, but the "I asked an LLM..." is not, unless: * the prompting was so complicated or time intensive that it's hard to reproduce (well, you can share web prompts) * the token spent was very high * there was significant review/judgement involved (doesn't seem so) No one is complaining about people using AI to find reproducers. But even here that's something a developer may as well just do themselves if all it took was "here's a GHC ticket, try to find a minimal reproducer".
I agree that tickets are important for code archeology. GHC seems to think so, too. I recall the GHC project going through great difficulty to migrate to a git forge while preserving ticket numbers, so that all the important comments and Notes that point to tickets wouldn't lose their context. :) I really like Mikolaj's framing of slop-as-log dumps. That's pretty insightful. Sure, you can generate a log dump yourself, given the right setup and instructions. And I've spent a lot of time staring at logs that are mostly useless. Writing good logs is hard for many reasons; the result is that logs are usually, you know, sloppy. So just like unfiltered LLM content, logs are voluminous and low-signal.[1] Nonetheless, attaching e.g. a 1.2MB log dump on a ticket is still generally considered useful. But if someone were to come by, open a cryptic ticket and just paste in the log dump, I'm not sure I'd have the patience to figure out what is being asked. So, as long as LLMs generate sloppy descriptions[2], I think it's wise to recommend putting a human in charge of writing tickets as well as comments and Notes. Mikolaj's approach seems like a good one. -Bryan [1]: LLMs are *very good* at trawling through messy logs and picking out the important messages. Another parallel between log slop and LLM slop... [2]: "As long as LLMs do X" is a pretty short timeframe. I wonder if ticket slop will even be a concern this time next year. On Fri, 23 Oct 2026 at 05:36, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
It will be read for decades, whereas no one in 10 years time is going to be reading today's tickets.
I strongly disagree with this.
Tickets are the main artifact for me to interact with GHC. That includes 15 years old tickets that are still unsolved today (there are plenty).
GHC tickets are referenced in the GHC codebase itself, in cabal and all sorts of other places.
I think you're looking at it from a "I'm a core GHC developer" perspective only. And for those your assessment might be true. But there's a large audience for whom tickets is the main source to understand what has been done and is still missing.
It would be absurd to expect Mikolaj to write every word. He doesn't know enough about GHC's internals. If I insisted on that, he just wouldn't submit them, and that would be a shame
This is what we call the meat proxy phenomenon: https://meatproxy.me/
The bug report is still valuable, but the "I asked an LLM..." is not, unless:
* the prompting was so complicated or time intensive that it's hard to reproduce (well, you can share web prompts) * the token spent was very high * there was significant review/judgement involved (doesn't seem so)
No one is complaining about people using AI to find reproducers. But even here that's something a developer may as well just do themselves if all it took was "here's a GHC ticket, try to find a minimal reproducer". _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
participants (17)
-
amindfv＠mailbox.org -
Andreas Klebinger -
Ben Gamari -
Bryan Richter -
Clinton Mead -
Julian Ospald -
Kazu Yamamoto -
Magnus Viernickel -
Mikolaj Konarski -
Moritz Angermann -
Rodrigo Mesquita -
Simon Jakobi -
Simon Peyton Jones -
Teo Camarasu -
Tom Ellis -
Viktor Dukhovni -
Wolfgang Jeltsch