Hi Simon (Jakobi),
I'm not deeply engaged in the discussion; I just want to insert my two
cents.
> > We strongly prefer human-written code
> I understand that it's "good exercise" to write code by hand.
I think you're missing an important aspect of this "good exercise".
Writing code by hand allows you to examine the abstractions you've
decided to use. Bad abstractions require a lot of code to use, and you
quickly grow tired of them. You naturally proceed to think about
possible improvements. It's actually beneficial to be bad and extremely
slow at writing code if you apply this reasoning =)
At the same time, any amount of LLM-produced code is cheap to produce.
It's very easy to ignore bad abstractions or the absence of abstraction
if it only takes 10–20 minutes to produce thousands of lines of code.
Lots of practice provides an intuition about bad and good abstractions,
and you may choose the right one from the very beginning. However,
writing code by hand is still a good battle test and reality check.
I hope this reasoning model is beneficial to the discussion.
Cheers,
Andrei.
P.S. The grammatical structure of this message has been checked by an AI.
On 14.07.2026 18:42, Simon Jakobi via ghc-devs 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]
