Thanks, Simon! A few more comments:
> A beautiful code base I wonder if this principle should be balanced with the goal of trying to make a "good compiler": a good tool which is "a joy to use". Specifically I'm thinking about some compiler performance challenges where a pragmatic solution comes at the expense of code elegance: I'm probably overthinking this, but I'd like to avoid a situation where someone points at these principles and says "We can't accept these performance improvements because they make the code less beautiful." > If you are reviewing an MR, and any part(s) of your review are generated by > an LLM, you should use essentially the same guidelines as above. That is, you > must take responsibility for every line of your review (P2); So I think that it would be worth experimenting with LLM-generated reviews, in order to reduce the load on human reviewers and in order to catch more bugs and performance issues before they make it into the code base. But if we require that the person who prompts the review and reports it on the MR has to take full responsibility for that review, I think that such an experiment is unlikely to stand a chance. In particular, the person providing the review would then probably be required to understand the generated review, and possibly the MR too. As a consequence we would be less likely to get LLM-generated reviews on the more complex MRs where they could be particularly helpful. I'm not sure if there have been any problems with LLM-generated reviews so far? My suggestion would be to drop the responsibility requirement for clearly marked LLM-generated MR reviews. > P1 [...] > These guidelines apply fully only to MRs on which you now seek review. In > the process of developing a solution, you may want to put up a MR so to see > what the CI system says, but without, at that time, seeking review. That's > fine: just mark it "Draft" (in the title), and say explicitly at the top of > the Description that you are not yet seeking review. My preference would be not to require the additional "Don't review yet" note. The contribution process is already complicated enough IMHO. > R1 [...] > (P2) says that you should take full responsibility for your entire > contribution. It is certainly possible to do so by forensically reviewing and > revising the output of an LLM, checking that you understand and stand by > every line of code, **that there is no clearer or simpler way to achieve the > goal; and that every sentence of documentation is accurate, necessary, clear, > and fully yours.** (emphasis mine) These criteria seem to set the bar very high, and I'm pretty sure that there have been multiple contributions that didn't involve LLMs and that failed to satisfy these criteria, so it seems a bit unfair to impose them now and only on LLM-generated contributions. The undertone I'm getting is "If you make an LLM-generated contribution and it's less than absolutely perfect, you're a bad LLM-jockey and you should feel bad." IMHO this just deters possible contributors, so maybe this paragraph can be toned down a bit for now. If the policy turns out to be insufficient to stop the slop, we can still strengthen the requirements. ---- Apart from these points, I think the main problem with this policy is its length. In its current form I feel it mainly transports how divisive and complicated this AI topic is, and I think that's kind of bad PR and not what potential contributors expect from a policy document they need to follow. The OCaml AI.md linked in the draft has a good length and shape IMHO. Cheers, Simon Am Di., 21. Juli 2026 um 10:16 Uhr schrieb Simon Peyton Jones via ghc-devs <[email protected]>: > > Friends > > There has been a lot of discussion about GHC's LLM policy on this GHC thread. > > I have made quite few revisions in the light of this and other conversations. > Here is the draft again, I hope in a close to final form. Any final > thoughts? > > thanks > > 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]
