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