Am Di 21.07.2026 14:32 schrieb Tom Ellis via ghc-devs:

On Tue, Jul 21, 2026 at 04:24:53PM +0300, Wolfgang Jeltsch via ghc-devs wrote:

...

I sense that the text has notably moved towards the “pro-LLM” side. Sometimes this led to outright wrong statements, like the following:

...

If you carefully review and understand every line of code or documentation produced with LLM assistance, revise it where necessary, and take full responsibility for every line, that constitutes human authorship.

No, it doesn’t. An author is a person who *created* the work. If the work was assembled by an LLM, based on only guidelines by the person in question, then said person acted only as a reviewer, not as an author.

Would it help if the text were changed to “… that constitutes human authorship for the purposes of this policy.”? That is, make it clear

This would still mean using the term “authorship” in contradiction to its actual meaning. Why not be honest and say that GHC doesn’t require contributors to be authors? Or just be silent about this issue? All the best, Wolfgang

I changed it to "human authorship for the purposes of this policy". If Claude suggests a one-line change, and I agree with it, and (after careful examination) would have written exactly that change myself, that's enough for me. It would be odd to say that I must re-type it myself. I really don't want to be silent on this issue. I want us to be explicit that every line of code has a human being standing behind it, vouching for it, taking personal responsibility for it. If anyone wants to offer a better term than "authorship" to express this aspiration, by all means do suggest it. (Terminology is always hard.) I sense that the text has notably moved towards the “pro-LLM” side. The intent (perhaps badly executed) is to be neither pro nor anti, but rather neutral about whether LLMs are good or bad. Rather that be pro or anti, since we want the policy to guide the behaviour of a very diverse group of people, it tries to de-emphasis the tools and instead concentrate on (a) the artefact itself (e.g the MR) and especially (b) the effect on our shared discourse and the motivations and agency of both reviewers and contributors. That neutrality may not truly satisfy anyone, but I hope that it may perhaps constitute a shared statement of some things we agree about (e.g. respectful discourse, high quality code base), and (because it is neutral) be equally un-satisfying to everyone. Of course, even what "neutrality" means might be controversial. I'm grateful to Wolgfang and others for their willingness to move forward together even if we disagree in some ways. Simon On Tue, 21 Jul 2026 at 14:43, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:

Am Di 21.07.2026 14:32 schrieb Tom Ellis via ghc-devs:

...

On Tue, Jul 21, 2026 at 04:24:53PM +0300, Wolfgang Jeltsch via ghc-devs wrote:

...

I sense that the text has notably moved towards the “pro-LLM” side. Sometimes this led to outright wrong statements, like the following:

...

If you carefully review and understand every line of code or documentation produced with LLM assistance, revise it where necessary, and take full responsibility for every line, that constitutes human authorship.

No, it doesn’t. An author is a person who *created* the work. If the work was assembled by an LLM, based on only guidelines by the person in question, then said person acted only as a reviewer, not as an author.

Would it help if the text were changed to “… that constitutes human authorship for the purposes of this policy.”? That is, make it clear

This would still mean using the term “authorship” in contradiction to its actual meaning. Why not be honest and say that GHC doesn’t require contributors to be authors? Or just be silent about this issue?

All the best, Wolfgang _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

I would agree with this. The point is not the means by which the code / documentation / review / etc.was developed; it is the question of responsibility. And you can't go back and ask Claude or Copilot about its involvement in an MR or review (probably that session's been wiped), just as you can't ask someone local to the author- or reviewer-of-record who had given them tips and hadn't mentioned because it had been considered a minor or indirect contribution. On Tue, Jul 21, 2026 at 11:59 AM Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:

On 7/21/26 16:24, Simon Peyton Jones via ghc-devs 'ghc-devs at haskell.org' wrote:

...

If anyone wants to offer a better term than "authorship" to express this aspiration, by all means do suggest it. (Terminology is always hard.)

