I also think that softening R1 is a mistake. Notably R1 is worded quite strongly but is a *recommendation*. I think Simon is quite clear here:
> All that said, it is a recommendation, not a requirement. Contributions are evaluated under P1–P3, not according to whether their final text was personally composed. In some extreme cases it would be peculiar to insist that a human type in every character of a code change -- for example, when an LLM finds an obviously-correct one-line code fix. More generally, it is possible to achieve (P2) 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. This level of attention may well take as much effort as writing it yourself. Contributors are free to make the effort to follow P1-P3 however they wish, and so long as they really do manage that, we are not going to reject them (though we have a recommendation). That seems fair to everyone. I think the LLM users would argue that they can make contributions just as good as the manually written ones. Very good - the policy does not forbid that! M On Mon, 3 Aug 2026 at 11:00, Teo Camarasu via ghc-devs <[email protected]> wrote: > Hi Avi, > > On Sun, 2 Aug 2026, at 4:29 PM, Avi Press via ghc-devs wrote: > > > *"R1: Recommendation: write the final version yourself"* could be better > softened to something like: *"R1: Make a final human author-led pass." *My > thinking is that the current wording somewhat undermines the otherwise > tool-neutral position, and could even be interpreted as a requirement in > practice despite being labeled a recommendation. In my opinion, hand-typing > every character isn't a relevant standard, except as a supplement to (P2). > > > I think that would make it quite a different recommendation and one that > would no longer effectively "[force] you to think. It's hard to type in > code that you don't understand!" In my experience at least, making a pass > through LLM generated code can fail to catch both subtle issues and > fundamental architectural mistakes. It often looks extremely reasonable > until you start to engage with it critically and in earnest. It is > extremely helpful to rephrase things in your own words to > > It seems like putting the cart before the horse to discount a > recommendation because it doesn't come across as neutral enough to some. I > think it is worth coming up with a policy that is derived from our > principles as a community rather than reacting to LLMs ad hoc. And it is a > strength of this draft that it takes this approach. Yet, if we derive from > our principles that certain aspects of LLMs are harmful then we shouldn't > shy away from that! The very purpose of a policy is to draw out these > things. > > Cheers, > Teo > _______________________________________________ > 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]
