One basis for comparing LLM-generated vs hand-rolled code is to consider them as alternative production processes for (software) artifacts, engendering analogies to comparisons between "code written with this or that editor" or "code developed on this or that operating system". Examples abound if we zoom out of software, e.g. typewritten vs word processed books, lab-grown vs mined diamonds.
While the production process influences the final product (to a larger or smaller extent, depending on the analogy), one can see the risk in strictly grading products according to a hierarchy of preference among production processes, when a more nuanced perspective might e.g. consider the context of use (drill bit or wedding ring?). However under a different lens, we might view code as less of a dead product and more of a living thing. Code (and its mental correlates) can be considered to have genealogy, population dynamics, ecological niches, and interactions (symbiotic or antagonistic) within an ecosystem whose health and composition are managed by maintainers. This shifts the problem from one of product selection to one of ecological husbandry. The analogies shift also: is it sensible to establish protections for a slow breeding native fish population over carp? What is the natural outcome (under the pressures of the ecosystem) of the alternative? PS: Apologies in advance if this is only of marginal utility to the (already quite long) conversation. On Sun, Jul 26, 2026, 5:49 a.m. Moritz Angermann via ghc-devs < [email protected]> 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 < > [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] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
