Jaro,
Thank you for proving my point. Your accusation of LLM use is precisely
what irritates me about the LLM policy. I hope you'll be able to (for
yourself) substantiate this accusation.
Also your accusal that I did _not_ address your question is incorrect in my
opinion.
You asked:
> Why, then, do we keep considering allowing such behavior?
And I spent significant time, and effort to outline the reasons why I am
not only certain that this has happened before, but even more importantly
why I think that a policy that considers NOT allowing such behavior is
contra productive. All that while typing from a fucking phone in a coffee
shop, while trying to keep a very conciliatory tone, and rephrasing many
paragraphs multiple times over. But you seem to rather want my raw text
without trying to keep it calm.
Just to reiterate, you basically did precisely what I was afraid of
happening. Anyone contributing to GHC, whether or not they use LLMs is now
under general suspicion of potentially having used LLMs (or basically _any_
assistive technology). And having the effort they put in negated by a
potential accusation of assistive technology use whether true or false.
This creates the environment I have been warning about all along! It
creates suspicion by default. And even worse suspicion that the accused
will be unable to disprove irrespective of the content.
Maybe I should just start to look less at trying to write cohesive and
without spelling mistakes and throw in some vulgarities to make sure I’d
not accused of llm use? And probably never use—an em-dash?
Where does this end? I’m sure it will lead to high quality contributions if
the contributors need to make sure to leave some “proofs” of human hand
writing?!
You’ve also demonstrated that you completely disregarded my email simply on
the grounds of suspicion. Moreover I do not see anyone yet having addressed
any of my concerns, other than: well then leave.
At this point I think Julian is right. The only workable policy is an
outright LLM ban; and forking GHC.
Weird I’ve now spent significant time trying to find a compromise, even
trying to find a wording (and why do I have to come up with this? I don’t
want this policy, you guys—who don’t like assistive technology—want a
policy!) that would hopefully satisfy Tom, while still being acceptable to
me.
Yes, the v1 policy is not acceptable to me.
The v2 policy is acceptable to me.
It’s Sunday night and I’m effectively still working to fight for my team to
not be institutionally discriminated against or need to spend time
defending themselves from accusations of LLM use going forward.
I’m sure you’ll consider this email like all my previous ones to be llm
generated, so I end up wondering why I’m even writing this response.
- moritz
PS: I guess you can just write what ever you want into the policy, and hope
people will follow it; while it will be mostly ignored, by the people you
want to address. Sad.
On Sun, 26 Jul 2026 at 18:57, <code(a)jaro.addy.io> wrote:
> Moritz,
>
> I'm sorry, but like some others have expressed already, I don't feel like
> you are responding to my question at all, so I don't think further
> discussion will be fruitful.
>
> It even seems like your use of LLMs in this discussion is causing us to
> talk past each other, directly demonstrating why allowing LLMs is not a
> good idea.
>
> Please don't respond to my e-mails with LLM generated text,
>
> Jaro
>
> On 26 Jul 2026, at 11:49, Moritz Angermann via ghc-devs <
> moritz.angermann(a)gmail.com> wrote:
>
> Jaro,
>
> Good question.
>
> To some extent, this has already happened. So the question seems to be
> whether we want to start prohibiting it going forward, or whether we
> instead define conditions under which such contributions remain acceptable.
>
> I also have rather practical reasons for arguing my case here.
>
> I’d very much like to continue contributing to GHC, preferably without
> maintaining a fork. Likewise, members of my team regularly contribute fixes
> and improvements to GHC as part of their work. If the project adopts a
> policy that institutionally disfavors those contributions simply because
> of the workflow used to produce otherwise acceptable contributions, that
> would make continued participation substantially harder for us. Over
> time, I also worry that this makes it more difficult to justify investing
> engineering time and funding into upstream GHC work.
>
> For me, the line is not the use of LLMs itself. The line is whether the
> project starts expressing a systemic preference between otherwise
> acceptable contributors based on their workflow.
>
> I cannot in good conscience contribute to, or advocate for, a project that
> institutionally ranks otherwise acceptable contributors or their work in
> this way.
>
> You might reasonably respond that, by opposing such a preference, I am
> disadvantaging contributors who dislike LLMs.
>
> I don’t see it that way.
>
> I am not arguing that anyone should be forced to use LLMs, nor that anyone
> should be compelled to review LLM-assisted contributions. Contributors
> remain free to review—or not review—whatever they choose. Just as they are
> today.
>
> What I am arguing against is the project itself adopting one side of that
> disagreement as an institutional preference. I think there is an
> important difference between reviewers expressing individual preferences
> and the project itself adopting those preferences as policy.
>
> Ultimately, I still think contributions should be evaluated on their
> technical merits.
>
> If the concern is that low-quality LLM-assisted patches will routinely
> pass uncontested through review, then I think the underlying problem is the
> review process rather than the existence of LLMs.
>
> The current proposal already introduces disclosure precisely so that
> reviewers who do not wish to review LLM-assisted contributions can opt out,
> while giving reviewers who do engage additional context.
>
> If the overwhelming majority of reviewers exercise that option, then
> LLM-assisted contributions simply will not be merged, or will be merged
> only very slowly because they are drawing from a much smaller review pool.
>
> Best,
> Moritz
> On Sun, Jul 26, 2026 at 4:12 PM Jaro Reinders via ghc-devs <
> ghc-devs(a)haskell.org> wrote:
>
>> We all seem to recognize that interacting with LLM generated code or
>> documentation makes a significant number of contributors uncomfortable. If
>> LLM generated code and documentation makes it into the codebase, then it
>> will become practically impossible to avoid and thus it will make a
>> significant number of contributors uncomfortable. Why, then, do we keep
>> considering to allow such behavior?
>>
>> Cheers,
>> Jaro
>>
>>
>> On 26 Jul 2026, at 10:27, Moritz Angermann via ghc-devs <
>> moritz.angermann(a)gmail.com> wrote:
>>
>> Hi Tom,
>>
>> Thank you. I think this gets us considerably closer.
>>
>> There is an important difference to me between:
>>
>> We strongly prefer human-written code.
>>
>> and:
>>
>> Some contributors strongly prefer human-written code.
>>
>> I could live quite comfortably with the latter. It acknowledges that the
>> community is not monolithic and that this preference genuinely exists,
>> without the project itself adopting that preference as its own.
>>
>> I would be less comfortable with “a large portion” or “a majority,”
>> because those are empirical claims that I don’t think the GitLab issue
>> establishes. To make such a claim, we would first need a representative
>> consultation and agreement on who constitutes the relevant community and is
>> eligible to participate.
>>
>> Perhaps wording along these lines would capture the concern without
>> overclaiming:
>>
>> Some contributors strongly prefer human-written code and documentation
>> and may be uncomfortable reviewing or maintaining LLM-assisted
>> contributions.
>>
>> That seems factual, acknowledges their position, and leaves the project
>> itself neutral between contributors who hold different views.
>>
>> Best,
>> Moritz
>>
>>
>> On Sun, Jul 26, 2026 at 2:20 PM <amindfv(a)mailbox.org> wrote:
>>
>>> > On 07/26/2026 8:57 AM CEST Moritz Angermann <
>>> moritz.angermann(a)gmail.com> wrote:
>>>
>>> > Human-written: Each and every substantive character of the final text
>>> was manually composed by a human. No assistive tooling was used to produce
>>> the substantive wording itself.
>>> >
>>> > Machine-written:Each and every substantive character of the final text
>>> was produced by a machine without meaningful human intervention. This is,
>>> to me, the diametric opposite ofhuman-written.
>>> >
>>> > Human-delegated: A human deliberately delegates the production of some
>>> or all of the substantive text to a machine.
>>> >
>>> > Human-guided: A human iteratively guides the production by providing
>>> prompts, constraints, corrections, examples, and feedback.
>>> >
>>> > Human-supervised: A human continuously evaluates, accepts, rejects, or
>>> redirects the machine’s output while it is being produced.
>>> >
>>> > Human-edited: A human substantially modifies machine-produced text
>>> after generation before adopting it.
>>> >
>>> > Human-authored: A human exercises judgement over, understands,
>>> selects, revises, adopts, and ultimately takes responsibility for the
>>> resulting work, regardless of how individual parts of it were initially
>>> produced.
>>>
>>> All of your definitions here, except the first, seem to include large
>>> sections of the final result being written by an LLM.
>>>
>>> I think "Human-written" could be expanded to include things like, "oh, I
>>> copy-pasted this 3-word phrase that came out of a conversation with an LLM
>>> chatbot," but I agree with the previous policy proposal: "By all means use
>>> an LLM to generate ideas, points to cover, and structure, but the best way
>>> to take responsibility for every word is to write every word."
>>>
>>> Cheers,
>>> Tom
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list -- ghc-devs(a)haskell.org
>> To unsubscribe send an email to ghc-devs-leave(a)haskell.org
>>
>
>
