Hi Wolfgang, Am Di., 14. Juli 2026 um 23:54 Uhr schrieb Wolfgang Jeltsch <[email protected]>: > > > > In particular, you must not use AI-generated text in a direct > > > conversation with a human reviewer. > > > > I think this is too restrictive. > > Isn’t it fundamental for a conversation that the conversation partners > themselves speak or write and not send texts generated by a machine?
What I meant is a situation like this: * Reviewer asks a question that is way too deep for the newbie contributor. * Newbie contributor answers "I thought it's X but my LLM explains it like this: '...'" That's not ideal, but acceptable IMHO. It mostly reveals the limits of the contributor's understanding, and maybe the limits of their interest, or willingness to dive deep. > > > You must understand, and be able to explain, every line of code, and > > > every sentence of documentation. Every line! > > > > I think that’s a good goal, but even for MRs, maybe too strict a > > requirement. Where do you draw the line? Is the contributor expected > > to understand every (pre-existing) function they used? To what extent? > > Strictness and performance characteristics too? > > If you contribute code, you should surely understand this code that you > contribute. If your code uses some function, you should understand the > consequences of using it, which implies that you should know about its > strictness and performance characteristics. This is the ideal at least, > which, I agree, is difficult to meet for people not deeply into GHC, me > included. However, the solution is to make it easier to understand > existing functions in the GHC codebase, for example by writing > documentation, not to lower the standard for contributions. I just think it should be toned down a bit. The current wording is kind of scary. > > > We strongly prefer human-written code > > > > I understand that it’s “good exercise” to write code by hand. > > I don’t see programming as a mere exercise. It’s a key part of > developing software. I think that's changing now. Sebastian's comments on this were pretty spot-on IMHO > > But I've always been pretty bad and extremely slow to write code. And > > now that recent models have become so good at producing code, I was > > relieved that I can now contribute without being so limited by my > > code-writing skills. > > I definitely don’t want to be offensive, but is it a good idea to > contribute code to a software that many are relying on if you’re “pretty > bad” at writing code? I have a good amount of experience as a library maintainer, so I think I have decent judgment regarding code quality. I'm just very inefficient at producing code by hand. > > > Writing it yourself forces you to think about every line; and it > > > imposes a cost on you if you write 1000 lines instead of 100. > > > > IMHO contributing to GHC is already quite onerous and “costly”, > > especially for newcomers. Just think of the flaky CI system and recent > > GitLab performance. Instead of trying to impose additional costs on > > contributors, I think it would be better to try to reduce the cost of > > reviewing and maintenance! > > I completely agree that contributing to GHC can be a frustrating > experience, but the solution is to improve things like the CI system, > isn’t it? Improving the ergonomics of contributing to GHC is really important, yes! And I think it's an area where LLMs will be very helpful, because few people seem to enjoy working on these things otherwise. In fact I've already started putting LLMs to good use in this area. See e.g. MR !16166. > What Simon (Peyton Jones) suggested was that the actual coding > should have a significant cost to avoid generating lots of code, which > can hardly be checked properly. I get it, but I just don't think it's the right approach. > > Overall, I feel that much of the recent discussion about LLMs in GHC and > > Haskell has been driven by fear and anger. > > I can assure you that at least I are not driven by anger in this > discussion. What I want is preventing harm. You may call this > “motivation by fear”. I would rather call it “motivation by concern” > and, not least, “motivation by ideals”. Also note that being motivated > by fear is not necessarily a bad thing. Sometimes fear is adequate. Given the huge shift that's happening in software development, I think that some concern is warranted. But I think it's more important to grasp the opportunities and to invite experimentation and LLM-assisted contributions now. Cheers! Simon _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
