Hi Sem, thanks for sharing your thoughts. I've responded inline:
> On 07/23/2026 11:54 PM CEST Semen Trygubenko via ghc-devs
> <[email protected]> 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
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
