Hi Sem, thanks for sharing your thoughts. I've responded inline:
On 07/23/2026 11:54 PM CEST Semen Trygubenko via ghc-devs <ghc-devs@haskell.org> wrote:
I think we could put still more precision of thought into the policy, so that humans and machines can agree on what it requires.
I'm concerned here at the notion of concerning ourselves with writing this policy for machine consumption. The argument earlier was that LLMs were "assistive technology," but now there's a subtle shift to needing to write for them and not only ourselves.
In programming terms, it could follow something like an SSA discipline: define each key concept once and use it consistently, rather than allowing effort, understanding, responsibility, provenance and quality to stand in for one another.
Applying Occam's razor, I think the normative core could be reduced to P1, P2 and R1.
P1 currently says twice that contributors should have invested substantially more time than reviewers. Time spent is difficult to observe and is only an indirect proxy for what matters. A contributor may spend considerable time producing an MR that remains difficult to review, while an assisted workflow may remove typing overhead yet produce a compact, well-understood and well-evidenced change. P1 should therefore specify review readiness rather than an effort ratio.
I might stand alone here among what might be termed the LLM skeptics, but I think your point is sometimes quite true: it's not hard for me to imagine individual changes (likely smaller ones) which require minimal human modification. Time and typing of course don't equal quality. The key, I think, is that more time and effort should be spent by the contributor _than the people reviewing the contribution_. (Maybe a reference to effort in addition to time would make this clearer?) The point being, whatever resources (time, effort, tearing one's hair out) required of the reviewer(s), the contributor should have invested significantly more than that, ensuring the change is as correct as it first appears. Even for trivial changes, reviewers have to make very sure the code is of high quality, and the contribuutor should put this effort in first too.
[...] The contributor must understand, test, simplify and explain the change; the reviewer must understand it sufficiently to stand behind an approval. Manual composition does not demonstrate understanding, just as machine assistance does not disprove it.
If P2 is enforced, P3 appears to add little quality control. A declaration neither establishes understanding nor detects its absence: a conscientious contributor who satisfies P2 gains no additional quality from declaring tool use, while someone willing to evade P2 can also omit the declaration. I would therefore remove P3 and judge contributions directly under P1 and P2.
I see your point, and yet this is precisely the slippery slope that LLM skeptics worry about: once LLM use is officially sanctioned, then the obvious next question is "if I'm writing good code, why should I need to declare how it was written?" The answer, I think, lies in the "overriding principles" section of the proposed document: "We want to build software that is the province of humans, who conceive, understand, develop and refine it through a web of relationships and dialogue." If I see a sentence in a discussion that seems strange to me, and I'm confident it was written by a human, I might spend quite a while considering whether the strangeness lies in a misapprehension of mine, a misapprehension of the author, or some other factor. I might put real effort into crafting a response that attempts to bridge the gap in understanding between two humans. If, instead, this strange sentence might just be generated nonsense, representing nothing that ever resided in any person's mind, then my time and effort has been completely wasted, like writing a longform response to email spam. Even a single nonsense phrase (or a technically-correct-but-robotic one) in an otherwise-fine paragraph is enough to make many of us demoralized and less trusting. The human connection has been breached.
[...] a small version-controlled evidence log containing agreed observations and the minimal metadata needed to interpret them. At each review, the community could retain, revise or reverse the policy in light of that record.
Can you explain how this would work? This seems like a technical solution to a social problem (namely, having a policy that keeps everyone reasonably happy).
I would replace the current writing-focused recommendation with "Use a workflow that develops understanding." Personally writing the final implementation is a useful kata for recall and fluency, but [...other methods...] makes machine-assisted development resemble disciplined human development without treating typing effort as a proxy for thought.
Your point here is both a reasonable position and exactly what concerns me most about efforts to enshrine LLM use as just another way of writing code. The focus on writing every word yourself is not just a "kata for recall." A previous version of this policy proposal put it perfectly, I thought: "writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand." Tens of thousands of commits have been contributed to GHC, each considering the effect of every statement (code or documentation) on future readers. It's not enough for code and documentation to be technically correct; it must be comprehensible and even enjoyable by humans, now and in the future. GHC is an incredible gift of authorship, and it's easy for it to get diluted by the output of machines that have no way of considering the effect on future readers.
Over time, an open list of katas and explicit optimisation criteria --- for example, diff minimisation, naming clarity, abstraction fit, removal of unnecessary complexity, evidence and test quality --- could let humans and machines explore bounded alternatives against values the project has actually chosen, rather than optimise for code production alone.
I again think that even before this policy has been fully hammered out, the slippery slope feels like it's already slipping. Things like diff minimization are only proxies for code quality. The onus here seems to flip, from LLMs helping some developers in the privacy of their personal setups, to the community contorting itself to make things easier for an LLM-assisted workflow.
(7) "P3: Declare direct use of LLMs" and the corresponding section -> delete (declaration neither establishes compliance with P2 nor detects non-compliance)
Detecting non-compliance is not the purpose of this document. An assumption of good faith is healthy.
(8) "R1: Recommendation: write the final version yourself" -> "R1: Recommendation: use a workflow that develops understanding" (states the intended outcome while retaining personal composition as one useful kata)
This change actually highlights why I think the previous version of the proposed LLM policy was much better than the current one: R1's recommendations focus on the benefits for the author (or "author"). The statements of preference ("We strongly prefer human-written code," "We strongly prefer human-written documentation") emphasized the benefits for everyone affected by the author's decisions.
(16) "you must not relay AI-generated text as a substitute for your own judgment" -> "Communication may be machine-assisted, but the sender must have read and understood the message, adopt it as their own position, and be prepared to discuss and defend it. Raw machine output presented for examination rather than adopted as the sender's judgement must be clearly identified." (distinguishes adopted communication from unexamined output)
"Be prepared to discuss and defend it" doesn't seem like much of a requirement if we're allowing unlabeled machine-generated text. I'm sure a person willing to use an LLM can "discuss and defend" anything ad nauseum, but that's not considerate of the person on the other end of the line. (Or of other readers, if both "people" are mostly LLMs!) Cheers, Tom