Just FTR, I’m agreeable with the revised policy Simon shared. Best, Moritz
On Fri, Jul 24, 2026 at 4:31 PM Moritz Angermann <[email protected]> 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. >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
