I think it's fine to make the argument against. But clearly the
suggested policy is not a LLM ban.
It seems extremely clear to me that no matter how it will look at the
end it won't be a LLM ban.
So perhaps focusing on a hypothetical ban is not the best use of anyones
time at this point. Clearly the discussion has moved past that.
------------
On the point of language barriers. Personally I'm fine with someone
writing texts in one language and then using whatever translation tool
they prefer to translate
their text. I don't think anyone actually disagrees with this. *I still
think it's good to point this out when doing so as it can help avoid
misunderstandings.
*Idoms can be very confusing when translated. I've found that dealing
with a text originating in another language is easier if I know about
that fact.
In my experience knowing it's been translated, and from what language,
can make decyphering certain phrases that are translated badly easier.
-------------
> - “LLM-generated code will contain different mistakes than code
written by humans does while the results often look very similar on the
first glance.” If we make such a claim, we need to put substance to it;
this needs a source.
You can put "Andreas Klebinger reviewing AI generated MRs" down as a
source if you like. Or just look for a paper. I found this one in 2
Minutes for example: https://arxiv.org/abs/2508.21634
Yeah it's based on older models. I'm sure you will have issues with it's
methodology. But it mostly matches my experience when reviewing code in
that there *are* differences between the kinds of
code and bugs a human would write and a model would generate. I'm sure
there are more such papers if one really wants to look further.
I have seen people put up AI MRs with bugs that contained bugs that a
humand understanding the structure of GHC would be *very* unlikely to make.
I'm not pointing at specific AI's because the point here is not to name
and shame them.
I'm not even saying they are always worse. For example I watch out more
closely for shadowing bugs in human written code than I do in AI generated
code. They are just different in a way where I as reviewer see it as
valuable to know about the origin.
> I am so vehemently against a policy that tries to classify LLMs as
something special.
Personally I don't see the big deal. I attribute it when I use code from
some library. When I implement an algorithm from some paper I reference it.
When I let AI do most of the work I similarly do the same. There are
references to stack overflow in GHC iirc and I think that's a good thing
to be liberal
in referencing your sources.
Yes there is no clear cut here. There will be edge cases. What if you
use it to review your hand written code and hand apply the suggested fixes?
What about having the LLM apply them? What about ... it really doesn't
matter.
If I use a paper or a library as inspiration and then rework the algo
massively it's up to me to decide if the reference is still useful. I
don't see it as much
different with LLMs. If there is honest confusion we can provide guide
lines. But I'm not sure there really is. And if people sometimes get it
wrong so be it.
The goal here is not to ostracise contributions that are partially LLM
generated. The goal is to make review easier. And if in 5 years no one
can tell the difference
between hand written contributions and LLMs we can simply change our policy.
Maybe it's simply a point we will have to agree to disagree on. But as I
see it with the state of this technology, and how it's used in practice,
it's in GHCs best interest
to ask people to mark LLM generated contributions as such for the time
being.
On 15/07/2026 07:00, Moritz Angermann via ghc-devs wrote:
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
<[email protected]> 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
<[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
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 [email protected]
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
