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