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 the policy is not trying to define a general notion of "human authorship" but rather specify when a submission meets a particular criterion relevant to contributing to GHC? Tom

On Tue, Jul 21, 2026 at 04:43:29PM +0300, Wolfgang Jeltsch via ghc-devs 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.

I think that is highly debatable, but probably a philosophical discussion out of scope for ghc-devs.

Why not be honest and say that GHC doesn’t require contributors to be authors? Or just be silent about this issue?

I have no objection to the policy being expressed in a way that doesn't refer to authorship. I disagree with the assessment that referring to authorship in the way it currently does makes the policy not "honest". I think claiming so probably violates the guidelines for respectful communication. Tom

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).

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.

On 07/24/2026 11:31 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:

Hi Tom,

This is interesting. We agree even!

Hi Moritz - glad to see many points of agreement and compatibility!

...

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.

I've been using "good faith" to mean having honest intentions. Aren't we both doing that here?

...

[...] 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.

It's quite simple: when documentation is written by a person, they choose each word based on its imagined effect on the reader. I imagine myself in your shoes and try to communicate abstract ideas to you. When it's written by a machine, whether high- or low-quality, that same process did not take place. Maybe it's written crisply; maybe it's not. (If it were guaranteed not to be, I'd be supporting a blanket LLM ban.) I imagine you might feel that a person going back and forth with an LLM might be putting just as much work into how the words will be received as someone writing without an LLM. Having seen how things work in practice, though, I feel that the productivity wins of LLMs are largely negated if that much care is put into wordsmithing, and as the original proposal said, "the best way to take responsibility for every word is to write every word." Again, though, the proposed policy does not disallow you from submitting anything; it just gives reviewers a heads-up that they might encounter a different type of failure mode.

I still don’t know where this “make things easier for an LLM-assisted workflow” comes from?

I was responding to the previous email in the thread, which suggested we develop lists of "optimization criteria" for, as I understand it, human-machine interaction.

...

...

(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?

Perhaps I wasn't clear; I'm saying that the issue of "detect[ing] non-compliance" (for example, whether a person who wrote code with LLMs truthfully declares it) is a separate issue from what our stated goals are (please declare direct use of LLMs).

...

...

(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?

My definition might be different from others', but to me it's fairly straightforward: "human-written" means, well, written by a human. That human may have had lots of long dialogues with chatbots about how systems work, and had the chatbots point to different parts of the code and maybe even come up with ideas about how to approach the problem, but then the human, well, wrote the code.

(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?

It's difficult to say why any community "should" have a preference for anything! But clearly, they do. Half of the people on GitLab want to ban it entirely, and others would prefer it's not used. I think we need to find an "agree to disagree" way forward, which in my mind _at least_ involves letting people opt out of unknowingly reviewing LLM-generated docs/code, and acknowledging that a majority prefer LLMs not to be used. (Also, I think you may need to be more charitable: I haven't seen a single person argue against using LLMs "in any form or function" in this discussion.)

...

...

(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?

No, that's not what I wrote, but re-reading it I understand the confusion. What I meant to say (should have said) is that a person so inclined could behave this way, not that anyone who uses LLMs would do so. I don't think a policy like the above is tenable because a person _could_ do that, certainly not that every LLM user _would_.

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.

The policy said "We strongly prefer human-written code. You can use LLMs to analyse, review, produce ideas and prototypes, but we would much prefer you to write the code of your MR yourself." If you're using "rubber ducky" in the traditional sense, that would very much be in the realm of "analyse, review, produce ideas and prototypes." I don't think it would be much of a struggle to remember if you'd written code or documentation with LLMs.

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.

These are good examples, thanks. In these cases, if it's a tiny change for clarity, it might fall under the "rubber ducky" notion. In the case of larger changes, I'd simply say in the MR "I wrote this feature myself but used LLMs for restructuring; here's how/where." No big deal! I'm willing to agree that in some cases this might result in higher-quality contributions; "I used LLMs" doesn't mean the contribution is necessarily worse. I do think writing the entire code yourself, fully-functional, then using LLMs for tweaks, is quite different from generating code.

Best, Moritz

PS: assistive technology was used when writing this email.

I'm reminded of the warning at the end of a fictional news segment on The Simpsons: "VIEWER ADVISORY: The preceding program [...] should not have been viewed by young children." I.e., at the end of the message it's too late to do anything about it! :) Cheers, Tom

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).

...

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?

...

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.

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'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."

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." Cheers, Tom *I say "more than" because 50% want to ban it entirely. There are others who would prefer it not be used, but don't want to force their preferences in the form of a ban.

Hi Simon (Jakobi) -

On 07/25/2026 1:40 PM CEST Simon Jakobi <simon.jakobi@gmail.com> wrote:

...

...

...

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.

I was initially horrified about this idea (and assumed I'd misunderstood you), but after readng more I think it's something I could get behind if done properly. There's apparently a roiling conflict on the LKML about some of the details (is it requiured, does the contributor or the reviewer need to read the LLM output, who if anyone is burdened with the "non-negligible quantity of nonsense", etc.), but I have confidence we could come to some kind of midpoint where we find bugs and don't burden people with too much slop. My personal leaning would be to only have a tool that a reviewer could optionally use as a first check, and if the LLM claims to find a bug the reviewer must take time to understand and take responsibility for the claim of the bug's existence, but this probably merits further discussion. Cheers, Tom

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. It is interesting that LLMs provide a channel for that frustration, but it is something that a diligent, high quality human review can trigger as well (and we are better off for it). :) Am Fr., 24. Juli 2026 um 15:52 Uhr schrieb Benjamin Redelings via ghc-devs < ghc-devs@haskell.org>:

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

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

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.)

Hi Simon, On Jul 24, 2026 at 1:12:26 AM, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:

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.

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. We should avoid “success at all costs”. — Lyle

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

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

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

Hi Tom, I’ve spent some more time rereading the discussion in an attempt to better understand your position. (Btw. The new mailman interface is awesome!) You wrote:

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

This sentence disappeared from Simon’s v2 draft, but from your replies it seems clear that you consider it essential. That made me realize something. Perhaps part of our disagreement stems from the fact that we’ve been using terms such as “human-written” without ever defining them. These are the definitions I have been implicitly using throughout this discussion. *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 of *human-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. I don’t expect everyone to agree with these definitions. They are simply the definitions I have been implicitly reasoning from throughout this discussion. I also don’t think the intermediate terms form a strict ordering. Rather, they describe different ways in which humans and machines can collaborate during the production of text. What I do think forms a spectrum are the two endpoints: fully human-written and fully machine-written. Human-authored, to me, is orthogonal to that spectrum. One reason I think these distinctions matter is that I don’t believe I have ever argued in favour of machine-written contributions. Throughout this discussion I have been arguing about workflows that remain under human judgement, supervision, direction, and ultimately responsibility. Conversely, I have consistently interpreted human-written literally. That is why I have repeatedly distinguished human-written from human-authored throughout this discussion. In my mind, human-written is simply the antonym of machine-written. If your understanding of these terms differs from mine, I would genuinely appreciate seeing your definitions. I increasingly suspect that we’ve been using the same words while referring to different concepts. Perhaps the next iteration of the policy shouldn’t begin by debating whether we strongly prefer human-written contributions, but by agreeing what “human-written” actually means. If the project is going to strongly prefer human-written contributions, then I think we owe contributors a clear definition of what “human-written” means. Otherwise I worry we’re expressing a strong preference for a term whose boundaries are left entirely to individual interpretation. Best, Moritz On Sun, Jul 26, 2026 at 8:35 AM Moritz Angermann <moritz.angermann@gmail.com> wrote:

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

Hi Tom, Thank you. I think this gets us considerably closer. There is an important difference to me between: We strongly prefer human-written code. and: Some contributors strongly prefer human-written code. I could live quite comfortably with the latter. It acknowledges that the community is not monolithic and that this preference genuinely exists, without the project itself adopting that preference as its own. I would be less comfortable with “a large portion” or “a majority,” because those are empirical claims that I don’t think the GitLab issue establishes. To make such a claim, we would first need a representative consultation and agreement on who constitutes the relevant community and is eligible to participate. Perhaps wording along these lines would capture the concern without overclaiming: Some contributors strongly prefer human-written code and documentation and may be uncomfortable reviewing or maintaining LLM-assisted contributions. That seems factual, acknowledges their position, and leaves the project itself neutral between contributors who hold different views. Best, Moritz On Sun, Jul 26, 2026 at 2:20 PM <amindfv@mailbox.org> wrote:

...

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

...

Human-written: Each and every substantive character of the final text was manually composed by a human. No assistive tooling was used to produce the substantive wording itself.

Machine-written:Each and every substantive character of the final text was produced by a machine without meaningful human intervention. This is, to me, the diametric opposite ofhuman-written.

Human-delegated: A human deliberately delegates the production of some or all of the substantive text to a machine.

Human-guided: A human iteratively guides the production by providing prompts, constraints, corrections, examples, and feedback.

Human-supervised: A human continuously evaluates, accepts, rejects, or redirects the machine’s output while it is being produced.

Human-edited: A human substantially modifies machine-produced text after generation before adopting it.

Human-authored: A human exercises judgement over, understands, selects, revises, adopts, and ultimately takes responsibility for the resulting work, regardless of how individual parts of it were initially produced.

All of your definitions here, except the first, seem to include large sections of the final result being written by an LLM.

I think "Human-written" could be expanded to include things like, "oh, I copy-pasted this 3-word phrase that came out of a conversation with an LLM chatbot," but I agree with the previous policy proposal: "By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word."

Cheers, Tom

Jaro, Good question. To some extent, this has already happened. So the question seems to be whether we want to start prohibiting it going forward, or whether we instead define conditions under which such contributions remain acceptable. I also have rather practical reasons for arguing my case here. I’d very much like to continue contributing to GHC, preferably without maintaining a fork. Likewise, members of my team regularly contribute fixes and improvements to GHC as part of their work. If the project adopts a policy that institutionally disfavors those contributions simply because of the workflow used to produce otherwise acceptable contributions, that would make continued participation substantially harder for us. Over time, I also worry that this makes it more difficult to justify investing engineering time and funding into upstream GHC work. For me, the line is not the use of LLMs itself. The line is whether the project starts expressing a systemic preference between otherwise acceptable contributors based on their workflow. I cannot in good conscience contribute to, or advocate for, a project that institutionally ranks otherwise acceptable contributors or their work in this way. You might reasonably respond that, by opposing such a preference, I am disadvantaging contributors who dislike LLMs. I don’t see it that way. I am not arguing that anyone should be forced to use LLMs, nor that anyone should be compelled to review LLM-assisted contributions. Contributors remain free to review—or not review—whatever they choose. Just as they are today. What I am arguing against is the project itself adopting one side of that disagreement as an institutional preference. I think there is an important difference between reviewers expressing individual preferences and the project itself adopting those preferences as policy. Ultimately, I still think contributions should be evaluated on their technical merits. If the concern is that low-quality LLM-assisted patches will routinely pass uncontested through review, then I think the underlying problem is the review process rather than the existence of LLMs. The current proposal already introduces disclosure precisely so that reviewers who do not wish to review LLM-assisted contributions can opt out, while giving reviewers who do engage additional context. If the overwhelming majority of reviewers exercise that option, then LLM-assisted contributions simply will not be merged, or will be merged only very slowly because they are drawing from a much smaller review pool. Best, Moritz On Sun, Jul 26, 2026 at 4:12 PM Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:

We all seem to recognize that interacting with LLM generated code or documentation makes a significant number of contributors uncomfortable. If LLM generated code and documentation makes it into the codebase, then it will become practically impossible to avoid and thus it will make a significant number of contributors uncomfortable. Why, then, do we keep considering to allow such behavior?

Cheers, Jaro

On 26 Jul 2026, at 10:27, Moritz Angermann via ghc-devs < moritz.angermann@gmail.com> wrote:

Hi Tom,

Thank you. I think this gets us considerably closer.

There is an important difference to me between:

We strongly prefer human-written code.

and:

Some contributors strongly prefer human-written code.

I could live quite comfortably with the latter. It acknowledges that the community is not monolithic and that this preference genuinely exists, without the project itself adopting that preference as its own.

I would be less comfortable with “a large portion” or “a majority,” because those are empirical claims that I don’t think the GitLab issue establishes. To make such a claim, we would first need a representative consultation and agreement on who constitutes the relevant community and is eligible to participate.

Perhaps wording along these lines would capture the concern without overclaiming:

Some contributors strongly prefer human-written code and documentation and may be uncomfortable reviewing or maintaining LLM-assisted contributions.

That seems factual, acknowledges their position, and leaves the project itself neutral between contributors who hold different views.

Best, Moritz

On Sun, Jul 26, 2026 at 2:20 PM <amindfv@mailbox.org> wrote:

...

...

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

...

Human-written: Each and every substantive character of the final text was manually composed by a human. No assistive tooling was used to produce the substantive wording itself.

Machine-written:Each and every substantive character of the final text was produced by a machine without meaningful human intervention. This is, to me, the diametric opposite ofhuman-written.

Human-delegated: A human deliberately delegates the production of some or all of the substantive text to a machine.

Human-guided: A human iteratively guides the production by providing prompts, constraints, corrections, examples, and feedback.

Human-supervised: A human continuously evaluates, accepts, rejects, or redirects the machine’s output while it is being produced.

Human-edited: A human substantially modifies machine-produced text after generation before adopting it.

Human-authored: A human exercises judgement over, understands, selects, revises, adopts, and ultimately takes responsibility for the resulting work, regardless of how individual parts of it were initially produced.

All of your definitions here, except the first, seem to include large sections of the final result being written by an LLM.

I think "Human-written" could be expanded to include things like, "oh, I copy-pasted this 3-word phrase that came out of a conversation with an LLM chatbot," but I agree with the previous policy proposal: "By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word."

Cheers, Tom

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

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

Jaro,

Good question.

To some extent, this has already happened. So the question seems to be whether we want to start prohibiting it going forward, or whether we instead define conditions under which such contributions remain acceptable.

I also have rather practical reasons for arguing my case here.

I’d very much like to continue contributing to GHC, preferably without maintaining a fork. Likewise, members of my team regularly contribute fixes and improvements to GHC as part of their work. If the project adopts a policy that institutionally disfavors those contributions simply because of the workflow used to produce otherwise acceptable contributions, that would make continued participation substantially harder for us. Over time, I also worry that this makes it more difficult to justify investing engineering time and funding into upstream GHC work.

For me, the line is not the use of LLMs itself. The line is whether the project starts expressing a systemic preference between otherwise acceptable contributors based on their workflow.

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

You might reasonably respond that, by opposing such a preference, I am disadvantaging contributors who dislike LLMs.

I don’t see it that way.

I am not arguing that anyone should be forced to use LLMs, nor that anyone should be compelled to review LLM-assisted contributions. Contributors remain free to review—or not review—whatever they choose. Just as they are today.

What I am arguing against is the project itself adopting one side of that disagreement as an institutional preference. I think there is an important difference between reviewers expressing individual preferences and the project itself adopting those preferences as policy.

Ultimately, I still think contributions should be evaluated on their technical merits.

If the concern is that low-quality LLM-assisted patches will routinely pass uncontested through review, then I think the underlying problem is the review process rather than the existence of LLMs.

The current proposal already introduces disclosure precisely so that reviewers who do not wish to review LLM-assisted contributions can opt out, while giving reviewers who do engage additional context.

If the overwhelming majority of reviewers exercise that option, then LLM-assisted contributions simply will not be merged, or will be merged only very slowly because they are drawing from a much smaller review pool.

Best, Moritz On Sun, Jul 26, 2026 at 4:12 PM Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:

...

We all seem to recognize that interacting with LLM generated code or documentation makes a significant number of contributors uncomfortable. If LLM generated code and documentation makes it into the codebase, then it will become practically impossible to avoid and thus it will make a significant number of contributors uncomfortable. Why, then, do we keep considering to allow such behavior?

Cheers, Jaro

On 26 Jul 2026, at 10:27, Moritz Angermann via ghc-devs < moritz.angermann@gmail.com> wrote:

Hi Tom,

Thank you. I think this gets us considerably closer.

There is an important difference to me between:

We strongly prefer human-written code.

and:

Some contributors strongly prefer human-written code.

I could live quite comfortably with the latter. It acknowledges that the community is not monolithic and that this preference genuinely exists, without the project itself adopting that preference as its own.

I would be less comfortable with “a large portion” or “a majority,” because those are empirical claims that I don’t think the GitLab issue establishes. To make such a claim, we would first need a representative consultation and agreement on who constitutes the relevant community and is eligible to participate.

Perhaps wording along these lines would capture the concern without overclaiming:

Some contributors strongly prefer human-written code and documentation and may be uncomfortable reviewing or maintaining LLM-assisted contributions.

That seems factual, acknowledges their position, and leaves the project itself neutral between contributors who hold different views.

Best, Moritz

On Sun, Jul 26, 2026 at 2:20 PM <amindfv@mailbox.org> wrote:

...

...

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

...

Human-written: Each and every substantive character of the final text was manually composed by a human. No assistive tooling was used to produce the substantive wording itself.

Machine-written:Each and every substantive character of the final text was produced by a machine without meaningful human intervention. This is, to me, the diametric opposite ofhuman-written.

Human-delegated: A human deliberately delegates the production of some or all of the substantive text to a machine.

Human-guided: A human iteratively guides the production by providing prompts, constraints, corrections, examples, and feedback.

Human-supervised: A human continuously evaluates, accepts, rejects, or redirects the machine’s output while it is being produced.

Human-edited: A human substantially modifies machine-produced text after generation before adopting it.

Human-authored: A human exercises judgement over, understands, selects, revises, adopts, and ultimately takes responsibility for the resulting work, regardless of how individual parts of it were initially produced.

All of your definitions here, except the first, seem to include large sections of the final result being written by an LLM.

I think "Human-written" could be expanded to include things like, "oh, I copy-pasted this 3-word phrase that came out of a conversation with an LLM chatbot," but I agree with the previous policy proposal: "By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word."

Cheers, Tom

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

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

...

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.

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

Hi Moritz -

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

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.

This is also my view, so that's good!

My understanding of your view: Policies should also reflect the community’s collective values and preferences.

I think there may some truth in that view, but it's not the crux of my issue here. My view is that LLM use directly affects the quality and type of community interaction, and the resulting code and docs, and that a good middle ground is to not mandate hand-written code and docs, but to state a preference for them. In other words, though I and others may be concerned with the environmental and social impacts of LLMs, if those things weren't an issue we'd still be having this conversation.

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?

I'm not quite sure what "justify" means here, but sure - if 50% of a community strongly opposed any particular set of community behaviors, and we considered that opposition to be worthy of consideration and respect, then I'd expect short of an outright ban, you'd see an expression of expectations in project policy. Not necessarily swinging the penduluum entirely to their view, though! (I think e.g. "develop[ed] on Linux" is a stretch because that's largely orthogonal to the visible results of a person's contribution, but I'm trying to roll with your analogy here. See if your answer changes if it's "developed with child labor" or "comments on MRs in all capital letters.") A potential point of compromise here might be to rephrase the "we" statements to be clear that the community is not monolithic. So instead of "We strongly prefer human-written code," it says "A large portion of the community prefers human-written code. Therefore, we'd prefer you (but won't compel you) to write your code by hand." (Followed by "You can use LLMs to analyse, review, produce ideas and prototypes, but we would much prefer you to write the code of your MR yourself," etc.) Cheers, Tom

Hi Simon, On Jul 25, 2026 at 5:05:40 AM, Simon Jakobi <simon.jakobi@gmail.com> wrote:

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.

That sounds reasonable to me. Thanks for the explanation. — Lyle