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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> wrote: > >> > On 07/26/2026 8:57 AM CEST Moritz Angermann <[email protected]> >> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
