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@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@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@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@mailbox.org> wrote:
> On 07/26/2026 8:57 AM CEST Moritz Angermann <moritz.angermann@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@haskell.org
To unsubscribe send an email to ghc-devs-leave@haskell.org