I would suggest "ownership" (as in code owner), which already has the meaning of a person responsible for a piece of code (e.g., https://doi.org/10.1007%2Fs10664-024-10538-5).

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

-- brandon s allbery kf8nh allbery.b@gmail.com

Tom,

I've had to read far more LLM-generated text than I'd have liked. I had a distinct sensation that I was being asked to re-read the same points as had been previously made, padded out in length by an LLM.

Are you referring to emails and their contained text that I wrote? Best, Moritz On Wed, 22 Jul 2026 at 00:58, amindfv--- via ghc-devs <ghc-devs@haskell.org> wrote:

Regretfully, and with full recognition of the need to balance the preferences of many developers, I think the removal of a statement of preference for human-written code takes the heart out of this document. It would cause me to withdraw my support, for whatever that's worth.

My perspective is that of a very infrequent contributor who follows development on the Gitlab pretty closely, and values being able to do so.

I understand the goal is to be as neutral as possible, but let me try and make the case that even putting aside the social and environmental (etc.) concerns, there is not an easy neutral position waiting for us:

Take a very easy-to-imagine scenario: a person opens an MR, which begins with: "Here's some code. It's been generated using AI, as has its documentation. I stand by it." The revised draft policy seems to assume that that only people whose business that is are the author and whoever's willing to review the proposed changes. I feel it would be a great loss to arrive at the GHC Gitlab to read about a change of importance to me, and have to wade through a long document alternating between "This code has been written with LLMs. I stand by it." and "This review has been written with LLMs. I stand by it." And in the end, documentation will be something many will read, even if they have a strong distaste for AI writing style. A developer taking responsibility for every word may still contribute to a reduction in quality of text that many of us must later read.

Already in discussing this policy, I've had to read far more LLM-generated text than I'd have liked. I had a distinct sensation that I was being asked to re-read the same points as had been previously made, padded out in length by an LLM. We then got confirmation of that at the end of a 792-word email (that's 4 double-spaced pages). I'd find it ironic if the LLM usage policy were changed substantially because of a large number of emails, from a small number of people, with a large contribution of "assistive technology." Everyones' points shold be considered and valued, but there's a risk that the people in favor of text-generating machines may drown out the other voices by word count.

If the preference of GHC developers is to use LLMs, then this policy may be fine. However, I thought the previous policy -- which was very open to LLM contributions but made a statement of preference for a community of human developers speaking to each other through code and prose -- was a much better basis for community standards in a time where LLMs make it very difficult to tell good from "good enough," and another person from "person enough."

- Tom

...

On 07/21/2026 10:15 AM CEST Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:

Friends

There has been a lot of discussion about GHC's LLM policy on this GHC thread ( https://mailman.haskell.org/archives/list/ghc-devs@haskell.org/thread/ZTHFWO... ).

I have made quite few revisions in the light of this and other conversations. Here is the draft again ( https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-...), I hope in a close to final form. Any final thoughts?

thanks

Simon _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

---

ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

Hi Sem, thanks for sharing your thoughts. I've responded inline:

On 07/23/2026 11:54 PM CEST Semen Trygubenko via ghc-devs <ghc-devs@haskell.org> wrote:

I think we could put still more precision of thought into the policy, so that humans and machines can agree on what it requires.

I'm concerned here at the notion of concerning ourselves with writing this policy for machine consumption. The argument earlier was that LLMs were "assistive technology," but now there's a subtle shift to needing to write for them and not only ourselves.

In programming terms, it could follow something like an SSA discipline: define each key concept once and use it consistently, rather than allowing effort, understanding, responsibility, provenance and quality to stand in for one another.

Applying Occam's razor, I think the normative core could be reduced to P1, P2 and R1.

P1 currently says twice that contributors should have invested substantially more time than reviewers. Time spent is difficult to observe and is only an indirect proxy for what matters. A contributor may spend considerable time producing an MR that remains difficult to review, while an assisted workflow may remove typing overhead yet produce a compact, well-understood and well-evidenced change. P1 should therefore specify review readiness rather than an effort ratio.

I might stand alone here among what might be termed the LLM skeptics, but I think your point is sometimes quite true: it's not hard for me to imagine individual changes (likely smaller ones) which require minimal human modification. Time and typing of course don't equal quality. The key, I think, is that more time and effort should be spent by the contributor _than the people reviewing the contribution_. (Maybe a reference to effort in addition to time would make this clearer?) The point being, whatever resources (time, effort, tearing one's hair out) required of the reviewer(s), the contributor should have invested significantly more than that, ensuring the change is as correct as it first appears. Even for trivial changes, reviewers have to make very sure the code is of high quality, and the contribuutor should put this effort in first too.

[...] The contributor must understand, test, simplify and explain the change; the reviewer must understand it sufficiently to stand behind an approval. Manual composition does not demonstrate understanding, just as machine assistance does not disprove it.

If P2 is enforced, P3 appears to add little quality control. A declaration neither establishes understanding nor detects its absence: a conscientious contributor who satisfies P2 gains no additional quality from declaring tool use, while someone willing to evade P2 can also omit the declaration. I would therefore remove P3 and judge contributions directly under P1 and P2.

I see your point, and yet this is precisely the slippery slope that LLM skeptics worry about: once LLM use is officially sanctioned, then the obvious next question is "if I'm writing good code, why should I need to declare how it was written?" The answer, I think, lies in the "overriding principles" section of the proposed document: "We want to build software that is the province of humans, who conceive, understand, develop and refine it through a web of relationships and dialogue." If I see a sentence in a discussion that seems strange to me, and I'm confident it was written by a human, I might spend quite a while considering whether the strangeness lies in a misapprehension of mine, a misapprehension of the author, or some other factor. I might put real effort into crafting a response that attempts to bridge the gap in understanding between two humans. If, instead, this strange sentence might just be generated nonsense, representing nothing that ever resided in any person's mind, then my time and effort has been completely wasted, like writing a longform response to email spam. Even a single nonsense phrase (or a technically-correct-but-robotic one) in an otherwise-fine paragraph is enough to make many of us demoralized and less trusting. The human connection has been breached.

[...] a small version-controlled evidence log containing agreed observations and the minimal metadata needed to interpret them. At each review, the community could retain, revise or reverse the policy in light of that record.

Can you explain how this would work? This seems like a technical solution to a social problem (namely, having a policy that keeps everyone reasonably happy).

I would replace the current writing-focused recommendation with "Use a workflow that develops understanding." Personally writing the final implementation is a useful kata for recall and fluency, but [...other methods...] makes machine-assisted development resemble disciplined human development without treating typing effort as a proxy for thought.

Your point here is both a reasonable position and exactly what concerns me most about efforts to enshrine LLM use as just another way of writing code. The focus on writing every word yourself is not just a "kata for recall." A previous version of this policy proposal put it perfectly, I thought: "writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand." Tens of thousands of commits have been contributed to GHC, each considering the effect of every statement (code or documentation) on future readers. It's not enough for code and documentation to be technically correct; it must be comprehensible and even enjoyable by humans, now and in the future. GHC is an incredible gift of authorship, and it's easy for it to get diluted by the output of machines that have no way of considering the effect on future readers.

Over time, an open list of katas and explicit optimisation criteria --- for example, diff minimisation, naming clarity, abstraction fit, removal of unnecessary complexity, evidence and test quality --- could let humans and machines explore bounded alternatives against values the project has actually chosen, rather than optimise for code production alone.

I again think that even before this policy has been fully hammered out, the slippery slope feels like it's already slipping. Things like diff minimization are only proxies for code quality. The onus here seems to flip, from LLMs helping some developers in the privacy of their personal setups, to the community contorting itself to make things easier for an LLM-assisted workflow.

(7) "P3: Declare direct use of LLMs" and the corresponding section -> delete (declaration neither establishes compliance with P2 nor detects non-compliance)

Detecting non-compliance is not the purpose of this document. An assumption of good faith is healthy.

(8) "R1: Recommendation: write the final version yourself" -> "R1: Recommendation: use a workflow that develops understanding" (states the intended outcome while retaining personal composition as one useful kata)

This change actually highlights why I think the previous version of the proposed LLM policy was much better than the current one: R1's recommendations focus on the benefits for the author (or "author"). The statements of preference ("We strongly prefer human-written code," "We strongly prefer human-written documentation") emphasized the benefits for everyone affected by the author's decisions.

(16) "you must not relay AI-generated text as a substitute for your own judgment" -> "Communication may be machine-assisted, but the sender must have read and understood the message, adopt it as their own position, and be prepared to discuss and defend it. Raw machine output presented for examination rather than adopted as the sender's judgement must be clearly identified." (distinguishes adopted communication from unexamined output)

"Be prepared to discuss and defend it" doesn't seem like much of a requirement if we're allowing unlabeled machine-generated text. I'm sure a person willing to use an LLM can "discuss and defend" anything ad nauseum, but that's not considerate of the person on the other end of the line. (Or of other readers, if both "people" are mostly LLMs!) Cheers, Tom

Just FTR, I’m agreeable with the revised policy Simon shared. Best, Moritz On Fri, Jul 24, 2026 at 4:31 PM Moritz Angermann <moritz.angermann@gmail.com> wrote:

Hi Tom,

This is interesting. We agree even!

...

I think we could put still more precision of thought into the policy, so that humans and machines can agree on what it requires.

I'm concerned here at the notion of concerning ourselves with writing this policy for machine consumption. The argument earlier was that LLMs were "assistive technology," but now there's a subtle shift to needing to write for them and not only ourselves.

I agree, this policy should first and foremost be written for humans not for machines. By us for us.

...

In programming terms, it could follow something like an SSA discipline: define each key concept once and use it consistently, rather than allowing effort, understanding, responsibility, provenance and quality to stand in for one another.

...

Applying Occam's razor, I think the normative core could be reduced to

P1, P2 and R1.

...

P1 currently says twice that contributors should have invested

substantially more time than reviewers. Time spent is difficult to observe and is only an indirect proxy for what matters. A contributor may spend considerable time producing an MR that remains difficult to review, while an assisted workflow may remove typing overhead yet produce a compact, well-understood and well-evidenced change. P1 should therefore specify review readiness rather than an effort ratio.

I might stand alone here among what might be termed the LLM skeptics, but I think your point is sometimes quite true: it's not hard for me to imagine individual changes (likely smaller ones) which require minimal human modification. Time and typing of course don't equal quality.

The key, I think, is that more time and effort should be spent by the contributor _than the people reviewing the contribution_. (Maybe a reference to effort in addition to time would make this clearer?) The point being, whatever resources (time, effort, tearing one's hair out) required of the reviewer(s), the contributor should have invested significantly more than that, ensuring the change is as correct as it first appears. Even for trivial changes, reviewers have to make very sure the code is of high quality, and the contribuutor should put this effort in first too.

I too agree with you here!

...

...

...

[...] The contributor must understand, test, simplify and explain the change; the reviewer must understand it sufficiently to stand behind an approval. Manual composition does not demonstrate understanding, just as machine assistance does not disprove it.

If P2 is enforced, P3 appears to add little quality control. A declaration neither establishes understanding nor detects its absence: a conscientious contributor who satisfies P2 gains no additional quality from declaring tool use, while someone willing to evade P2 can also omit the declaration. I would therefore remove P3 and judge contributions directly under P1 and P2.

I see your point, and yet this is precisely the slippery slope that LLM skeptics worry about: once LLM use is officially sanctioned, then the obvious next question is "if I'm writing good code, why should I need to declare how it was written?"

The answer, I think, lies in the "overriding principles" section of the proposed document: "We want to build software that is the province of humans, who conceive, understand, develop and refine it through a web of relationships and dialogue."

And here as well!

...

If I see a sentence in a discussion that seems strange to me, and I'm

...

confident it was written by a human, I might spend quite a while considering whether the strangeness lies in a misapprehension of mine, a misapprehension of the author, or some other factor. I might put real effort into crafting a response that attempts to bridge the gap in understanding between two humans.

If, instead, this strange sentence might just be generated nonsense, representing nothing that ever resided in any person's mind, then my time and effort has been completely wasted, like writing a longform response to email spam.

This is where we start to disagree.

...

Even a single nonsense phrase (or a technically-correct-but-robotic one)

...

in an otherwise-fine paragraph is enough to make many of us demoralized and less trusting. The human connection has been breached.

And this is where the conflict arises, because I agree with you here that relaid communication is problematic and inauthentic, yet I think this is exactly where we lose good faith and where labeling starts to become an issue. Case in point: one word in this email was changed using assistive technology.

...

[...] a small version-controlled evidence log containing agreed observations and the minimal metadata needed to interpret them. At each review, the community could retain, revise or reverse the policy in light of that record.

Can you explain how this would work? This seems like a technical solution to a social problem (namely, having a policy that keeps everyone reasonably happy).

...

I would replace the current writing-focused recommendation with "Use a workflow that develops understanding." Personally writing the final implementation is a useful kata for recall and fluency, but [...other methods...] makes machine-assisted development resemble disciplined human development without treating typing effort as a proxy for thought.

Your point here is both a reasonable position and exactly what concerns me most about efforts to enshrine LLM use as just another way of writing code. The focus on writing every word yourself is not just a "kata for recall." A previous version of this policy proposal put it perfectly, I thought: "writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand."

Why is this negated by assistive technology. I do not genuinely understand this blanket claim. I don’t even think in English. During my usual days I interact in three to four languages. I’m not even sure I think in words. It’s probably closer to concepts. Sometimes it’s even a mix of word from different languages. At times I have a really hard time recalling the word in a specific language, yet know it from the tip of my tongue in a different.

Don’t we all know at least two programming languages? Concepts translate; letters and words don’t.

...

Tens of thousands of commits have been contributed to GHC, each

...

considering the effect of every statement (code or documentation) on future readers. It's not enough for code and documentation to be technically correct; it must be comprehensible and even enjoyable by humans, now and in the future. GHC is an incredible gift of authorship, and it's easy for it to get diluted by the output of machines that have no way of considering the effect on future readers.

...

Over time, an open list of katas and explicit optimisation criteria --- for example, diff minimisation, naming clarity, abstraction fit, removal of unnecessary complexity, evidence and test quality --- could let humans and machines explore bounded alternatives against values the project has actually chosen, rather than optimise for code production alone.

I again think that even before this policy has been fully hammered out, the slippery slope feels like it's already slipping. Things like diff minimization are only proxies for code quality. The onus here seems to flip, from LLMs helping some developers in the privacy of their personal setups, to the community contorting itself to make things easier for an LLM-assisted workflow.

I still don’t know where this “make things easier for an LLM-assisted workflow” comes from? The ticket that started all this was Ban all LLM contributions <https://gitlab.haskell.org/ghc/ghc/-/work_items/27433#top>. There was no ticket of anyone campaigning to allow all autonomously generated contributions? Nor does anyone come along an open an issue: stop rejecting poor contributions, and allow assisted contributions to be fast tracked for inclusion. Or even campaign for valuing contributors using llm higher than those that don’t. If I missed any such issues, please share them!

...

(7) "P3: Declare direct use of LLMs" and the corresponding section -> delete (declaration neither establishes compliance with P2 nor detects non-compliance)

Detecting non-compliance is not the purpose of this document. An assumption of good faith is healthy.

Where is this assumption of good faith? As soon as there is even the hint of a llm label, it goes out the window?

...

(8) "R1: Recommendation: write the final version yourself" -> "R1: Recommendation: use a workflow that develops understanding" (states the intended outcome while retaining personal composition as one useful kata)

This change actually highlights why I think the previous version of the proposed LLM policy was much better than the current one: R1's recommendations focus on the benefits for the author (or "author"). The statements of preference ("We strongly prefer human-written code," "We strongly prefer human-written documentation") emphasized the benefits for everyone affected by the author's decisions.

I find the current wording in the document quite good. Please help me out for my understanding: (1) what do you define as human-written? (2) why should the ghc project have a strong preference for it? To discourage contributors who might consider using assistive technology in any form or function?

...

(16) "you must not relay AI-generated text as a substitute for your own judgment" -> "Communication may be machine-assisted, but the sender must have read and understood the message, adopt it as their own position, and be prepared to discuss and defend it. Raw machine output presented for examination rather than adopted as the sender's judgement must be clearly identified." (distinguishes adopted communication from unexamined output)

"Be prepared to discuss and defend it" doesn't seem like much of a requirement if we're allowing unlabeled machine-generated text. I'm sure a person willing to use an LLM can "discuss and defend" anything ad nauseum, but that's not considerate of the person on the other end of the line. (Or of other readers, if both "people" are mostly LLMs!)

So we are assuming bad faith now? Are we also assuming that someone who honestly labeled their contribution as assisted will now (of course!) use assistive technology to discuss and defend their contributions ad nauseum?

On the one hand you want people to label their contributions, on the other hand you want to codify a fundamental distrust against those that do label their contributions?!

Isn’t this fundamentally very corrosive to building a trusted community? And if we can’t build trust as a collaborative community, what for is this policy then anyway other than being ignored? I could just not care about this at all. Create MRs like I’m used to, not label them because I just don’t even want to engage in the distraction of whether or not and to which degree I have or have not used assistive technology while conceiving the contribution. Arguably, I would say assistive technology allows me to create higher quality contributions because it allows me to have a conversation with myself and some kind of rubber ducky while working on changes. It also lets me trivially rebase, refactor, split and reorganize my work into much more manageable and digestible chunks. Something that would have cost days and be a lot of busy work to perform. And subsequently I would likely just not have done it and presented the MR as is, after an intense week.

My argument is that measured use of assistive technology leads to more people contributing and a chance of higher quality contributions even. I’m not denying there will be very poor contributions as the result of LLMs as well, but this is a social issue that no matter how many policies we write no policy will be able to address. On the other hand a non welcoming policy can exclude and a judgmental policy even more so.

Some people are more eloquent, some find it easier to find the right words, others don’t; they might still be able to enjoy consuming high quality writing just not be able to produce it themselves at such a level. I can write some Haskell code and keep wondering if this couldn’t be expressed better. What do I do? Ask an llm to try to rewrite this function in a way that simpler, more natural to me, more readable, uses some other idioms I didn’t think of this time around? Help me write this comment more concisely, less roundabout because I simply can’t find the right words to use here myself right now.

Your fear of “slop”, seems to blind you from these opportunities. Maybe they don’t apply to you; in that case I deeply envy you!

Best, Moritz

PS: assistive technology was used when writing this email.

Hi Tom! Am Fr., 24. Juli 2026 um 11:09 Uhr schrieb <amindfv@mailbox.org>:

...

On 07/24/2026 10:12 AM CEST Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:

...

...

A beautiful code base

I wonder if this principle should be balanced with the goal of trying to make a "good compiler": a good tool which is "a joy to use". Specifically I'm thinking about some compiler performance challenges where a pragmatic solution comes at the expense of code elegance: I'm probably overthinking this, but I'd like to avoid a situation where someone points at these principles and says "We can't accept these performance improvements because they make the code less beautiful."

I might be slightly misremembering history here, but I think this has already happened in the past. I recall discussion of a new register allocator(?) that was indeed faster, but much more complex and fiddly. The decision was made to stick with the somewhat-less-efficient "obviously no defects" version, vs. the "no obvious defects" one. In other words, elegance and comprehensibility (by humans) are sometimes as valuable as raw speed.

It should not be a no-brainer that any code change which passes its tests and improves performance must be merged in. A discovery of potential speedup is of course very valuable, but it then needs to be integrated into the way GHC works (including how its human developers' brains work).

I agree that there should be a balance. The current wording just seems unbalanced towards beautiful code.

...

...

If you are reviewing an MR, and any part(s) of your review are generated by an LLM, you should use essentially the same guidelines as above. That is, you must take responsibility for every line of your review (P2);

So I think that it would be worth experimenting with LLM-generated reviews, in order to reduce the load on human reviewers and in order to catch more bugs and performance issues before they make it into the code base. But if we require that the person who prompts the review and reports it on the MR has to take full responsibility for that review, I think that such an experiment is unlikely to stand a chance. In particular, the person providing the review would then probably be required to understand the generated review, and possibly the MR too. As a consequence we would be less likely to get LLM-generated reviews on the more complex MRs where they could be particularly helpful.

I'm not sure if there have been any problems with LLM-generated reviews so far? My suggestion would be to drop the responsibility requirement for clearly marked LLM-generated MR reviews.

Am I reading you correctly that your suggestion is to have code reviews where no human takes full responsibility for the review?

Yes. I think this could be an effective way to reduce the workload on human reviewers and to reduce the number of bugs and perf issues introduced into GHC. My intention is not to replace human review, but to filter out some of the problems with a code contribution before a human reviewer spends their time on it.

...

...

R1 [...] (P2) says that you should take full responsibility for your entire contribution. It is certainly possible to do so by forensically reviewing and revising the output of an LLM, checking that you understand and stand by every line of code, **that there is no clearer or simpler way to achieve the goal; and that every sentence of documentation is accurate, necessary, clear, and fully yours.**

(emphasis mine)

These criteria seem to set the bar very high, and I'm pretty sure that there have been multiple contributions that didn't involve LLMs and that failed to satisfy these criteria, so it seems a bit unfair to impose them now and only on LLM-generated contributions.

When a human makes a statement that they tried their best to be accurate, yet wasn't, that's a great opportunity for a reviewer to transfer knowledge to another person. If an LLM hallucinates, that's purely wasted reviewer time (a precious resource!) with no upside at all. It makes sense that good-faith human mistakes would be treated differently than AI hallucinations.

I guess you have a point there.

...

The undertone I'm getting is "If you make an LLM-generated contribution and it's less than absolutely perfect, you're a bad LLM-jockey and you should feel bad." IMHO this just deters possible contributors, so maybe this paragraph can be toned down a bit for now.

Stepping back for a moment, I find it interesting that the current revision, which seems to have ceded any mention of preference for human-written code, is still seen as too anti-LLM, and the request is to lower the bar even further ("These criteria seem to set the bar very high").

I think the preference for human-written code is still expressed implicitly but loudly in R1.

I'm straining to see how SPJ of all people would make a statement like "you're a bad LLM-jockey and you should feel bad."

Hmm, I'm afraid this "undertone" was mostly my own insecurities speaking. ;) I certainly did not intend to imply that Simon PJ would say anything like that.

...

If the policy turns out to be insufficient to stop the slop, we can still strengthen the requirements.

That's the crux of the issue, though, right? "Insufficient to stop the slop" is in the eye of the beholder. Currently 50% of "voters" on the GHC GitLab feel that _any_ LLM usage is inappropriate. I think it would be valuable to consider how to make a policy that doesn't just please the people who want to use LLMs without too high of a quality bar, but also recognizes that when a person makes an LLM contribution to the GHC GitLab, more than* half of the users there are thinking "I wish you hadn't done that."

I don't think the voters on that issue are a very representative group that this policy should be optimized for. Cheers, Simon

On 7/24/26 4:12 AM, Simon Jakobi via ghc-devs wrote:

I'm not sure if there have been any problems with LLM-generated reviews so far? My suggestion would be to drop the responsibility requirement for clearly marked LLM-generated MR reviews.

The linux kernel has been using an LLM patch review system called "sashiko".  It definitely finds bugs, although not everything it highlights is a real bug. There has been some debate about who should pay the cost of checking its output -- patch approvers (maintainers) or patch submitters -- and whether a response to the review by submitters is optional or required.  Sashiko sometimes find bugs in adjacent code, but submitters don't want to have to fix bugs they didn't create. See: "Debating the role of large language models in the kernel community" -- there's a section called "Email from Sashiko"      https://lwn.net/SubscriberLink/1083275/d5518174ec4dcbcb/ -BenRI

On Fri, Jul 24, 2026 at 10:16 AM Sebastian Graf via ghc-devs < ghc-devs@haskell.org> wrote:

...

Sashiko sometimes find bugs in adjacent code, but submitters don't want to have to fix bugs they didn't create.

I had my fair share of patches reviewed by humans like Simon and others where they caught a bug in adjacent code as well. While I understand the scope creep frustration, I'm convinced that it makes the code base better overall because it means patch authors have to think about how their contribution fits into the design of the component they are touching.

I don't think any of my GHC reviews have done that, but it's happened a few times with Cabal reviews. It's definitely a thing. -- brandon s allbery kf8nh allbery.b@gmail.com

On 07/25/2026 1:07 PM CEST Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:

Hi Ben!

Am Fr., 24. Juli 2026 um 15:52 Uhr schrieb Benjamin Redelings via ghc-devs <ghc-devs@haskell.org>:

...

See: "Debating the role of large language models in the kernel community" -- there's a section called "Email from Sashiko"

https://lwn.net/SubscriberLink/1083275/d5518174ec4dcbcb/

Thanks! That's really interesting!

This bit in particular makes me hopeful (emphasis mine):

...

Ted Ts'o said that Sashiko finds problems that human reviewers might not notice, but that it is not a substitute for human review: "I agree that if reviewers stop doing this, we would be in a world of hurt". **He also said, in a different discussion, that "one of the things that really excites me about Sashiko is that it reduces my workload"**

(Ted Ts'o is the principal maintainer of the ext4 filesystem.)

I agree this quote (including the "world of hurt" part!) are quite relevant. The LWN link was a very enlightening read, both for the positives and negatives of the path the Linux kernel has taken. A couple other quotes worth thinking on: "Our maintainers are not scaling to handle this new flood, and I fear we are going to see some unfortunate things merged. One LLM-driven newcomer recently nearly succeeded in establishing himself as the maintainer of lib/." There's also advice to not "conflat[e] generative AI with analytic uses of AI and actually be really clear about this in public messaging. Sashiko can be compared to other tools, but really - I don't think that comparison is remotely fair with stuff like generative AI. The logistics are just too different, and it really does feel like it gives people the wrong idea." "In Ireland we are seeing AI-driven DC growth consume ever more power - we're at circa 25% of our entire grid generation now (predicted to hit 30% or so in next year or so)! Our government will require new DCs to have their own generation, but that will be largely gas-backed - HCs." "This position is worth reflecting upon for a moment. Developers will, given a chance, describe a number of ethical misgivings about these tools. They will talk about the industry's decision to ignore copyright and the possibility that LLM output violates copyrights. They may mention the environmental costs of untold gigawatts of computing power being directed toward these models, or the effects of data-center construction on the communities around them. Developers may express concerns about how these models are controlled by oligarchs, or about the systemic economic risk posed by the huge portion of the economy being pulled into this industry. They might even spare a moment to commiserate with web-site operators who are struggling to contend with scraping by bot networks." "A tool that dramatically lowers the bar required to generate huge amounts of sniff-test passing slop is in fact, not like other tools. And it does need some level of special consideration, even if it's not being banned." Cheers, Tom

Hi Tom, For transparency upfront: assistive technology was used in parts of the conception and writing of this email. It has now taken more than two hours just to discuss, compose and edit this email alone in the hopes of being clear and easy to understand. I’m making this point specifically to underline that using assistive technology to me does not mean cheap and quick, but rather higher quality. Thank you for your response and the clarifications. As I said before, I am agreeable with the revised policy Simon shared. I think it represents a compromise I can support. There is, however, one part of your response that I still struggle with.

“human-written” means, well, written by a human.

I think we probably have a philosophical disagreement here about what writing or authorship is. To me, understanding, judgement, selection, revision, adoption, and taking responsibility for the result are more important than whether I personally produced every character of the final representation. I don’t think we will necessarily resolve that disagreement here, though. More importantly, the revised policy does not require us to. It focuses on understanding, responsibility, quality, and disclosure, which I find quite reasonable. On this point:

acknowledging that a majority prefer LLMs not to be used.

I’m not convinced this conclusion follows from the GitLab discussion itself. The issue was titled “Ban all LLM contributions”. A discussion framed in this way seems inherently self-selecting to me. People who strongly oppose LLM use have an obvious reason to participate. People who use assistive technology, are indifferent to its use, or simply consider the proposed ban unlikely to succeed may just ignore the issue and let those interested in it discuss it. To be clear: I am _not_ claiming that the opposite conclusion follows. I do not know what the majority of GHC contributors thinks about LLM use. My point is only that I don’t think we can infer the preference of the wider contributor community from the people who chose to participate in this particular issue. However, let us assume for the sake of argument that a majority really does prefer that LLMs are not used. I am still not convinced that the project should therefore add an explicit statement strongly preferring human-written contributions back into the policy. Please bear with me for a deliberately hyperbolic analogy. Suppose I distrust contributions developed on Windows. I might even have technical arguments for this position: - Windows commonly uses CRLF rather than LF line endings. - The GHC runtime system behaves substantially differently on Windows. - Windows has different filesystem and process semantics. - Code developed and tested primarily on Windows may therefore have a different set of failure modes from code developed on Linux. Based on these concerns I open a GitLab issue titled “Ban all Windows-developed contributions”. The issue attracts a number of people who also distrust code developed on Windows. Perhaps half of the people participating in the issue support a complete ban. Others don’t support a ban, but would still prefer that development happens on Linux. Eventually we reach a compromise: - Contributions developed on Windows are permitted. - Contributors are asked to disclose that the contribution was developed on Windows. - Reviewers who distrust Windows-developed code can use this information when deciding whether and how to review it. While I would not personally support such a policy, I can at least understand the argument. It is fundamentally about provenance. Now suppose someone argued that this compromise is missing its heart because it no longer says:

We strongly prefer code developed on Linux.

This is where I think we cross an important line. There is a qualitative difference between providing provenance and the project itself attaching a value judgement to an otherwise acceptable way of contributing. Individual reviewers may distrust Windows-developed contributions. They are free to take that into account, to scrutinise them more closely, or to decline to review them. But stating a strong project-wide preference for Linux-developed code would elevate that distrust from an individual judgement into an institutional one. It would divide equally acceptable contributors into preferred and less-preferred classes solely based on their workflow. The policy would no longer merely say:

Please disclose information that reviewers may consider relevant.

It would also say:

The project considers contributions produced through your workflow less desirable.

I would find that objectionable even if a majority of participants in the “Ban all Windows-developed contributions” issue supported it. This is how I see the proposed preference for human-written contributions as well. I don’t object to the present policy stating expectations around responsibility, understanding, quality, and disclosure. As mentioned above, I am agreeable with the revised policy. What I object to is adding an institutional ranking of otherwise acceptable workflows back into it. One reason I care about this distinction is that I want GHC to remain an open and welcoming project for contributors. To me, project policy does more than document current practice. It also communicates the kind of community we aspire to build and the incentive structures we create for future contributors. Personally, I would like those incentives to encourage openness, honesty, and collaboration. A contributor who openly discloses their workflow, takes responsibility for their contribution, responds thoughtfully to review, and ultimately produces high-quality work is, in my view, doing exactly what I hope our community encourages. By contrast, explicitly declaring one otherwise acceptable workflow to be _ preferred_ over another risks sending a different signal. Even if that is not the intention, it creates the impression that some contributors are viewed as inherently more desirable than others despite meeting the same standards of quality and responsibility. That seems misaligned with the kind of welcoming, collaborative, and trust-based project I would like GHC to be. Perhaps some contributors distrust LLM-assisted code. The present disclosure requirement gives them the information necessary to act on that distrust. I don’t think the project additionally needs to adopt that distrust as its own stated preference. Best, Moritz

Hi Tom, First of all, for transparency: assistive technology was used. Especially to get these tables formatted. Before responding to the substance, I’d like to address one meta point. You wrote that I “don’t seem to have assimilated any of the points of earlier responses.” I don’t think that’s a fair characterisation of my position. I have read every reply carefully, and several have changed my thinking. For example, I started this discussion by questioning whether we even needed an explicit LLM policy. Today, I support Simon’s current draft. Likewise, after Magnus objected to my use of the term “segregation”, I reflected on that criticism, looked into the terminology, and changed how I describe the concern I was trying to express. The reason I have returned to some of the same arguments is therefore not because I ignored the replies, but because I don’t think I have yet succeeded in communicating the distinction I’m trying to draw. Perhaps I have also failed to communicate where I am actually starting from. Roughly speaking, my preferences would look something like this: *Preference* *Position* 1 No policy at all. 2 A lightweight provenance policy (e.g. Ghostty). 3 The current GHC v2 proposal. 4 A more prescriptive policy. 5 A policy expressing an institutional preference between otherwise acceptable workflows. 6 A complete ban. Personally, I would probably choose somewhere between (1) and (2). The current proposal therefore already represents a fairly substantial compromise from my preferred position, and one that I am genuinely happy to support. Interestingly, I think I would even find the Guix proposal [1] easier to agree with than v1 of our proposal, despite disagreeing with many of its conclusions and despite frequently disagreeing with Guix’s broader philosophy. The reason is not that it is less restrictive (it clearly isn’t) but that it explicitly starts with the project’s commitments and values, and only then derives a contribution policy from them. Whether or not one agrees with those values, I find the document internally coherent. The reason I’ve kept reaching for analogies is because I don’t feel I have managed to communicate the distinction I’m trying to draw. The Windows analogy is the closest analogue I have found so far. *GHC proposal* *Windows analogy* LLM-assisted contributions may exhibit different failure modes. Windows-developed contributions may exhibit different failure modes. Contributors disclose LLM assistance. Contributors disclose Windows development. Reviewers may use that information. Reviewers may use that information. *We strongly prefer human-written contributions.* *We strongly prefer Linux-developed contributions.* Up to the third row I can understand the rationale, even if I might not personally agree with every aspect of it. It is the fourth row where I think the character of the policy changes fundamentally. At that point we are no longer talking about provenance. We are expressing an institutional preference between otherwise acceptable workflows. This is the distinction I have been trying to make throughout the discussion. I also realize that analogies can be misleading, and I don’t claim this one is perfect. However, I do think it differs materially from my earlier Emacs/Vim and similar analogies. The point of the Windows analogy is *not* that Windows and LLMs are similar technologies. Rather, it is intended to isolate the policy mechanism I have been trying to discuss throughout this thread: - a workflow is claimed to exhibit different failure modes, - contributors disclose that workflow, - reviewers are free to act on that information, and - the project expresses an institutionalized preference for an alternative workflow. If you believe the analogy fails, I would genuinely appreciate it if you could point out where this structural correspondence breaks down. I suspect that would help me understand your position much better. Julian has probably come closest to engaging with it directly. While I disagree with his conclusion, I genuinely appreciate that he stated his position explicitly. It’s also one of the reasons I deeply value, respect and appreciate Julian. is currently roughly this: - *Julian:* to protect people who cannot or will not use LLMs, and to prevent LLM use from becoming a de facto expectation. - *Tom:* because merged artifacts and project discussion affect everyone; disclosure and individual opt-out cannot fully insulate people who object to LLM-assisted contributions. - *Simon (my understanding):* because personally composing code and documentation is itself believed to encourage engagement, restraint, understanding, and better human communication. Even if I grant all of these concerns, I still struggle to understand why an institutional preference between otherwise acceptable workflows is the appropriate and proportionate mechanism, rather than limiting the policy to provenance, responsibility, quality, direct human communication, and reviewer choice. Perhaps this is where the discussion has been talking past itself all along. It increasingly feels to me that I am arguing against what I would describe as a *soft-ban* policy: not an outright prohibition of LLM-assisted contributions, but a policy that nevertheless creates enough stigma, additional disclosure requirements, institutional distrust, and stated preference that contributors are expected to infer the "correct" workflow. If that is indeed the intended direction, I would rather we say so explicitly and discuss that position on its own merits. If, on the other hand, LLM-assisted contributions are considered acceptable provided they satisfy the project's requirements around disclosure, understanding, responsibility, and quality, then I still do not understand why the project itself should additionally express a preference for a different workflow. Best, Moritz — [1] https://codeberg.org/guix/guix-consensus-documents/raw/commit/a24520c4147ffd... On Sat, Jul 25, 2026 at 2:49 PM <amindfv@mailbox.org> wrote:

Hi Moritz,

Many of your paragraphs here seem to reiterate arguments you've made previously. Additionally, you don't seem to have assimilated any of the points of earlier responses. For example, several days ago you equated pro- and anti-LLM positions with developers debating using Emacs vs. Vim. Several people responded with why that wasn't a helpful analogy for them, and yet in this email you're equating the debate with Linux vs. Windows, seeming not to take on board any of their points.

At this point I think we should focus only on finding how to "disagree agreeably."

I've responded to a few of your points inline:

...

On 07/25/2026 4:35 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:

...

As I said before, I am agreeable with the revised policy Simon shared. I think it represents a compromise I can support.

Unfortunately it does not represent a compromise that I and many others can. Specifically, it seems slanted in favor of LLM users doing whatever they like, provided they disclose their LLM usage.

...

There is, however, one part of your response that I still struggle with.

...

“human-written” means, well, written by a human. I think we probably have a philosophical disagreement here about what writing or authorship is. To me, understanding, judgement, selection, revision, adoption, and taking responsibility for the result are more important than whether I personally produced every character of the final representation. I don’t think we will necessarily resolve that disagreement here, though. More importantly, the revised policy does not require us to. It focuses on understanding, responsibility, quality, and disclosure, which I find quite reasonable.

Please recognize, though, that what you find quite reasonable is exactly the part that I and others disagree with. We haven't found a compromise position by adopting criteria that ignores usage of LLM (other than disclosure).

...

On this point:

...

acknowledging that a majority prefer LLMs not to be used. I’m not convinced this conclusion follows from the GitLab discussion itself. The issue was titled “Ban all LLM contributions”. A discussion framed in this way seems inherently self-selecting to me. People who strongly oppose LLM use have an obvious reason to participate. People who use assistive technology, are indifferent to its use, or simply consider the proposed ban unlikely to succeed may just ignore the issue and let those interested in it discuss it. To be clear: I am _not_ claiming that the opposite conclusion follows. I do not know what the majority of GHC contributors thinks about LLM use. My point is only that I don’t think we can infer the preference of the wider contributor community from the people who chose to participate in this particular issue.

This seems like motivated reasoning. Why should we doubt that pro-LLM users would be at least as likely to vote on an issue that would ban their preferred workflow?

Occam's razor is that around 50% of people who care about the issue, want to ban LLM usage entirely.

You will notice, by the way, that my name is not among those voting to ban usage. This is because I feel GHC needs to move forward with a compromise that doesn't leave people feeling totally left out. Unfortunately, the current draft does this in my view, in the other direction.

...

I would find that objectionable even if a majority of participants in the “Ban all Windows-developed contributions” issue supported it. This is how I see the proposed preference for human-written contributions as well. I don’t object to the present policy stating expectations around responsibility, understanding, quality, and disclosure. As mentioned above, I am agreeable with the revised policy.

What I object to is adding an institutional ranking of otherwise acceptable workflows back into it.

One reason I care about this distinction is that I want GHC to remain an open and welcoming project for contributors.

You seem not to recognize that we cannot have our cake and eat it too. For each person who'd say "Yippee! I can use LLMs!" there is another person who says "Oh no, discussion on important issues is LLM-generated. I don't want to read that."

I'm seeking to find a compromise position here, but for that to work, both sides need to recognize that there is no free lunch: no solution that will be maximally welcoming for all people of all stripes.

...

By contrast, explicitly declaring one otherwise acceptable workflow to be _preferred_ over another risks sending a different signal. Even if that is not the intention, it creates the impression that some contributors are viewed as inherently more desirable than others despite meeting the same standards of quality and responsibility. That seems misaligned with the kind of welcoming, collaborative, and trust-based project I would like GHC to be. Perhaps some contributors distrust LLM-assisted code. The present disclosure requirement gives them the information necessary to act on that distrust. I don’t think the project additionally needs to adopt that distrust as its own stated preference.

Another "no free lunch" situation: embedded in your view here ("The present disclosure requirement gives them the information necessary to act on that distrust") is that a person who dislikes LLM contributions can remain unaffected by them simply by not reading LLM code or documentation. Your proposal (everybody develops how they please; people who don't like it shouldn't participate) sidelines people and excludes them from meaningful discussion and information about GHC's future. And of course, they'll end up reading LLM-generated code and/or documentation if it's merged in.

As soon as you recognize there's a balancing act here, I think you'll understand more where many of us are coming from.

Thanks, Tom

Tom, your latest reply helped me understand something I hadn’t appreciated before. When I wrote “otherwise acceptable workflows,” you replied that this is exactly the point under discussion.

"Otherwise acceptable" is, of course, the point of discussion here.

Does that mean that, in your view, LLM-assisted authorship is *not* an otherwise acceptable workflow, even when the contributor satisfies all of the policy’s requirements around disclosure, understanding, responsibility, and quality? If so, I think I finally understand why we have been talking past each other. In that case, the disclosure requirement is no longer merely about provenance; it identifies contributions produced by a workflow that the project itself does not regard as fully acceptable. Best, Moritz On Sun, Jul 26, 2026 at 6:31 AM <amindfv@mailbox.org> wrote:

Moritz, your LLM-generated table and bullet points are almost an exact rephrase of your previous email's points about Windows vs. Linux. Let's try to "disagree agreeably." I don't think it's helpful for me to rephrase my responses as well.

...

On 07/25/2026 1:38 PM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:

...

At that point we are no longer talking about provenance. We are expressing an institutional preference between otherwise acceptable workflows.

"Otherwise acceptable" is, of course, the point of discussion here.

...

If you believe the analogy fails, I would genuinely appreciate it if you could point out where this structural correspondence breaks down. I suspect that would help me understand your position much better.

If you search this email thread for the word "emacs," you can find other people explaining why they find the analogy unhelpful. To one person's response you wrote "Here we disagree; but this would likely end up splitting hairs [...] and I have no interest in debating that." So let's agree to disagree!

Thanks, Tom

Thank you for your time Tom, The disagreement (as I understand) is this: My view: Policies should define the minimum framework necessary for collaboration between people who disagree. My understanding of your view: Policies should also reflect the community’s collective values and preferences. In that case let me bring up my previous analogy one more time, and let me know if you in principle agree with the following or not, and if not, why not? Suppose that 50% of the community strongly preferred that all contributors develop on Linux, or that all documentation be written manually rather than with grammar or translation tools. Would that fact alone justify expressing those preferences in project policy? Best, Moritz On Sun, Jul 26, 2026 at 7:31 AM <amindfv@mailbox.org> wrote:

...

On 07/26/2026 1:57 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:

Tom, your latest reply helped me understand something I hadn’t appreciated before.

When I wrote “otherwise acceptable workflows,” you replied that this is exactly the point under discussion.

...

"Otherwise acceptable" is, of course, the point of discussion here.

Does that mean that, in your view, LLM-assisted authorship is not an otherwise acceptable workflow, even when the contributor satisfies all of the policy’s requirements around disclosure, understanding, responsibility, and quality?

If so, I think I finally understand why we have been talking past each other. In that case, the disclosure requirement is no longer merely about provenance; it identifies contributions produced by a workflow that the project itself does not regard as fully acceptable.

I'll just quote myself from a previous email:

"Currently 50% of 'voters' on the GHC GitLab feel that _any_ LLM usage is inappropriate. I think it would be valuable to consider how to make a policy that doesn't just please the people who want to use LLMs [...], but also recognizes that when a person makes an LLM contribution to the GHC GitLab, more than* half of the users there are thinking 'I wish you hadn't done that.'"

Saying "the contributor satisfies all of the policy’s requirements around disclosure, understanding, responsibility, and quality" puts the cart before the horse: policies about quality and understanding will be influenced by the community's feelings about LLMs.

Cheers, Tom

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

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 <mailto:amindfv@mailbox.org>> wrote:

...

...

On 07/26/2026 8:57 AM CEST Moritz Angermann <moritz.angermann@gmail.com <mailto: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

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 <mailto: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 <mailto: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 <mailto:amindfv@mailbox.org>> wrote:

...

...

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

On 07/26/2026 11:48 AM CEST Moritz Angermann via ghc-devs <ghc-devs@haskell.org> wrote:

I cannot in good conscience contribute to, or advocate for, a project that institutionally ranks otherwise acceptable contributors or their work in this way.

So, you're willing to change your (and your team's) contribution to a project based on your personal morals, and you are advocating changes to GHC's contribution policy based on your personal sense of morality as well. Can you spare a bit of empathy for people who are concerned about, e.g. global warming or loss of drinking water due to LLMs (not to mention code quality)?

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.

With this sentence you reveal you haven't assimilated, at all, the point Jaro made in his 3-sentence email. (Nor the one I and several others have written previously.) Instead you wrote a 392-word reply, which we all had to read to realize you were just restating your points from your _34 other emails_ on this list. The next-most-prolific contributor here is SPJ with 15 emails. - Tom

Just want to chime in and say that Moritz is not the only contributor who wants to use LLMs in the future. Just because he seems to be the only pro-LLM person commenting in what I personally perceive as a very unproductive discussion does not mean that there aren't any others. It is unreasonable to take representation in this discussion as a proxy for how many people are against or in favour of the policy. Aside from that, I share the post-apocalyptic concerns about LLMs (climate, alignment), however it is completely baffling to me how banning LLMs from GHC development would help with that. An analogy: It's a bit like wanting to prevent a nuclear war between the US and China by vetoing nuclear power plants in the UK. I'm not advocating for the latter either, but it is not a problem you can solve bottom-up. I think people just have to accept their powerlessness in this matter and hope for the best, or establish more effective political channels. GHC development should not become a casualty to the new LLM-enabled economics in this process. That would not solve any problems that LLMs could potentially inflict on human kind. Moritz Angermann via ghc-devs <ghc-devs@haskell.org> schrieb am Mo., 27. Juli 2026, 01:18:

...

I cannot in good conscience contribute to, or advocate for, a project that institutionally ranks otherwise acceptable contributors or their work in this way.

So, you're willing to change your (and your team's) contribution to a project based on your personal morals, and you are advocating changes to GHC's contribution policy based on your personal sense of morality as well.

I see you still have not understood the point I have been arguing all along. I can not in good conscience contribute, advocate or support a project that institutionalized discrimination. Whether that discrimination is based on gender, workflow, religion, language, skin colour, disabilities, intelligence, ...

My whole argument is fundamentally about _any_ form of discrimination, and orthogonal to LLMs, although this particular discussion has centered around LLMs. I somehow doubt you are ok with discrimination.

So, you're willing to change your (and your team's) contribution to a

...

project based on your personal morals, and you are advocating changes to GHC's contribution policy based on your personal sense of morality as well. Can you spare a bit of empathy for people who are concerned about, e.g. global warming or loss of drinking water due to LLMs

Yes, I can spare empathy, those are valid concerns. Again, discrimination does not fix this in my view. It does not move us closer to less LLM use, just because the GHC project prefers one workflow over another. The only way forward for that would be lobbying politics to prohibit the creation of Data Centers (in the context of LLMs). I don't see how "human written" (but you can use LLMs for research, ...) moves the needle here. Can you explain how the changes you have been arguing for address this issue?

...

(not to mention code quality)?

Have you read my emails? Where have I argued for lower code quality? Where have I argued for "slop slinging"? If anything I've repeatedly argued for higher quality and against poor drive-by contributions. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

On Mon, Jul 27, 2026 at 07:53:04AM +0200, Sebastian Graf via ghc-devs wrote:

Just want to chime in and say that Moritz is not the only contributor who wants to use LLMs in the future.

Holding up my hand as another example. I'm not actually a GHC contributor but I would like to be in the future. The only way I will be is if I am allowed to use agentic coding in my contributions. In fact the same goes for almost any contribution I make to any codebase, open source or otherwise. My life is simply too short to not to use tools which reduce the effort expended to achieve a particular result. If I'm not allowed to work in my preferred way in GHC I'll direct my efforts elsewhere. By way of example, here is an ecosystem contribution (bug report with reproducer and precise location of where the fix needs to be applied): https://github.com/qrilka/xlsx/issues/205 The bug was discovered from a much higher level bug report entirely but an analysis carred out by a coding agent. The precise location of the bug was discovered by the coding agent. The minimal reproducer was written entirely by a coding agent. I had to patch this locally as part of my job. Whether I reported it upstream was up to me. My view is that the pro-social choice was to report it upstream so it could be patched to everyone's benefit. I am glad the maintainers of that package does not have a policy that discouraged me from making that contribution. Tom

On Mon, Jul 27, 2026 at 11:57:49AM +0200, Hécate via ghc-devs wrote:

In your case I'd say it's even more important that you do *not * use an LLM to give you answers about questions you may have regarding GHC's internal, as you will be unable to detect if they are correct until after it's too late (or someone else points it out).

I think you are raising a valid risk. In my particular case I am confident enough in my use of the tool that my use of it will help rather than hinder in that particular endeavour. I think your "you will be unable ... until after it's too late" is too strong a claim. I can only speak for myself rather than others. To others, I would suggest that, rather than avoiding using such a tool because of that risk, that they instead learn to use the tool in ways that will be an overall benefit rather than a detriment. If, despite their efforts, they decide that using a tool can only be overall detrimental to them, so they will not continue using one, then so be it. Tom

On Sun, Jul 26, 2026 at 11:14:44PM +0200, amindfv--- via ghc-devs wrote:

people who are concerned about, e.g. global warming or loss of drinking water due to LLMs

I would invite people who are concerned about global warming or water usage of LLMs to explain what they disagree with in Andy Masley's analysis. He ultimately concludes that the impact on water and CO2 by my use of LLMs (all day every working day) is negligible compared to the impact by other aspects of my daily life: https://blog.andymasley.com/p/a-cheat-sheet-for-conversations-about?open=fal... Tom

We don't even have to bother with the detailed math. For the scale we care about it holds that: * compute ~= energy * We can fit more compute into a data centre each year through better tech. The only reason to build data centres on mass is then to scale compute massively, which increases energy consumption accordingly. On 27/07/2026 13:07, Andrei Borzenkov via ghc-devs wrote:

Hi, Tom!

The very core metric of this blogpost is questionable:

...

Throughout this post I’ll assume the average ChatGPT query uses 0.3 Wh of energy, about the same as a Google search used in 2009 <https://googleblog.blogspot.com/2009/01/powering-google-search.html>. Here’s a summary of why 0.3 Wh is the most reasonable guess right now <https://www.sustainabilitybynumbers.com/p/ai-footprint-august-2025>.

He's listing a bunch of sources in the summary:

...

Sam Altman, CEO of OpenAI, published a blog post <https://blog.samaltman.com/the-gentle-singularity>in June covering a range of AI updates. In it, he casually mentioned that a standard text query uses *0.34 Wh of electricity*. Remember, that’s close to the updated estimate that EpochAI came up with <https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use>(0.3 Wh),

...

Mistral AI, another AI company, conducted an environmental analysis <https://mistral.ai/news/our-contribution-to-a-global-environmental-standard-for-ai>of its LLMs. ... Overall, the impacts were low: just 1 gram of CO_2 /per page of text/generated

...

This article in MIT Technology Review — We did the math on AI’s energy footprint. Here’s the story you haven’t heard <https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage-climate-footprint-big-tech/>— was published in May, and was a good overview of many of the complexities. Some stand-out numbers: it quoted an estimate of around *0.93 Wh (let’s call it 1 Wh)*for an average Llama text query response.

And concludes with this:

...

The 3 Wh estimate in my previous article was probably too high, and something a little lower — possibly as low as 0.3 Wh — seems possible.

That looks like a bold hand-waving to my taste. The author dropped MIT estimation at all and fully agreed with Sam Altman (very questionable source of information). Mistral AI had relatively small models at a time (around 70B) and can't be used to estimate GPT.

EpochAI uses a lot of indirect measures for their own research and base their estimation on a long ago outdated model *GPT-4o* with "200 billion total parameters (likely between 100 and 400 billion)." ©. The models are way way larger now, even openweight models hit 1 to 3 trillion parameters and have 1 million token context windows.

Both EpochAI and Mistral AI base their estimations on the per-page basis

...

I assume that a typical number of output tokens per query is 500 tokens (~400 words, or roughly a full page of typed text). This is somewhat pessimistic—for example, Chiang et al. <https://arxiv.org/abs/2403.04132> found an average response length of 261 tokens in a dataset of chatbot conversations

Agentic AIs do not hold this assumption. LLMs now read huge chunks of files, spawn research subagents, write files with thousands lines of code and each model supports <think></think> blocks where they echo and rephrase information multiple times. One agentic session can easily pass 100k tokens of context and context lookups have quadratic complexity. Plus closed LLMs from top AI labs hide their thinking proccess from the end user.

I can't say if "0.3 Wh of electicity" is a wrong estimation for LLM query, but I don't believe this blogpost estimation because sources of this metric do not look good.

Cheers, Andrei.

On 27.07.2026 14:35, Tom Ellis via ghc-devs wrote:

...

On Sun, Jul 26, 2026 at 11:14:44PM +0200, amindfv--- via ghc-devs wrote:

...

people who are concerned about, e.g. global warming or loss of drinking water due to LLMs I would invite people who are concerned about global warming or water usage of LLMs to explain what they disagree with in Andy Masley's analysis. He ultimately concludes that the impact on water and CO2 by my use of LLMs (all day every working day) is negligible compared to the impact by other aspects of my daily life:

https://blog.andymasley.com/p/a-cheat-sheet-for-conversations-about?open=fal...

Tom _______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

Hi Tom, Technological improvements increasing the efficiency of a resource do not lead to a fall but to a rise in total consumption of that resources. That's a well-known effect. See e.g. https://en.wikipedia.org/wiki/Jevons_paradox.

But how much?

There are countless projections and surveys like the one shared by Andrei. We fortunately do not have to rely on bloggers with no considerable qualification in that area. Best Magnus On 7/27/26 15:27, Tom Ellis via ghc-devs wrote:

On Mon, Jul 27, 2026 at 02:22:07PM +0200, Andreas Klebinger via ghc-devs wrote:

...

For the scale we care about it holds that:

* compute ~= energy Technological progress in silicon manufacturing leads to smaller chips, which send signals over smaller distances and are therefore both faster and more energy efficient. How do you reconcile this with your claim?

Still, I don't think that claim is needed for this one:

...

The only reason to build data centres on mass is then to scale compute massively, which increases energy consumption accordingly. I certainly have no objection to the claim that more energy is going into AI workloads as time goes on. But how much? And is it an *unjustifiable* amount? That's the question that needs to be answered.

Tom _______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org

I've done a bit of research now, mainly based on Jegham et al. "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference" They list the energy consumption of DeepSeek-R1 (671B params) to be ~29 kW at 10k input token and 1.5k output token scales (Table 4). I think it is reasonable to expect current frontier models to at least match that since the models seem to have gotten larger and I think contexts are generally also larger in the use case we're considering (large chunks of GHC would have to get loaded into the context presumably). From the same study, most datacenters use around 0.3 kg of CO2 equivalent per kWh (Table 1), so DeepSeek R1 uses about 8.7 kgCO2e/h. That means using a single agent for ~400 hours is equivalent to a return flight from Austin Texas to Zurich (3500 kg CO2e; source: online tool), which I find an unjustifiable amount of emissions, but I guess some members of the community do already make such a trip once a year. I think this shows that it is likely that heavy use of LLMs causes significant emissions exceeding that of yearly transatlantic flights. Cheers, Jaro

On 27 Jul 2026, at 15:46, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:

On Mon, Jul 27, 2026 at 03:32:45PM +0200, Magnus Viernickel via ghc-devs wrote:

...

Technological improvements increasing the efficiency of a resource do not lead to a fall but to a rise in total consumption of that resources.

That's a well-known effect. See e.g. https://en.wikipedia.org/wiki/Jevons_paradox.

Yes indeed. I do not dispute that the amount of energy going into AI usages is increasing both in relative and absolute terms.

...

...

But how much?

There are countless projections and surveys like the one shared by Andrei. We fortunately do not have to rely on bloggers with no considerable qualification in that area.

That's good to hear, and I would welcome someone making a numeric claim and backing it up with citations. I think that would be a valuable contribution to the discussion here.

To be clear: *I* am not trying to make a claim, nor refute someone else's claim. I am pointing out that no such claim has been made precise nor substantiated in this discussion! If someone believes strongly that AI energy use should be factored into GHC's LLM policy then the responsibility is theirs to make a precise and substantiated claim. If claims about AI energy usage are not precise and substantiated then I don't see why they should factor into the policy decision.

Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

Right, so my calculation only works if you assume 1000 reasoning requests per hour, which is admittedly unrealistic. And unfortunately I can't find the raw data for the paper, so I can't calculate the actual value.

On 29 Jul 2026, at 12:46, Luite Stegeman via ghc-devs <stegeman@gmail.com> wrote:

The table doesn't say 29kW, it says 29Wh for 1500 output tokens with 10k input tokens, i.e. energy per token, not power.

On Wed, Jul 29, 2026 at 12:12 PM Jaro Reinders via ghc-devs <ghc-devs@haskell.org> wrote:

...

I've done a bit of research now, mainly based on Jegham et al. "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference"

They list the energy consumption of DeepSeek-R1 (671B params) to be ~29 kW at 10k input token and 1.5k output token scales (Table 4). I think it is reasonable to expect current frontier models to at least match that since the models seem to have gotten larger and I think contexts are generally also larger in the use case we're considering (large chunks of GHC would have to get loaded into the context presumably).

...

From the same study, most datacenters use around 0.3 kg of CO2 equivalent per kWh (Table 1), so DeepSeek R1 uses about 8.7 kgCO2e/h.

That means using a single agent for ~400 hours is equivalent to a return flight from Austin Texas to Zurich (3500 kg CO2e; source: online tool), which I find an unjustifiable amount of emissions, but I guess some members of the community do already make such a trip once a year.

I think this shows that it is likely that heavy use of LLMs causes significant emissions exceeding that of yearly transatlantic flights.

Cheers,

Jaro

...

On 27 Jul 2026, at 15:46, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:

On Mon, Jul 27, 2026 at 03:32:45PM +0200, Magnus Viernickel via ghc-devs wrote:

...

Technological improvements increasing the efficiency of a resource do not lead to a fall but to a rise in total consumption of that resources.

That's a well-known effect. See e.g. https://en.wikipedia.org/wiki/Jevons_paradox.

Yes indeed. I do not dispute that the amount of energy going into AI usages is increasing both in relative and absolute terms.

...

...

But how much?

There are countless projections and surveys like the one shared by Andrei. We fortunately do not have to rely on bloggers with no considerable qualification in that area.

That's good to hear, and I would welcome someone making a numeric claim and backing it up with citations. I think that would be a valuable contribution to the discussion here.

To be clear: *I* am not trying to make a claim, nor refute someone else's claim. I am pointing out that no such claim has been made precise nor substantiated in this discussion! If someone believes strongly that AI energy use should be factored into GHC's LLM policy then the responsibility is theirs to make a precise and substantiated claim. If claims about AI energy usage are not precise and substantiated then I don't see why they should factor into the policy decision.

Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

I found the data and it includes newer models like GPT 5: https://github.com/Nidhal-Jegham/HowHungryisAIDashboard/blob/main/HHAI%20Sna... It lists the data center efficiency (pue) as 1.12, gpu power usage (pgpu) as 5.6 kW, non gpu power usage (pngpu) as 4.6 kW, lower bound on gpu utilization (ugpu) as 0.055, and non gpu utilization (ungpu) as 0.0625. Using the formula E = pue * (pgpu * ugpu + pngpu * ungpu), we find that GPT 5 uses about 0.67 kW to run, but the CO2e/kW of GPT is also higher at 0.34. We come to 228 grams CO2e per hour, or about 15000 hours (less than two years of continuous use) for a transatlantic return flight equivalent. It is not quite a return flight every year, but also not a once in a lifetime thing, especially if you start using multiple agents at once. Cheers, Jaro

On 29 Jul 2026, at 13:31, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:

...

On Wed, Jul 29, 2026 at 12:12 PM Jaro Reinders via ghc-devs <ghc-devs@haskell.org> wrote:

...

I've done a bit of research now, mainly based on Jegham et al. "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference"

They list the energy consumption of DeepSeek-R1 (671B params) to be ~29 kW at 10k input token and 1.5k output token scales

On Wed, Jul 29, 2026 at 12:45:51PM +0200, Luite Stegeman via ghc-devs wrote:

...

The table doesn't say 29kW, it says 29Wh for 1500 output tokens with 10k input tokens, i.e. energy per token, not power.

That's right.

Here's a different figure: median energy per query of 0.34 Wh[1]

My *guess* is that an *extremely* intense user of a typical coding agent with chain of thought might use about one query per 10 seconds[2], which means a power of

0.34 Wh * 3600 s/h / 10s = 122.4Wh / h ~= 0.12kWh / h

This is 200 times less than the figure you quoted, so even if it's off by an order of magnitude the conclusion will still be that agentic coding emits far less CO2 than your analysis.

...

...

...

From the same study, most datacenters use around 0.3 kg of CO2 equivalent per kWh (Table 1), so DeepSeek R1 uses about 8.7 kgCO2e/h.

Using my 0.12kWh / h above, this would be

0.3 kg CO2e / kWh * 0.12 kWh / h = 0.036 kg CO2e / h

...

...

That means using a single agent for ~400 hours is equivalent to a return flight from Austin Texas to Zurich (3500 kg CO2e; source: online tool), which I find an unjustifiable amount of emissions, but I guess some members of the community do already make such a trip once a year.

Based on 3500 kg CO2e per flight, this is the equivalent of

3500 kg CO2e per flight / (0.036 kg CO2e / h) = 97,000 hours per flight equivalent = 48 years per flight equivalent (2000 hours per year) = 1 long and hopefully productive career

...

...

I think this shows that it is likely that heavy use of LLMs causes significant emissions exceeding that of yearly transatlantic flights.

My analysis shows that it's nowhere near. It's more like one lifetime of using agentic coding is equivalent to taking one transatlantic flight in a lifetime.

Now of course this may be nonetheless too much already. Energy use and carbon emissions of agentic coding will rise. Some of my base figures may be wrong (but they'd have to be *very* wrong for agentic coding to be worse than other activities we take for granted).

And I may have made a mistake in my calculations. I would welcome a correction.

Tom

[1] https://www.microsoft.com/en-us/research/publication/energy-use-of-ai-infere...

[2] Probably a massive overestimate (maybe by 10x?): I don't think I've ever reached that sustained pace -- Moritz might have! -- let alone the whole working day every day _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

On Wed, Jul 29, 2026 at 01:00:27PM +0100, Tom Ellis via ghc-devs wrote:

Indeed. The total energy use and carbon emissions of agentic coding will rise.

To set myself the standard of being precise with terms: The total *power* use and *rate of* carbon emissions of *an average user's use of* agentic coding will rise. Tom

On Wed, Jul 29, 2026 at 12:18:39PM +0000, Jaro Reinders via ghc-devs wrote:

Is it uncommon to use LLMs overnight to churn away at some task?

Some people do so. I know some of my colleagues do, but I don't know how often. I've never done so.

Also, in an attempt to extrapolate to newer models, we can compare open model inference pricing ... we can conclude that frontier models require 4.3x more energy to run than GPT 5. If that is the case the number is down to 3500 hours of full time LLM use for 1 transatlantic return flight equivalent.

Perhaps, or perhaps people use a better, but more expensive, model less? Tom

On Mon, Jul 27, 2026 at 03:07:52PM +0400, Andrei Borzenkov via ghc-devs wrote:

I can't say if "0.3 Wh of electicity" is a wrong estimation for LLM query, but I don't believe this blogpost estimation because sources of this metric do not look good.

Very well. The linked article is also a year old and LLM usage has increased considerably in the intervening period, so it doesn't make an irrefutable point. But I'm not using it to justify any course of action on the part of GHC leadership! By contrast, I interpreted Tom amindfv---'s comment in the message I replied to as suggesting that some people think the energy and water use of LLMs is sufficiently high that LLM-based development *should be* forbidden in GHC. If that's really so then I think they should substantiate that with some hard numbers. (I may have misunderstood Tom amindfv---, of course. Maybe he really was simply saying that it would be nice to show empathy to people's fears even if they are expressed without substantiation. But of course then that shouldn't affect the substance of the policy.) Tom

Thanks to everyone who has contributed to this thread. Lots of good, civil discussion, along with robust disagreement. I have made lots of (mostly small) edits in response. Some more reflections below Simon Here are some of my personal thoughts - *Beautiful code.* Yes, every enhancement to GHC comes with a complexity cost; we have to make a judgement about whether the benefit pays for the (permanent) cost in terms of complexity. I have updated the principle to say this briefly. - *Agnostic*. Some thoughtful people believe that we should have a blanket ban on LLMs. Others, equally thoughtful, believe that they have a helpful role to play in software development. I do not believe that we have anything close to a consensus on this, so I have framed the draft policy so that it is explicitly agnostic about whether LLMs are, in themselves, good or bad. That will please no one, but the alternatives seem worse to me. - *Principles*. In contrast there seems to be universal agreement about the principles of (a) a human conversation among developers and (b) a high-quality beautiful code base. No one at all is arguing for blurting large quantities of machine-generated slop into GHC's code base or documentation, even if it passes the regression tests and superficial sniff-testing. - I personally do not want to express or institutionalise a second-class status for LLM-assisted contributions. So I take Moritz's concerns on this score seriously. But I do want to express a very strong desire for human judgement, responsibility, effort, and responsibility in GHC contributions. (And Moritz does too.) How best to express that pair of desires? It seems difficult to find language that is acceptable to all, despite our agreement on the principles this language expresses. My proposal is to - *Require *full responsibility. For now at least I have settled on "human authorship" as a term to express this idea strongly -- adding language to say that (in this context) "authorship" does not mean "typed every word". But it does mean reviewing every word and almost certainly revising many of them. - *Recommend *writing it yourself. I am worried that, even with the best of intentions, I might submit code that I had not forensically reviewed in the above way. Time is short, I want to get this done, honestly it looks pretty good etc. I think that the discipline of writing it out myself would force me to think. Is this duplication necessary? Why does this function need its third parameter? But that's just me. Mindful that others may work differently, I have framed it as a recommendation only. I have adjusted the language a bit in the light of the conversation of the last few days. - *LLM-only reviews*. The policy explicitly says that if an LLM helps you to find a bug, with a repro case, it's fine to report the bug even if you don't understand its cause or how to fix it; that is the case with many human-reported bugs. But I am personally much more sceptical about LLM-generated *reviews *(of MRs) where no human has forensically checked the review. There may be good content in it; or it may just be distracting. Perhaps in due course we'll want a channel for LLM-only reviews; but in the meantime the proposal asks that reviews follow (P2). - *Attribution*. I continue to think that (P3) is important: we should be clear if an LLM has written any part of the material we are asking someone to review. That is transparent, gives us helpful data, gives the reviewer a bit more context, and helps those who want to avoid LLMs altogether. On Sun, 26 Jul 2026 at 19:35, Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:

On Sun, Jul 26, 2026 at 09:12:19AM +0000, Jaro Reinders via ghc-devs wrote:

...

We all seem to recognize that interacting with LLM generated code or documentation makes a significant number of contributors uncomfortable.

A very interesting claim. Whatever could it possibly mean?

Do you mean those contributors are uncomfortable with some intrinsic property of the code (or documentation) that LLMs tend to generate? Or merely by its provenenance, i.e. an extrinsic property?

If the former, can such users reliably distinguish LLM-generated code? Can theydistinguish LLM-generated code that has been highly human edited, or even entirely rewritten? If a human can generate code with an LLM and then edit it sufficiently carefully that it's indistinguishable from code that had no LLM involvement, would those contributors be comfortable with such code?

If the latter, does it mean that those contributors are simply uncomfortable with the *knowledge* that some code was LLM-generated, even if they can't independently tell it was LLM-generated? Perhaps it's a bit like knowing that some code was written by someone who only wrote it to benefit their employer in the military-industrial complex, oil industry or block chain industry, any of which some people might find uncomfortable.

Or maybe both apply? Could you please elaborate on the nature and origin of this discomfort because at the moment I don't understand it.

Thanks,

Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org

Hi Simon - I've re-read your revised draft policy in full, and overall I think it's a very thoughtful and helpful piece of writing, and the basis for a good policy that can hopefully be good enough for everyone. However...

On 07/26/2026 8:39 PM CEST Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:

* Agnostic. Some thoughtful people believe that we should have a blanket ban on LLMs. Others, equally thoughtful, believe that they have a helpful role to play in software development. I do not believe that we have anything close to a consensus on this, so I have framed the draft policy so that it is explicitly agnostic about whether LLMs are, in themselves, good or bad. That will please no one, but the alternatives seem worse to me.

The statement "That will please no one" seems to me to be empirically incorrect. The current policy seems to please all(?) of the pro-LLM people, and certainly the elephant in the room, Moritz, who has stated support for it several times. By contrast, multiple anti- or limited-LLM people have said they won't support the draft policy with this current position. (I am, regretfully, one of those people.)

* I personally do not want to express or institutionalise a second-class status for LLM-assisted contributions. So I take Moritz's concerns on this score seriously.

In my opinion "LLM-assisted" is not the best choice of words here, because all versions of this policy have been explicit that LLMs can be used in a multitude of ways to assist development. The issue at hand is whether LLM-generated code and documentation should be treated _the same_ as human-written.

But I do want to express a very strong desire for human judgement, responsibility, effort, and responsibility in GHC contributions. (And Moritz does too.)

By my `wc -w` count, Moritz has contributed - with the aid of LLMs - close to 50% of all words in this discussion. He and his LLMs have written more emails than the next 2 most-frequent contributors put together. He has taken responsibility for every word, yet seems to have had quite an outsized influence on the direction of this policy and discussion. (He's the only person named in your email, for example, and he's named twice.) The number of personal emails I've gotten thanking me for taking on this "dirty job" (not my words) of interacting with these walls of partially-LLM-generated text has me convinced that this is not just a me-issue, but something which threatens the balance of the delicate ecosystem that is GHC development. We're no longer, in my eyes, in the realm of "what if" but instead the realm of "so this is what it's like." Absolutely, we're in a better place than we'd be if we were getting true "slop," but I would vehemently (though respectfully, of course) disagree with the notion that this current revision of the policy is the "agnostic" or "agree disagreeably" position.

How best to express that pair of desires? It seems difficult to find language that is acceptable to all, despite our agreement on the principles this language expresses. My proposal is to

* Requirefull responsibility. For now at least I have settled on "human authorship" as a term to express this idea strongly -- adding language to say that (in this context) "authorship" does not mean "typed every word". But it does mean reviewing every word and almost certainly revising many of them.

My constructive feedback is that the balance of positions lies in finding somewhere between the poles of "reviewing every word and almost certainly revising many of them" and (my phrasing) "writing nearly every word and taking responsibility for all of them." (Note that these positions are closer to each other than the ban/allow all LLMs positions!). I would be happy (well, willing :) ) to work together with people who hold different views, to try and come up with a phrasing that tries to find a midpoint here, if you think that would be helpful. Cheers and thanks, Tom

On 07/26/2026 8:35 PM CEST Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:

On Sun, Jul 26, 2026 at 09:12:19AM +0000, Jaro Reinders via ghc-devs wrote:

...

We all seem to recognize that interacting with LLM generated code or documentation makes a significant number of contributors uncomfortable.

A very interesting claim. Whatever could it possibly mean?

Do you mean those contributors are uncomfortable with some intrinsic property of the code (or documentation) that LLMs tend to generate? Or merely by its provenenance, i.e. an extrinsic property?

If the former, can such users reliably distinguish LLM-generated code? Can theydistinguish LLM-generated code that has been highly human edited, or even entirely rewritten? If a human can generate code with an LLM and then edit it sufficiently carefully that it's indistinguishable from code that had no LLM involvement, would those contributors be comfortable with such code?

I'll tell you that my interaction on this list with discussion that was LLM-generated (even with full responsibility taken, hand-selection, etc.) has affected my already dim view negatively. In principle we can say "you must stand behind every line." Standing behind every line does not mean that the whole process has not been made worse and unwelcoming. The ability to generate HTML tables summarizing one's point without considering the other fellow's point is not an unvarnished good. I think your argument -- well, sometimes it's as good or better -- is eminently reasonable. Yet in aggregate, expressing only a "recommendation" for hand-written code/docs/discussion will have very obvious negative effects. It already has. This is precisely why I advocate the policy being preference-based instead of a ban or full permissiveness.

If the latter, does it mean that those contributors are simply uncomfortable with the *knowledge* that some code was LLM-generated, even if they can't independently tell it was LLM-generated? Perhaps it's a bit like knowing that some code was written by someone who only wrote it to benefit their employer in the military-industrial complex, oil industry or block chain industry, any of which some people might find uncomfortable.

Or maybe both apply? Could you please elaborate on the nature and origin of this discomfort because at the moment I don't understand it.

I think for many people it's both, but speaking for myself primarily the former. Cheers, Tom

On Sun, Jul 26, 2026 at 11:23:29PM +0200, amindfv--- via ghc-devs wrote:

expressing only a "recommendation" for hand-written code/docs/discussion will have very obvious negative effects. It already has.

Sorry I forgot to address this in my previous reply, and sorry if I missed an explanation earlier. What obvious negative effect has 'a "recommendation" for hand-written code/docs/discussion' are you referring to, which has already happened? Tom

Hi Lyle! Am Fr., 24. Juli 2026 um 18:01 Uhr schrieb Lyle Kopnicky <lists@qseep.net>:

I have been using Claude Code (Opus) to assist with code reviews lately. I find that it is of great assistance in doing code reviews, but in no way can be left to stand on its own as a reviewer. It will quickly find several issues. I then examine each one. As needed, I ask Claude for explanations and justifications, and consult the code myself, to make sure I understand. I find that most of the issues it finds are legitimate, but some are not actually issues - it may have misunderstood something about the code or the intent. I will then continue to review the code myself, and often will find major issues that Claude missed.

Although I think Claude is of great assistance in getting up to speed on the merge request, and with questions on the code, it is no magic bullet. There is no way to ensure that it doesn’t generate false positives, or false negatives. Thus I think that generating reviews completely automatically with LLMs is likely to cause frustration to the MR author. I’m fine with someone doing an LLM-assisted review, but agree with the Simon PJ’s proposed notion of someone needing to take responsibility for it.

I agree that an LLM-generated shouldn't replace a human review. My current idea is to have optional, additional LLM-generated reviews that I or other contributors could provide. However if the goal is to reduce the load on human reviewers, I don't think that it should the task of the "LLM-review-providers" to check that the review is actually "correct". In fact, I don't think anyone should be obligated to act on such a review. My hope is that these reviews will still provide some value to the project by catching issues before a human reviewer needs to spend time on them. If it turns out that the rate of false positives and negatives is too high, we can try to improve how these reviews are generated or end the experiment. Cheers, Simon