The following is a deliberately artificial thought experiment about that policy mechanism. It is not an argument that Emacs and LLMs are technically, psychologically, ethically, or socially equivalent.
Imagine the following policy:
As an Emacs user, what does this policy communicate to you?
It says that you are nominally welcome, but that you belong to the non-preferred category of contributors. Your contribution must carry a declaration that Vim users do not need to make. That declaration appears before anybody considers the merits of your work, and some reviewers may use it as a reason not to engage with you or your contribution at all.
Do you feel that your contribution begins on equal footing?
Do you feel equally welcome as a contributor, or merely tolerated provided that you disclose your non-preferred working method?
Would you expect your work to be received with the same initial trust?
Would you feel required to justify why you used Emacs?
And given that Emacs usage cannot ordinarily be determined from the final patch, what incentive does this policy create? The honest Emacs user voluntarily enters the non-preferred category and accepts greater scrutiny and a smaller potential reviewer pool. The dishonest Emacs user says nothing and is treated as an ordinary contributor.
That is my concern about the proposed LLM policy. The issue is not disclosure in isolation. The issue is disclosure combined with an explicit preference against the disclosed category.
Together, those provisions do not merely distinguish two methods of producing code. They create two classes of participation:
Where the same people repeatedly fall into the second category, this is no longer merely a classification of patches. It becomes a classification of contributors.
Of course LLMs are not editors. They differ in capability, risk, psychological effects, environmental impact, economics, and many other respects. The comparison is not intended to erase those differences. It isolates a narrower policy question:
What happens when we require people to disclose a private and difficult-to-verify practice, explicitly classify that practice as non-preferred, and permit the declaration to affect how they are received?
The answer is that we create an honesty penalty and a two-tier contributor status. We tell conscientious assisted contributors that they are welcome, while requiring them to identify themselves as belonging to the less-preferred category.
What behavior are we trying to encourage: honest disclosure, or plausible silence?
When a policy requires disclosure of a difficult-to-detect private practice and simultaneously declares that practice non-preferred, it makes honesty costly and concealment advantageous.
And yes, whether or not an LLM was used for research, analysis, ... or even (partial) code conception is fundamentally different from the conversation someone enters into about their work. I would not tolerate someone who basically makes me talk to a chatbot on their behalf. Nor someone who blurts out 1000+lines of code and claims a job well done. But this is a social dynamic question. And we need to align the incentives that make this behaviour undesirable for the person that is contributing. An outright LLM ban doesn't create those incentives, but it's the strongest deterrent you could have.
Best,
Moritz
Disclaimer: Parts of this email have been rewritten and rephrased using assistive tools to improve clarity and hopefully aid in getting my point across better. I have reviewed each suggested change myself, accepted or modified.
Hi Moritz,What I'm getting at is that the LLM proponent position sounds to me like "I'm in the group of people who need LLMs", in the same way that a person might need the actual assistive technology of prescription eyeglasses, or a screen reader - but I don't see LLMs as being this category of technology (they're more like a weird IDE), although they do their best to make a person feel like they need it. LLM users are surely capable of programming in the way that we always have, so the various versions of these policies do not make a value judgement on the contributor, just on inclusion of a piece of software in that contributor's process. I'm struggling to see this link that LLM proponents feel like making where judgement against their tool of choice is judgement against the participant, and therefore completely excludes them.As you have said that you intentionally use LLMs for development, I would like to point out that the real value judgement is in favour of the institutional knowledge that exists in, for example, your previous contributions. It's extremely difficult to gain that depth in the "review" process, whether that's reviewing the output of your own prompt, or reviewing a human-authored PR. To make an analogy, I see "oh yeah, I reviewed it" as comparable to "I watched the lectures, I'm ready for the exam".Yes, it is difficult to prove lack of usage, especially with the inclusion of LLMs in search engines and likely in forum discussions that one might come across, but I believe that's at least somewhat orthogonal to direct usage in editing code or "conversation" participation with a chat bot on the topic of the changes you intend to make to the code. I also agree that it's possible that people might lie about their usage, though I believe a policy could also result in self-selection against people likely to lie, because at least a subset of this group would be looking for easy praise.Kind Regards,JoshOn Fri, 17 Jul 2026 at 20:57, Moritz Angermann <moritz.angermann@gmail.com> wrote:Josh,What makes me part of which group? The one that uses assistive tools? Well, simply by using VSCode with copilot enabled I'm using LLMs. Sure I personally also use claude, codex, and other models in my experiments. But I can not prove, neither to myself, not to anyone else that I did not use assistive technology in any form, unless I go and buy a computer and try really hard to not have any ai tech on there. So yes, I have to assume that I intentionally or unintentionally used llm most likely. And tbqh, I don't even think that's a problem. So I'm also not objecting to the labeling.
I don't think Claude, Codex or any of the other LLMs should be anthropomorphised and considered contributors. I think that label should stay with humans.
LLM ban, clearly says you do not want people as contributors who use LLMs casually, or otherwise and might contaminate any contribution with their use of assistive technologies.
The current policy stratifies contributions in desirable (strongly preferred human-written) and less desirable (created fractionally or fully with assistive technologies), that extends to the authors of those contributions. Some are seen in higher regard than others who use assistive technologies. This is exactly what I do not want to be encoded. Whether or not someone holds these views privately or openly in public is different to the GHC project encoding this value judgement in its policie(s).
The opposite of an LLM ban, which I'll just try to sketch for completeness, but doubt (hopefully?) anyone would argue for is: we don't care how contributions come to be, even if they are created completely autonomous without a human near them.
Best,MoritzOn Fri, 17 Jul 2026 at 17:39, Josh Meredith <joshmeredith2008@gmail.com> wrote:Hi Moritz,That's part of my question though: what makes you (or others) part of this group? An LLM is just something you are currently deciding to (or inadvertently, with how much the technology is being pushed) access from your computer. I'm aware that it is difficult to prove situations such as "did the PR author avoid reading the Gemini summary in conducting a Google search?", but it's reductive to say that actively and intentionally using LLMs is the same as accidentally breaking your "clean-room" status by coming across an output. We all know you to have been fully capable without such tools, and I know that the ease they introduce can help with motivation, but I do believe that (from my observations in discussions outside of the Haskell community) that it's a false motivation stemming from learning being linked with frustration.Either policy - being a full ban, or labelling, doesn't say anything about wanting a contributor or not, and I think to say it does is to anthropomorphise Claude.Kind Regards,JoshOn Fri, 17 Jul 2026 at 20:14, Moritz Angermann <moritz.angermann@gmail.com> wrote:Josh,You might be surprised to learn that I'd be conceptually more aligned with a LLM ban policy than one that tries to not not ban, but creates preferred and permissible contributors.
While an LLM ban will mean I will just stop (and maybe that's the best for my health anyway), caring about Haskell and GHC, it does not create two separate groups. It just completely precludes one group (the one I'd count myself in). However it does not make me coexist with other contributors who are considered of higher standing than me, because I will not ensure (and eventually have to prove) that I did not use any assistive technology.
If the majority of ghc developers want to ban assistive technology use (maybe just for some time), so be it. But that should be a statement as simple as:
The GHC project does not permit contributions that use assistive technologies.
That's fine, it says: we don't want you; legitimate. I have no problem with such a stance. Notably though, it does not say--which is what I so vehemently object to--well, maybe we do want you, but if you contribute we'll not value your contribution as much as someone else's whose process we value above your process.
Best,MoritzOn Fri, 17 Jul 2026 at 16:59, Josh Meredith <joshmeredith2008@gmail.com> wrote:Hi Moritz, Simon,I'd like to question the need for this classification for a policy being stratified, non-inclusive, or whatever word you'd like to attach, as well as provide my own observations on software development, learning/collaboration, and LLM usage.To me, it's not relevant whether a policy banning a piece of software should be considered non-inclusive. "LLM user" isn't an innate human trait, socioeconomic status, or any other similar category - it's isn't even a category that existed until recently, and it's one that we've yet to see the consequences of.Speculatively, I believe that LLM proponents can see this usage as important to their personality because of the perceived smoothness and speed of working with one. In my opinion, the smoothness is a result of the LLM making decisions for the user, and decisions can be fatiguing. However, software is an artifact that results from many decisions being made ahead of runtime, so the result of LLM use for programming is that we're left with code that provides a statistically plausible, but not necessarily correct decision that no human has actually made. The difficulty of reviewing code, whether fully hand-written or otherwise, is that to some degree you have to trust that the author has reasons for the decisions they made - to do otherwise would necessitate recreating the changes from scratch. I think that LLMs are unique in that they, in my observation, seem to unlink the correlation between correctness and perceived plausibility.Julian has brought up the value of collaboration in software development, and to me this (category, and not necessarily his words) means that GHC is a result of the collaboration and consensus in making decisions. The Haskell community has been known to be slow in coming to a consensus, which I have previously seen as bureaucratic, but I now see as resulting in better end decisions.I've seen multiple mentions in this thread about LLMs incentivising code that lacks abstraction, and I don't see this as a surprise. Programming languages are essentially a UI that allows a programmer to encode decisions, and LLMs are a UI on top of programming languages. Different UIs select for different methodologies, and of course the one that writes fast boilerplate while shielding the user from being forced to undergo the frustration of learning will take away incentives and deep understanding that allows a person to find and solve the general form of a problem (the abstraction being well-designed functions, and not necessarily DSLs).Hecate has alluded to the future of LLMs being still in question, in the details of psychological effects, institutional knowledge, and post-subsidy costs. While I realise it would be difficult to find consensus to institute a full ban, I would like to add that a ban isn't a permanent thing - it can be removed if proponents turn out to be right after the rug pull. I don't think there's an opportunity cost that the Haskell community will be losing out on if GHC were to simply wait to see how things end up.LLMs are a technology that I feel doesn't play well with other methods of development, and they crowd out a solution space in a way that is difficult to come back from, so I have to agree with Julian's point that a neutral stance is actually in favour of LLM usage.Thanks for your time,JoshOn Fri, 17 Jul 2026 at 19:01, Moritz Angermann via ghc-devs <ghc-devs@haskell.org> wrote:Julian,
I hope you'll find the focus to protect your mental health. values and continue enjoying this craft you love so much.
While I understand that you would prefer that LLMs would just stop existing, you know that I don't see this as a realistic outcome. I also do take your concerns very seriously! Even if that might not appear to you like I do. This time I'll try something different. Instead of arguing against some policy, or its wording, I'm going to offer an alternative GHC Contribution and Collaboration Policy as inspiration: and yes, assistive technology has been used in its creation, to make sure I don't end up misusing words. I've also attached the current version as a PDF for those who prefer to read it that way instead of on google docs.
Given that policy, I would hope we would not need a dedicated LLM policy. However people will nevertheless ask for an explicit LLM policy, the complete dedicated statement could then be very short:
“LLMs are permitted assistive tools. The general GHC Contribution and Collaboration Policy applies regardless of the tools used. Please disclose non-trivial LLM-generated material included in a contribution when relevant to provenance or review context. Such disclosure is contextual information, not a quality rating, and does not make either the contribution or its author less preferred. The human contributor must understand, stand behind, and take full responsibility for the contribution, and must participate authentically in review.”
With this I've tried to focus on regulating the contribution and the collaboration, not the contributor’s private method of production. Which--as I've expressed--I don't think we even realistically can.
Sadly I'm afraid this will fall short of the constitution of human programming culture, you'd like to see. If we want to debate a constitution for the GHC development community that we give ourselves, I'm happy to debate that in a separate thread though. Although we'll probably run into the same impasses :-/
Maybe a line like the following, would be something you'd like to see added?GHC does not measure contributors by output volume, and nobody is expected to adopt LLMs or any other assistive technology to remain a valued participant. Human understanding, mentoring, review, maintenance, and community involvement matter at least as much as implementation speed.In any case, I hope we'll end up spending some good time sharing durian in the future again.
Best,Moritz_______________________________________________On Fri, 17 Jul 2026 at 13:01, Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote:This is going to be my last reply in this thread.
Let me start by saying that I am not an anti-AI absolutist like some in this thread have repeatedly try to paint me as. I have been using LLMs for almost a year now, have been experimenting with them and found interesting use cases. Sometimes they seem to enable me and sometimes they lead me into psychological traps. And they do so regularly. I have also observed what I believe are their effects on the open source ecosystem. So here is my boiled down evaluation:
- they can compromise the judgement of (senior) engineers
- they erode human communication and collaboration
- while they can act as an accessibility boost, they do not on average promote curiosity or learning
So the central over-arching question we're trying to solve here is:
IS THERE A RESPONSIBLE USE OF LLMs?
I think there might be. But we also have to accept the possibility that the answer is "no". So the question is, how do we move forward in this uncertainty. I think there might be ways, but they are all fairly impractical in a passive society:
- gaining control over the alignment and "algorithms"
- running local models
- promoting and supporting more evidence-based research
- boycotting the "AI empire" (the frontier model companies who very clearly only have our best interests in mind)
Maybe we might reach a point of responsible use in the future, but not in the current landscape of sycophantic LLMs, companies who see us as products and a general lack of public awareness of their dangers.
But that is not all. What all of this has exposed too is our self-image and understanding of our craft. What is software engineering to us? Just the production of high quality code?
I have always followed the principle of being able to collaborate with people who hold different views than me, political or otherwise. I found this one of the primary qualities of open source, where disagreements just boil down to quality standards and design taste.
But this time it appears it's different. Your use of LLMs affects us, affects the ecosystem, affects our trust relationships, our ability to derive joy from interactions.
I have not seen that so-called responsible use yet, not at work or anywhere else. It is not a reality. I do not believe people when the say "I know how to use it responsibly". I think the only honest position is to have a deep intrinsic self-doubt about ones own capacity to deal with this technology.
Does that mean we should stop trying? I don't really know. That's up to the project to decide what risks they want to take.
But what Moritz is proposing is not going to get us any closer to that goal. It is just extending the global experiment that was brought onto us. And I object.
I do not think that carving out a huge list of dos and don'ts will actually address the primary issues that the LLM interface is posing to humans, which are about the psychological effects and our values (which he calls "ideological", but I think that is inaccurate, because it largely affects our craft). And Moritz clearly does not want to talk about either of those.
And I finally agree with Moritz, that the policy as it is right now is biased. It is trying to please both sides, but carries subtle implicit judgements. And I have changed my mind about it. I do no longer support it. The only policy I will support is a blanket LLM ban, because I think this is (right now) the best we can do to regain control, take a breath and continue the journey with caution.
But it might not be a good decision for the GHC project, which is why I will stop engaging in these discussions, which appear to already have caused some harm. I am not a top or core contributor to the project and my words should not carry as much weight as, say, Simon, Moritz, or anyone else.
But I believe there is no neutral stance. Not taking a stand means to silently agree to the global experiment. So I am taking a stand here: if LLMs are here to stay, so are humans and I value humans and their authentic work more.
So I will focus on the things I can do myself to protect my mental health, my values and maintain my enjoyment in programming.
Cheers,
Julian
_______________________________________________
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