After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following:
Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:

LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR.
2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR.
3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR.
4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs.
5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed.
(1) is the MR you want.
(2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english.
(3) is the person you probably don't want, but can't tell from the outside.
(4) is the person you probably don't want, but still can't tell from the outside.
(5) is the person you probably don't want, and might find out later.
Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs.
Person (5) will feel ashamed if called out.
Reviewers still have to deal with (3), (4), (5).
And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.

And I _really_ _really_ think we want people especially from group (1) and (2).

I honestly think
> code may be reviewed if you find a reviewer

is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.

Even extending it to:
> if you submit a LLM PR, you should find a potential reviewer before doing so

I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.

I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.

Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...

But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.

In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.

Best,
Moritz

On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:

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

_______________________________________________
ghc-devs mailing list -- ghc-devs@haskell.org
To unsubscribe send an email to ghc-devs-leave@haskell.org