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.