Andreas,
I should probably not have dealt in extremes to try to make my point.
What I'm trying to convey is that LLMs are not special in the ability
to produce poor code. They _do_ lower the bar, but LLMs are
fundamentally orthogonal to the problem we face with them. As such I
mostly question the necessity for large parts of the policy.
Especially as I question the enforceability of the policy, and what
value does a policy without teeth have?
From the interactions you had with me, you might know that I deeply
value simplicity over (unnecessary) complexity. And this policy as it
grows to me becomes increasingly complex. I think we could do with a
much shorter policy, that doesn't even mention LLMs/AI, ... and sets
the general expectations that would cover much more than just the
challenges with LLMs.
I've taken the part from the policy that I consider very valuable and
modified it slightly below. I would like us to set a frame that
transcends LLM and similar concerns, and focuses on the outcome we
want, not on the particulars.
Best,
Moritz
*Basic principles of GHC Development:*
*
We want to nurture the community of passionate volunteers who
maintain and develop GHC, their motivation, their relationships,
and their enjoyment.
*
We want to build software that is the province of humans, where it
is understood and developed by a community of people.
*
We want to build a code base that we can be proud of: well
structured, well documented, even beautiful.
*Collaboration*
*
Human conversation. In offering a contribution to GHC you are
becoming a valued part of a community of living, breathing
people. You are offering your work for free, and members of the
community are likewise offering their work to you for free, to
review and improve your MR, and to help you to learn your way
around the code base.
They should treat you with respect, and you should treat them
likewise. You are expected to enter a direct conversation with a human
reviewer, and be able to fully motivate, explain and stand behind the
contributions you offer. They want to talk to you.
*
Supporting contributors. We aspire to nurture a
mutually-supportive community of human beings who contribute to
GHC. GHC is a large code base, which can be intimidating. Many
GHC experts hang out on ghc-devs mailing list, or the Matrix
channel, and IRC, and are happy to help. Here's a list of channels
<https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc>.
*
*No Right to Reviews*. Your contribution to GHC may not be
automatically reviewed. There is only a small pool of active
reviewers, and it is often best to reach out to people through the
mailing list, irc, matrix, ... and find reviewers this way. We
very much look forward to having you as a reviewer as well.
Contributions that fail to enlist a reviewer or sheperd may be
closed as-is after a reasonable timeframe (e.g. 3mo). *Always be
sure that your MRs meet your own expectations on MRs you'd like to
review.*
*
*Bad actors and poor quality contributions.* In the rare case
where contributions to GHC are of sloppy, and poor quality, we
reserve the right to ignore and eventually ban aspiring contributors.
On Wed, 15 Jul 2026 at 15:44, Simon Peyton Jones
<[email protected]> wrote:
Thanks for your feedback Iavor.
The only bit I have some reservations about is the bit that
any LLM use needs to be clearly indicated, as often the LLM
use tends to be a bit "blurry", and I generally tend to think
of the code as something I did, even if I happened to use an
LLM for some bit.
I have clarified that section (P4). I never intended to cover
"any LLM use", so I have made that more explicit. I intended NOT
to require declaration of use of LLMs to help you find your way
around the code base, draw diagrams etc. Just declare if the
material you are asking others to review was LLM-generated, even
if (P2) you take full responsibility for every line. Doing so
is not a weakness; it just provides context.
I hope that may address your unease.
Simon
On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki
<[email protected]> wrote:
Hello,
I like the document Simon has written because it established
expectations and it does so with nuance. I also might be in
the minority, but it doesn't seem overly long to me. I view
such documents as guidelines, rather than law, and as such I
am not worried about it being "weaponized": if we have
disagreements we should still discuss them directly rather
then appealing to the document, as an arbiter if truth.
Here are a few of my experiences with LLMs so far:
* I find them very useful for refactoring code
* For generating new code, I am still experimenting with the
amount of guidance to give the LLM. My impression is that I
tend to be a lot more controlling than other folks using them
(I don't really try to "one shot" things). I do this because I
find it a lot easier to review the code as it is being
written, then doing it all at once after the fact.
* For complex features, I find working on a plan with an LLM
to be pretty handy: it's a bit like having a fancy rubber
duck, to clarify my thinking and try to think of all
possibilities
* I've had some good luck with having the LLM find bugs in
the code
* I also find them a pretty handy tool for getting familiar
with a new code base. I've used them to sketch architecture
diagrams, pointing to important modules, and it is pretty
convenient to be able to ask questions about where to look for
things in the code
On the more negative side:
* It is important to clearly scope your work, as LLMs make
it easy to make giant PRs, even if you do it a little bit at a
time. I just did this on a project (not on purpose!), and now
we have a giant PR that I am the only person who understands.
I was too focused on implementing the features, and not
thinking of how it would be reviewed, which is a mistake (in
retrospect an obvious one)
* We've had issues with "drive by PRs" where a new
contributor dumps a bunch of code. Some of my colleagues try
to review those, but I am inclined to just delete them unless
I can get some engagement from the contributor and get a sense
that they know what they did (which hasn't happened yet)
I think that most of my experiences are aligned with the
proposed GHC policy. The only bit I have some reservations
about is the bit that any LLM use needs to be clearly
indicated, as often the LLM use tends to be a bit "blurry",
and I generally tend to think of the code as something I did,
even if I happened to use an LLM for some bit. Not so much
opposed to this I just wouldn't know what to label.
More long term, I think as a community, it would be useful to
focus on getting more folks to be able to and comfortable to
review code. Traditionally, I think we've encouraged new
contributors to implement some small feature, and then have
somebody experienced review their code. I wonder if this might
work the other way around too, where a new contributor reviews
a PR of an experienced contributor (perhaps in addition to
another review).
Anyway, I hope this helps!
Cheers,
Iavor
On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs
<[email protected]> 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 to [email protected]
_______________________________________________
ghc-devs mailing list [email protected]
To unsubscribe send an email [email protected]
