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]
