Thanks for taking the time to write, Simon.

I have updated my draft

Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well.
Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.)
Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.

I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.

For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.

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.

My intent was NOT to discourage contributions that involve LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.

thanks again

Simon

On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:

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 -- ghc-devs@haskell.org
To unsubscribe send an email to ghc-devs-leave@haskell.org