Hi all, I agree with Simon (Jakobi)'s message 100%.
Writing Software is no longer about writing code, it's about making good architectural decisions to guide an LLM to do it. It's pretty much what I do when I review code by a contributor. I'm happy for the contributor's code in much the same way as I'm happy for the LLM to write it, and I instruct them to (re-)write the code in exactly the same way. At the end of such a review cycle, the code is pretty much the joint product of both the contributor and the reviewer. If I haven't reviewed the code (such as when I mark the LLM-generated MR as draft), then it is not meant to be merged, not even meant to be reviewed by other people, except to get a glimpse of the proposed design. Cheers, Sebastian Am Di., 14. Juli 2026 um 16:42 Uhr schrieb Simon Jakobi via ghc-devs < [email protected]>: > Hi Simon, > > here are my comments on the policy document: > > > In particular, you must not use AI-generated text in a direct > conversation with a human reviewer. > > I think this is too restrictive. A contributor may easily reach the limits > of their understanding during a code review, and I think it's ok to resort > to using an LLM then. I think it's fair to require that they clearly mark > the LLM-generated part of their response though. > > > P1: Write MRs that are easy to review > > I fully agree with this, and apologize that some of my MRs have not been > easy to review! I do want to point out though that MRs marked as "Draft" > should not be held to the same standards as a "ready" / non-draft MR. I > frequently open draft MRs mainly to get the CI results. Sometimes I still > get detailed reviews on these MRs, and then feel sorry that a reviewer > wasted their time on this. > > > P2: Full responsibility > > > 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? > > For bug reports, I think GHC should be more lenient, and instead require > that LLM use is clearly signalled. > > > P3: Strong preference for human authorship > > > We strongly prefer human-written code > > I understand that it's "good exercise" to write code by hand. > > 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 already realize that some core contributors have much disdain for > LLM-generated code. If the GHC project decides to devalue contributions of > LLM-generated code with this language, I think this will reduce my > motivation to contribute. > > > 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! For example, I think GHC should try using LLMs for > "first-line" code review. LLMs are already very capable at debugging. How > about investing in fuzzing or better automated testing, so bugs are > discovered before they make it into a release? > > > We strongly prefer human-written documentation. > > Documentation generated by recentish models like Claude Opus 4.8 has > indeed been quite bad. Claude Fable 5 is already much better at this. > > I think the main incentive resulting from this policy is to include _less_ > documentation in contributions. In a world where LLMs are very capable of > making sense of large code bases, maybe that's not much of a drawback. > > --- > > Overall, I feel that much of the recent discussion about LLMs in GHC and > Haskell has been driven by fear and anger. I think many Haskellers are very > proud of their skill to produce high-quality code, and as LLMs get better > and better at this, this skill is becoming "less special". > > Instead of trying to discourage contributions that involve LLMs, I think > this project should rather try to welcome creative use of LLMs for the > benefit of this project and all Haskell users. > > Sorry for the bad wording here and there. I did not use an LLM to write > these comments, and it took me an embarrassingly long time. > > Cheers, > Simon > > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
