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,
 Moritz

On 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,
Josh

On 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