> On 10/23/2026 12:58 PM CEST Wolfgang Jeltsch via ghc-devs > <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
