Hi Simon, here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too? For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand. But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this. I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback. --- Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special". Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users. Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time. Cheers, Simon
Hi all, I agree with Simon (Jakobi)'s message 100%. Writing Software is no longer about writing code, it's about making good architectural decisions to guide an LLM to do it. It's pretty much what I do when I review code by a contributor. I'm happy for the contributor's code in much the same way as I'm happy for the LLM to write it, and I instruct them to (re-)write the code in exactly the same way. At the end of such a review cycle, the code is pretty much the joint product of both the contributor and the reviewer. If I haven't reviewed the code (such as when I mark the LLM-generated MR as draft), then it is not meant to be merged, not even meant to be reviewed by other people, except to get a glimpse of the proposed design. Cheers, Sebastian Am Di., 14. Juli 2026 um 16:42 Uhr schrieb Simon Jakobi via ghc-devs < ghc-devs@haskell.org>:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Hi, Simon (Jakobi)! When reading your remarks on the LLM policy, I was quite perplexed, because apparently there are certain views that seem self-evident to me but which you don’t seem to share. Let me comment on some things that you wrote:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive.
Isn’t it fundamental for a conversation that the conversation partners themselves speak or write and not send texts generated by a machine?
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that’s a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
If you contribute code, you should surely understand this code that you contribute. If your code uses some function, you should understand the consequences of using it, which implies that you should know about its strictness and performance characteristics. This is the ideal at least, which, I agree, is difficult to meet for people not deeply into GHC, me included. However, the solution is to make it easier to understand existing functions in the GHC codebase, for example by writing documentation, not to lower the standard for contributions.
We strongly prefer human-written code
I understand that it’s “good exercise” to write code by hand.
I don’t see programming as a mere exercise. It’s a key part of developing software.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills.
I definitely don’t want to be offensive, but is it a good idea to contribute code to a software that many are relying on if you’re “pretty bad” at writing code?
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and “costly”, especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance!
I completely agree that contributing to GHC can be a frustrating experience, but the solution is to improve things like the CI system, isn’t it? What Simon (Peyton Jones) suggested was that the actual coding should have a significant cost to avoid generating lots of code, which can hardly be checked properly.
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger.
I can assure you that at least I are not driven by anger in this discussion. What I want is preventing harm. You may call this “motivation by fear”. I would rather call it “motivation by concern” and, not least, “motivation by ideals”. Also note that being motivated by fear is not necessarily a bad thing. Sometimes fear is adequate. All the best, Wolfgang
On Wed, 15 Jul 2026 at 03:24, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Hi, Simon (Jakobi)!
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills.
I definitely don’t want to be offensive, but is it a good idea to contribute code to a software that many are relying on if you’re “pretty bad” at writing code?
When Simon said he is "pretty bad and extremely slow to write code", he probably did not mean that he produces bad quality code. In my experience I have seen programmers who are very slow but produce really good quality code and those who are really fast but produce bad code (correct code but harder to understand and maintain). It may be directly related to one's inherent capacity to maintain (a larger) context in their brain. Some people can maintain a large context and juggle with it quickly while others cannot. Some programmers who fall in the first category are quick to analyze and understand even complex code and that is what makes them not so good programmers because they tend to think that the code is easy to understand and there is no need to build better abstractions. Programmers in the latter category tend to build better abstractions because they fear they may not be able to understand their own code later if they do not do that. I know we cannot generalize this too much but I have seen many examples of this in practice. When Simon said "I was relieved that I can now contribute without being so limited", I can understand it this way -- now you do not need to struggle keeping that context in mind, LLMs can assist you where you lack. LLMs are particularly good at juggling a large context pretty quickly, but they are not good at abstractions and that is where a good programmer comes in. You can get the LLM to build the context and do the lower level labor job, and take care of building better abstractions themselves. However, I understand that LLMs can make it difficult to mentor newbies and grow them into good programmers (and this is my biggest worry), but that is a different problem to solve and may have a different solution. I may have misunderstood what Simon meant, but this is how I interpret it. -harendra
I don't know if I'm a "good programmer", but I definitely fall on the side of the spectrum where LLMs can hold the context I can't. With current models, I can build better abstractions than they can (and certainly better tests). But my working memory seems to be about 63 bytes, which limits my ability to do a lot of interesting things. With LLMs, I have become a lot more motivated and effective. It's similar to the effect I felt when I switched to Haskell in the first place -- though obviously for very different reasons. I'll have to join Moritz in signing off all of my contributions with "LLMs may have been used in the production of this work." I am reminded of the ubiquitous Prop 65 warnings in California. E.g. https://commons.wikimedia.org/wiki/File:Disneyland_Prop_65_Warning.jpg -Bryan (This message *not* generated with LLMS) On Thu, 16 Jul 2026 at 11:33, Harendra Kumar via ghc-devs < ghc-devs@haskell.org> wrote:
On Wed, 15 Jul 2026 at 03:24, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Hi, Simon (Jakobi)!
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills.
I definitely don’t want to be offensive, but is it a good idea to contribute code to a software that many are relying on if you’re “pretty bad” at writing code?
When Simon said he is "pretty bad and extremely slow to write code", he probably did not mean that he produces bad quality code. In my experience I have seen programmers who are very slow but produce really good quality code and those who are really fast but produce bad code (correct code but harder to understand and maintain). It may be directly related to one's inherent capacity to maintain (a larger) context in their brain. Some people can maintain a large context and juggle with it quickly while others cannot. Some programmers who fall in the first category are quick to analyze and understand even complex code and that is what makes them not so good programmers because they tend to think that the code is easy to understand and there is no need to build better abstractions. Programmers in the latter category tend to build better abstractions because they fear they may not be able to understand their own code later if they do not do that. I know we cannot generalize this too much but I have seen many examples of this in practice.
When Simon said "I was relieved that I can now contribute without being so limited", I can understand it this way -- now you do not need to struggle keeping that context in mind, LLMs can assist you where you lack. LLMs are particularly good at juggling a large context pretty quickly, but they are not good at abstractions and that is where a good programmer comes in. You can get the LLM to build the context and do the lower level labor job, and take care of building better abstractions themselves. However, I understand that LLMs can make it difficult to mentor newbies and grow them into good programmers (and this is my biggest worry), but that is a different problem to solve and may have a different solution.
I may have misunderstood what Simon meant, but this is how I interpret it.
-harendra _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I'll have to join Moritz in signing off all of my contributions with "LLMs may have been used in the production of this work."
Let me just check. The draft explicitly says that there is no need to declare *use *of LLMs per se. It says only " An acknowledgement is only needed if LLM-generated material forms part of the thing that you are asking others to examine". If the policy gives the impression of asking you to declare if "LLMs have been used", I should correct that. A number of people on this thread have said how helpful they have found LLM technology to help them navigate the code base, identify errors, build tests, even build abstractions, and I did not intend the draft policy to discourage them from doing so. But sometimes such discouragement can be somehow implicit, so please suggest wording improvements that would avoid creating this misunderstanding. Does that help at all? Simon On Thu, 16 Jul 2026 at 09:50, Bryan Richter via ghc-devs < ghc-devs@haskell.org> wrote:
I don't know if I'm a "good programmer", but I definitely fall on the side of the spectrum where LLMs can hold the context I can't. With current models, I can build better abstractions than they can (and certainly better tests). But my working memory seems to be about 63 bytes, which limits my ability to do a lot of interesting things. With LLMs, I have become a lot more motivated and effective. It's similar to the effect I felt when I switched to Haskell in the first place -- though obviously for very different reasons.
I'll have to join Moritz in signing off all of my contributions with "LLMs may have been used in the production of this work."
I am reminded of the ubiquitous Prop 65 warnings in California. E.g. https://commons.wikimedia.org/wiki/File:Disneyland_Prop_65_Warning.jpg
-Bryan
(This message *not* generated with LLMS)
On Thu, 16 Jul 2026 at 11:33, Harendra Kumar via ghc-devs < ghc-devs@haskell.org> wrote:
On Wed, 15 Jul 2026 at 03:24, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Hi, Simon (Jakobi)!
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills.
I definitely don’t want to be offensive, but is it a good idea to contribute code to a software that many are relying on if you’re “pretty bad” at writing code?
When Simon said he is "pretty bad and extremely slow to write code", he probably did not mean that he produces bad quality code. In my experience I have seen programmers who are very slow but produce really good quality code and those who are really fast but produce bad code (correct code but harder to understand and maintain). It may be directly related to one's inherent capacity to maintain (a larger) context in their brain. Some people can maintain a large context and juggle with it quickly while others cannot. Some programmers who fall in the first category are quick to analyze and understand even complex code and that is what makes them not so good programmers because they tend to think that the code is easy to understand and there is no need to build better abstractions. Programmers in the latter category tend to build better abstractions because they fear they may not be able to understand their own code later if they do not do that. I know we cannot generalize this too much but I have seen many examples of this in practice.
When Simon said "I was relieved that I can now contribute without being so limited", I can understand it this way -- now you do not need to struggle keeping that context in mind, LLMs can assist you where you lack. LLMs are particularly good at juggling a large context pretty quickly, but they are not good at abstractions and that is where a good programmer comes in. You can get the LLM to build the context and do the lower level labor job, and take care of building better abstractions themselves. However, I understand that LLMs can make it difficult to mentor newbies and grow them into good programmers (and this is my biggest worry), but that is a different problem to solve and may have a different solution.
I may have misunderstood what Simon meant, but this is how I interpret it.
-harendra _______________________________________________ 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
Hi, Harendra! Am Do 16.07.2026 14:03 schrieb Harendra Kumar:
When Simon said he is "pretty bad and extremely slow to write code", he probably did not mean that he produces bad quality code. In my experience I have seen programmers who are very slow but produce really good quality code and those who are really fast but produce bad code (correct code but harder to understand and maintain).
I completely agree that “bad” can mean many things, and I’m certainly not the fastest programmer myself. However, Simon said that his coding is “extremely slow” *and* “pretty bad”; so I assumed that the issue is not only slowness.
Some people can maintain a large context and juggle with it quickly while others cannot. Some programmers who fall in the first category are quick to analyze and understand even complex code and that is what makes them not so good programmers because they tend to think that the code is easy to understand and there is no need to build better abstractions. Programmers in the latter category tend to build better abstractions because they fear they may not be able to understand their own code later if they do not do that.
[…]
[N]ow you do not need to struggle keeping that context in mind, LLMs can assist you where you lack. You can get the LLM to build the context and do the lower level labor job, and take care of building better abstractions themselves.
Well, if the LLM assists the “slow” programmers, who cannot deal with large contexts, doesn’t this mean that those programmers will care *less* about building abstractions, because the incentive to build them, which you describe, is largely gone? Or do you mean to say that the LLM will not only maintain the context but also build the abstractions? If yes, is abstraction building really something that an LLM is useful for, and does it make sense for people who used to be strong in abstraction building to delegate this to a machine? All the best, Wolfgang
On Thu, 16 Jul 2026 at 18:51, Wolfgang Jeltsch <wolfgang@well-typed.com> wrote:
Well, if the LLM assists the “slow” programmers, who cannot deal with large contexts, doesn’t this mean that those programmers will care *less* about building abstractions, because the incentive to build them, which you describe, is largely gone?
In my experience LLMs are *not* good at building abstractions or even reusing code, they can lead to code replication and code bloat. And yes the incentive structure to maintain discipline is not favorable. And yes it will affect everyone, not just a particular category of programmers. They may not feel the need to write better code because LLMs will take care of understanding the code, they do not have to. But this does not mean that we must not use LLMs altogether. A responsible use can make a good programmer very productive. You can take care of the big picture and abstractions while LLMs can potentially help you fill in the local details faster which you can review quickly. I think the entire discussion is around the premise that most people will not be responsible, if that problem arises and becomes a big burden then sure it warrants revisiting the solution.
Or do you mean to say that the LLM will not only maintain the context but also build the abstractions? If yes, is abstraction building really something that an LLM is useful for, and does it make sense for people who used to be strong in abstraction building to delegate this to a machine?
I was trying to say the opposite. You take care of the discipline and abstractions, LLMs will take care of the context. -harendra
Good morning everyone! As I keep having offline discussions around this as well, what I'm being told fairly often falls into primarily two buckets: (a) I do not want people to use LLMs, they are fundamentally detrimental to human psychology and people hurt themselves and potentially others. And yes there are research papers that show this may be the case. (b) I do not want to talk to machines. I want to collaborate with humans on a shared endeavour. (c) I don't want to read LLM generated output. (d) I do not want someone to take my review comments, I spent significant time on, feed them into some LLM, and paste the response to me. (See (b)). I hope it's no surprise that I'm actually in full support for (b), and (d) while I don't think GHC as a project is the right place to try and enforce (a) even. I personally don't mind (c), and as.I outlined in many previous emails, I don't even think I can distinguish how code was conceived and if what I'm reading is human, assisted, partially assisted, contracted out, ... conceived. I have absolutely no objection to declaration of assistive tool use or attribution. I can fully get behind that, provided that it does not imply a rating of the person doing so. What I object to, and continue to object to is that we try to solve (b) _and_ (c) with some form of *strong preference* of *human written* code. While also trying to address (c) with attribution. The policy as it stands tells me that I am a less valued member of the community because I do not follow the same values "strongly prefer human written" code. The policy also implies that my contributions will be regarded as less preferable simply because I object to disabling copilot or similar tools while writing patches. And none of this has anything to do with me actually interacting with people, reaching out to people to get contributions reviewed, responding to comments on contributions, writing long emails by hand, because I actually care about GHC being a welcoming place to people of all kinds of beliefs. If your belief just happens to be that you believe you can create better contributions using assistive tools, why do we tell people that we strongly discourage them from doing so, without actually knowing what they will contribute? At the same time, someone could be an amazing engineer producing exceptionally high quality contributions by hand, but be socially so inept that they frustrate reviewers to the point where they just don't want to interact with them. This policy ultimately tells me that I should leave the GHC community because I do not share the same strong convictions around hand written code, and will be relegated to a second class of de-skilled engineers that are ok with using assistive tools. My contributions (and by extension I) will be viewed less favourably than contributions from people who (maybe just claim) to have written their contributions by hand. This is the classification I fundamentally object to. And not necessarily just because it puts me into a lower class, but because I believe this makes GHC a less open community, and bars people who might have considered contributing to GHC, from actually contributing. Even worse, the focus of the policy is not on what we even try to address: the human connection (what), but on people's preferences (how). So we'll be left with the following: (1) AI slop slingers will not be deterred, they don't care about the values we supposedly try to enshrine anyway. (2) People who actually care and read the AI policy, but feel deterred because they don't share the same strong preference for human written code, irrespective of how much they use assistive tooling, or if they are active on IRC, Discourse, Matrix, ... and actually value the human connection/interaction/collaboration as well. We broadly classify them as less preferred engineers. From the policy document: *Our overriding principles are:*- We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment. - We want to build software that is the province of humans, where it is understood and developed by a community of people. - We want to build a code base that we can be proud of: well structured, well documented, even beautiful. [...] *P3: Strong preference for human authorship*- *We strongly prefer human-written code. * You can use LLMs to analyse, review, produce ideas and prototypes, but we would much prefer you to write the code of your MR yourself. [...] - *We strongly prefer human-written documentation.* Again, writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand. In contrast LLMs can, at zero cost to you, blurt out pages of plausible-looking text that may contain much pertinent information, but in which that information is sometimes concealed in a fog of words. (Of course this can happen with humans too!) We strongly urge the discipline of writing documentation, especially Notes, yourself. By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word. [...] This pretty much reads to me: We want an inclusive and vibrant community that is proud of their product, but if you consider using assistive technology when crafting code, we'd prefer you stay away. Maybe that *is* the message we want to send. But then let's just be explicitly upfront about this. I consider myself part of this community, and I do not stand behind this message. I also know that this message would preclude at least some people from the community I liked to work with from contributing to ghc going forward, because I know they use assistive technologies to various degrees in writing code. Best, Moritz On Thu, 16 Jul 2026 at 21:04, Harendra Kumar via ghc-devs < ghc-devs@haskell.org> wrote:
On Thu, 16 Jul 2026 at 18:51, Wolfgang Jeltsch <wolfgang@well-typed.com> wrote:
Well, if the LLM assists the “slow” programmers, who cannot deal with large contexts, doesn’t this mean that those programmers will care *less* about building abstractions, because the incentive to build them, which you describe, is largely gone?
In my experience LLMs are *not* good at building abstractions or even reusing code, they can lead to code replication and code bloat. And yes the incentive structure to maintain discipline is not favorable. And yes it will affect everyone, not just a particular category of programmers. They may not feel the need to write better code because LLMs will take care of understanding the code, they do not have to. But this does not mean that we must not use LLMs altogether. A responsible use can make a good programmer very productive. You can take care of the big picture and abstractions while LLMs can potentially help you fill in the local details faster which you can review quickly. I think the entire discussion is around the premise that most people will not be responsible, if that problem arises and becomes a big burden then sure it warrants revisiting the solution.
Or do you mean to say that the LLM will not only maintain the context but also build the abstractions? If yes, is abstraction building really something that an LLM is useful for, and does it make sense for people who used to be strong in abstraction building to delegate this to a machine?
I was trying to say the opposite. You take care of the discipline and abstractions, LLMs will take care of the context.
-harendra
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
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
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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
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, Josh On 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, 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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
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, Moritz On 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, Josh
On 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, 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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
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, Josh On 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, Moritz
On 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, Josh
On 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, 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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
Josh, I am not claiming that LLMs are equivalent to prescription glasses, nor that everyone who uses one is incapable of programming without it. My concern is that mandatory disclosure combined with an explicit preference against the disclosed method repeatedly places people who use that method into a non-preferred class of participation. I agree that merely saying “I reviewed it” is not evidence of sufficient understanding. I want us to require demonstrated ownership and understanding: the ability to explain, defend, modify, and maintain the contribution. I do not want us to use textual provenance as a special qualification for those things. Nor is my argument that every imperfectly enforceable rule is invalid. My concern is incentive design. This particular rule gives honest assisted contributors an immediate disadvantage while giving people who conceal the same conduct the ordinary preferred status. It may deter some low-effort contributors, but it may also select against exactly the conscientious people on whose disclosure the policy depends. My argument is that the combination of mandatory disclosure and a strong preference for human-written code does two things: 1. it classifies contributors into a preferred and a non-preferred category according to their production method; and 2. it makes concealment more advantageous than honest disclosure. 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: 1. We value all contributors and all contributions. 2. Contributors must declare any use of Emacs before review. 3. We strongly prefer Vim-authored patches, because modal editing encourages deliberate changes and reduces accidental modifications. 4. Reviewers may take Emacs usage into account and are free to decline Emacs-assisted patches. 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: - contributors whose normal method is institutionally preferred and unmarked; - contributors whose normal method is institutionally non-preferred, must be declared, and may reduce trust or access to review. 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. On Fri, 17 Jul 2026 at 18:36, Josh Meredith <joshmeredith2008@gmail.com> wrote:
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, Josh
On 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, Moritz
On 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, Josh
On 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, 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 <https://docs.google.com/document/d/11HkycOsCZvNfSHhud5n7V34t8iVHkF4qdOUqdzqyERo/edit?usp=sharing> 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
Moritz reads the draft policy as saying We want an inclusive and vibrant community that is proud of their product,
but if you consider using assistive technology when crafting code, we'd prefer you stay away.
In that case, the message you are hearing is different from the one I intended to send. Can you help me improve the wording so that it is less easy to misinterpret? The message I intended was: You are welcome to use whatever assistive technologies you please (IDEs, test generators, spell checkers -- and LLMs), provided they are consistent with the principles set out above. [Moritz summarised this as "an inclusive and vibrant community that is proud of their product.] The draft explicitly says nothing about what assistive technologies you use to produce your MR. So "using assistive techologies" is explicitly fine. If that does not come across, could you suggest workding that would make it clearer? Would it help to say the above para explicitly? So we can focus on the MR itself. A strong preference for human authorship is not a blanket ban. If you use an LLM to produce an MR in which you have reviewed and understood every line in the same detail as if you'd written it yourself, that's fine according to the draft. (Would it help to say that explicitly?) To me, that is tantamount to human authorship. What is not OK, and I think Moritiz would agree, is using an LLM to blurt out 1000 lines of code that no one has read, let alone understood. I think there is common ground here. Perhaps my draft wording has failed to articulate it. Can you suggest words that better convey the intent? Thanks Simon On Fri, 17 Jul 2026 at 03:01, Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Good morning everyone!
As I keep having offline discussions around this as well, what I'm being told fairly often falls into primarily two buckets:
(a) I do not want people to use LLMs, they are fundamentally detrimental to human psychology and people hurt themselves and potentially others. And yes there are research papers that show this may be the case. (b) I do not want to talk to machines. I want to collaborate with humans on a shared endeavour. (c) I don't want to read LLM generated output. (d) I do not want someone to take my review comments, I spent significant time on, feed them into some LLM, and paste the response to me. (See (b)).
I hope it's no surprise that I'm actually in full support for (b), and (d) while I don't think GHC as a project is the right place to try and enforce (a) even. I personally don't mind (c), and as.I outlined in many previous emails, I don't even think I can distinguish how code was conceived and if what I'm reading is human, assisted, partially assisted, contracted out, ... conceived. I have absolutely no objection to declaration of assistive tool use or attribution. I can fully get behind that, provided that it does not imply a rating of the person doing so.
What I object to, and continue to object to is that we try to solve (b) _and_ (c) with some form of *strong preference* of *human written* code. While also trying to address (c) with attribution.
The policy as it stands tells me that I am a less valued member of the community because I do not follow the same values "strongly prefer human written" code. The policy also implies that my contributions will be regarded as less preferable simply because I object to disabling copilot or similar tools while writing patches. And none of this has anything to do with me actually interacting with people, reaching out to people to get contributions reviewed, responding to comments on contributions, writing long emails by hand, because I actually care about GHC being a welcoming place to people of all kinds of beliefs. If your belief just happens to be that you believe you can create better contributions using assistive tools, why do we tell people that we strongly discourage them from doing so, without actually knowing what they will contribute?
At the same time, someone could be an amazing engineer producing exceptionally high quality contributions by hand, but be socially so inept that they frustrate reviewers to the point where they just don't want to interact with them.
This policy ultimately tells me that I should leave the GHC community because I do not share the same strong convictions around hand written code, and will be relegated to a second class of de-skilled engineers that are ok with using assistive tools. My contributions (and by extension I) will be viewed less favourably than contributions from people who (maybe just claim) to have written their contributions by hand. This is the classification I fundamentally object to. And not necessarily just because it puts me into a lower class, but because I believe this makes GHC a less open community, and bars people who might have considered contributing to GHC, from actually contributing. Even worse, the focus of the policy is not on what we even try to address: the human connection (what), but on people's preferences (how).
So we'll be left with the following: (1) AI slop slingers will not be deterred, they don't care about the values we supposedly try to enshrine anyway. (2) People who actually care and read the AI policy, but feel deterred because they don't share the same strong preference for human written code, irrespective of how much they use assistive tooling, or if they are active on IRC, Discourse, Matrix, ... and actually value the human connection/interaction/collaboration as well. We broadly classify them as less preferred engineers.
From the policy document:
*Our overriding principles are:*- We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment. - We want to build software that is the province of humans, where it is understood and developed by a community of people. - We want to build a code base that we can be proud of: well structured, well documented, even beautiful. [...]
*P3: Strong preference for human authorship*- *We strongly prefer human-written code. * You can use LLMs to analyse, review, produce ideas and prototypes, but we would much prefer you to write the code of your MR yourself. [...] - *We strongly prefer human-written documentation.* Again, writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand. In contrast LLMs can, at zero cost to you, blurt out pages of plausible-looking text that may contain much pertinent information, but in which that information is sometimes concealed in a fog of words. (Of course this can happen with humans too!) We strongly urge the discipline of writing documentation, especially Notes, yourself. By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word. [...]
This pretty much reads to me:
We want an inclusive and vibrant community that is proud of their product, but if you consider using assistive technology when crafting code, we'd prefer you stay away.
Maybe that *is* the message we want to send. But then let's just be explicitly upfront about this. I consider myself part of this community, and I do not stand behind this message. I also know that this message would preclude at least some people from the community I liked to work with from contributing to ghc going forward, because I know they use assistive technologies to various degrees in writing code.
Best, Moritz
On Thu, 16 Jul 2026 at 21:04, Harendra Kumar via ghc-devs < ghc-devs@haskell.org> wrote:
On Thu, 16 Jul 2026 at 18:51, Wolfgang Jeltsch <wolfgang@well-typed.com> wrote:
Well, if the LLM assists the “slow” programmers, who cannot deal with large contexts, doesn’t this mean that those programmers will care *less* about building abstractions, because the incentive to build them, which you describe, is largely gone?
In my experience LLMs are *not* good at building abstractions or even reusing code, they can lead to code replication and code bloat. And yes the incentive structure to maintain discipline is not favorable. And yes it will affect everyone, not just a particular category of programmers. They may not feel the need to write better code because LLMs will take care of understanding the code, they do not have to. But this does not mean that we must not use LLMs altogether. A responsible use can make a good programmer very productive. You can take care of the big picture and abstractions while LLMs can potentially help you fill in the local details faster which you can review quickly. I think the entire discussion is around the premise that most people will not be responsible, if that problem arises and becomes a big burden then sure it warrants revisiting the solution.
Or do you mean to say that the LLM will not only maintain the context but also build the abstractions? If yes, is abstraction building really something that an LLM is useful for, and does it make sense for people who used to be strong in abstraction building to delegate this to a machine?
I was trying to say the opposite. You take care of the discipline and abstractions, LLMs will take care of the context.
-harendra
_______________________________________________ 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
Simon, as you'll find my sibling email in your inbox right now. I've spent a lot of time re-reading this thread, and the discussions I've had elsewhere. The fundamental disagreement between Julian and I (as I have come to believe) is the "human-written" part in P3. This is (as far as I understand) integral to Julian, as it signifies the craft of programming. In my view the "hand-written" qualification is an indefensible restriction on the freedom of contributors. So while I think P3 is going too far in prescribing how contributors should produce their contributions, my understanding is that it is not going far enough in Julians view. I don't know how to resolve this disagreement. My concern with the current wording of "strongly prefer human-written" code is that it stratifies contributions, and by extension the authors of those contributions into more and less desirable contributors. The title of P3 is "human authorship", but that is much broader than the "human-written" bullet points. This of course is my view, after re-reading the discussion I've had here and through other media multiple times now. Here is an alternative mush shorter text, which I could get easily behind: *GHC exists not only to produce a compiler, but to sustain a human community engaged in the craft of understanding, writing, reviewing, and maintaining software.* *GHC as a human craft* 1. *GHC is a human community, not merely a software-production system. *Programming, review, documentation, mentoring, curiosity, taste, and enjoyment are valuable in themselves; maximizing productivity is not our primary goal. 2. *We strongly prefer human authorship of code and documentation.* LLMs may assist exploration, analysis, prototyping, or review, but they should not displace human understanding, judgment, agency, and responsibility. 3. *Substantial LLM assistance must be disclosed before review.* Provenance is relevant information, not merely private workflow, because it may affect trust, reviewer interest, and willingness to engage. 4. *Every contribution must have a human owner.* That person must understand the work, explain its design, walk reviewers through it, respond meaningfully to criticism, and take responsibility for the contribution and for addressing problems found in it. 5. *Review remains voluntary.* Nobody is required to review an LLM-assisted contribution, and substantially generated contributions may need to find a willing reviewer before being marked ready for review. 6. *No one should be pressured to adopt LLMs to remain relevant.* LLM-assisted speed and volume must not redefine the expected pace of contribution or drive people who value human programming out of the community. 7. *This constitution expresses what kind of community we choose to be.* Its purpose is not only to reject defective patches, but to preserve programming as a meaningful human craft and shared identity. I agree with all of the above. The remaining question is what we mean by human authorship. Does preserving human craft require that a human personally compose the substantive final implementation, or can an implementation that is machine-generated but human-directed, critically evaluated, understood, adopted, and responsibly maintained still be an expression of human authorship and craft? My answer is: yes, it can. My current understanding of Julian’s position is not necessarily that such contributions must be forbidden, but that personal composition has independent value and that assisted authorship should therefore not be treated as equivalent to personally composed work. Julian, is that a fair description of the disagreement? I don't even disagree with the fact that it has independent value; it has! I value personal composition as a practice; I reject personal composition as a hierarchy. Best, Moritz On Fri, 17 Jul 2026 at 15:30, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Moritz reads the draft policy as saying
We want an inclusive and vibrant community that is proud of their product,
but if you consider using assistive technology when crafting code, we'd prefer you stay away.
In that case, the message you are hearing is different from the one I intended to send. Can you help me improve the wording so that it is less easy to misinterpret?
The message I intended was:
You are welcome to use whatever assistive technologies you please (IDEs, test generators, spell checkers -- and LLMs), provided they are consistent with the principles set out above. [Moritz summarised this as "an inclusive and vibrant community that is proud of their product.]
The draft explicitly says nothing about what assistive technologies you use to produce your MR. So "using assistive techologies" is explicitly fine. If that does not come across, could you suggest workding that would make it clearer? Would it help to say the above para explicitly?
So we can focus on the MR itself. A strong preference for human authorship is not a blanket ban. If you use an LLM to produce an MR in which you have reviewed and understood every line in the same detail as if you'd written it yourself, that's fine according to the draft. (Would it help to say that explicitly?) To me, that is tantamount to human authorship.
What is not OK, and I think Moritiz would agree, is using an LLM to blurt out 1000 lines of code that no one has read, let alone understood.
I think there is common ground here. Perhaps my draft wording has failed to articulate it. Can you suggest words that better convey the intent?
Thanks
Simon
On Fri, 17 Jul 2026 at 03:01, Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Good morning everyone!
As I keep having offline discussions around this as well, what I'm being told fairly often falls into primarily two buckets:
(a) I do not want people to use LLMs, they are fundamentally detrimental to human psychology and people hurt themselves and potentially others. And yes there are research papers that show this may be the case. (b) I do not want to talk to machines. I want to collaborate with humans on a shared endeavour. (c) I don't want to read LLM generated output. (d) I do not want someone to take my review comments, I spent significant time on, feed them into some LLM, and paste the response to me. (See (b)).
I hope it's no surprise that I'm actually in full support for (b), and (d) while I don't think GHC as a project is the right place to try and enforce (a) even. I personally don't mind (c), and as.I outlined in many previous emails, I don't even think I can distinguish how code was conceived and if what I'm reading is human, assisted, partially assisted, contracted out, ... conceived. I have absolutely no objection to declaration of assistive tool use or attribution. I can fully get behind that, provided that it does not imply a rating of the person doing so.
What I object to, and continue to object to is that we try to solve (b) _and_ (c) with some form of *strong preference* of *human written* code. While also trying to address (c) with attribution.
The policy as it stands tells me that I am a less valued member of the community because I do not follow the same values "strongly prefer human written" code. The policy also implies that my contributions will be regarded as less preferable simply because I object to disabling copilot or similar tools while writing patches. And none of this has anything to do with me actually interacting with people, reaching out to people to get contributions reviewed, responding to comments on contributions, writing long emails by hand, because I actually care about GHC being a welcoming place to people of all kinds of beliefs. If your belief just happens to be that you believe you can create better contributions using assistive tools, why do we tell people that we strongly discourage them from doing so, without actually knowing what they will contribute?
At the same time, someone could be an amazing engineer producing exceptionally high quality contributions by hand, but be socially so inept that they frustrate reviewers to the point where they just don't want to interact with them.
This policy ultimately tells me that I should leave the GHC community because I do not share the same strong convictions around hand written code, and will be relegated to a second class of de-skilled engineers that are ok with using assistive tools. My contributions (and by extension I) will be viewed less favourably than contributions from people who (maybe just claim) to have written their contributions by hand. This is the classification I fundamentally object to. And not necessarily just because it puts me into a lower class, but because I believe this makes GHC a less open community, and bars people who might have considered contributing to GHC, from actually contributing. Even worse, the focus of the policy is not on what we even try to address: the human connection (what), but on people's preferences (how).
So we'll be left with the following: (1) AI slop slingers will not be deterred, they don't care about the values we supposedly try to enshrine anyway. (2) People who actually care and read the AI policy, but feel deterred because they don't share the same strong preference for human written code, irrespective of how much they use assistive tooling, or if they are active on IRC, Discourse, Matrix, ... and actually value the human connection/interaction/collaboration as well. We broadly classify them as less preferred engineers.
From the policy document:
*Our overriding principles are:*- We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment. - We want to build software that is the province of humans, where it is understood and developed by a community of people. - We want to build a code base that we can be proud of: well structured, well documented, even beautiful. [...]
*P3: Strong preference for human authorship*- *We strongly prefer human-written code. * You can use LLMs to analyse, review, produce ideas and prototypes, but we would much prefer you to write the code of your MR yourself. [...] - *We strongly prefer human-written documentation.* Again, writing documentation yourself forces you to articulate each word, to think about what it is saying and what a future reader will understand. In contrast LLMs can, at zero cost to you, blurt out pages of plausible-looking text that may contain much pertinent information, but in which that information is sometimes concealed in a fog of words. (Of course this can happen with humans too!) We strongly urge the discipline of writing documentation, especially Notes, yourself. By all means use an LLM to generate ideas, points to cover, and structure, but the best way to take responsibility for every word is to write every word. [...]
This pretty much reads to me:
We want an inclusive and vibrant community that is proud of their product, but if you consider using assistive technology when crafting code, we'd prefer you stay away.
Maybe that *is* the message we want to send. But then let's just be explicitly upfront about this. I consider myself part of this community, and I do not stand behind this message. I also know that this message would preclude at least some people from the community I liked to work with from contributing to ghc going forward, because I know they use assistive technologies to various degrees in writing code.
Best, Moritz
On Thu, 16 Jul 2026 at 21:04, Harendra Kumar via ghc-devs < ghc-devs@haskell.org> wrote:
On Thu, 16 Jul 2026 at 18:51, Wolfgang Jeltsch <wolfgang@well-typed.com> wrote:
Well, if the LLM assists the “slow” programmers, who cannot deal with large contexts, doesn’t this mean that those programmers will care *less* about building abstractions, because the incentive to build them, which you describe, is largely gone?
In my experience LLMs are *not* good at building abstractions or even reusing code, they can lead to code replication and code bloat. And yes the incentive structure to maintain discipline is not favorable. And yes it will affect everyone, not just a particular category of programmers. They may not feel the need to write better code because LLMs will take care of understanding the code, they do not have to. But this does not mean that we must not use LLMs altogether. A responsible use can make a good programmer very productive. You can take care of the big picture and abstractions while LLMs can potentially help you fill in the local details faster which you can review quickly. I think the entire discussion is around the premise that most people will not be responsible, if that problem arises and becomes a big burden then sure it warrants revisiting the solution.
Or do you mean to say that the LLM will not only maintain the context but also build the abstractions? If yes, is abstraction building really something that an LLM is useful for, and does it make sense for people who used to be strong in abstraction building to delegate this to a machine?
I was trying to say the opposite. You take care of the discipline and abstractions, LLMs will take care of the context.
-harendra
_______________________________________________ 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
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
It doesn't sound like the requirement would be for a reviewer or contributor not to consult an LLM to help them understand something they previously didn't; only that the written reply, after understanding, come from them. In other words, a contributor would need to understand whatever they're asking another person to read, whether text or code.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
I'd hope that contributors wouldn't use any function -- pre-existing or not -- that they didn't have an understanding of, including relevant performance characteristics.
[...] LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
As I read it, there's no prohibition on doing any of these things! A person would be welcome to use an LLM to fuzz or do automated testing, but then they'd need to verify themselves that the bug is real, and explain it, rather than putting that verification work onto others. They'd also be free to use an LLM to understand the bug(s) they discovered. --- For what it's worth, from the peanut gallery of people who've only contributed to GHC in relatively small ways, I was quite pleased to read SPJ's nuanced proposal and found its suggestions very reasonable and forward-thinking. It reminded me about the excitement of working with other (real) people on a project as wonderful as GHC. - Tom
Thanks for taking the time to write, Simon. I have updated my draft - Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help. I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours. For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most. Instead of trying to discourage contributions that involve LLMs, I think
this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands. thanks again Simon On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well: LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2). I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach. Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy. I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever. Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ... But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it. In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized. Best, Moritz On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I think
this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
I think it's fine to make the argument against. But clearly the suggested policy is not a LLM ban. It seems extremely clear to me that no matter how it will look at the end it won't be a LLM ban. So perhaps focusing on a hypothetical ban is not the best use of anyones time at this point. Clearly the discussion has moved past that. ------------ On the point of language barriers. Personally I'm fine with someone writing texts in one language and then using whatever translation tool they prefer to translate their text. I don't think anyone actually disagrees with this. *I still think it's good to point this out when doing so as it can help avoid misunderstandings. *Idoms can be very confusing when translated. I've found that dealing with a text originating in another language is easier if I know about that fact. In my experience knowing it's been translated, and from what language, can make decyphering certain phrases that are translated badly easier. -------------
- “LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source.
You can put "Andreas Klebinger reviewing AI generated MRs" down as a source if you like. Or just look for a paper. I found this one in 2 Minutes for example: https://arxiv.org/abs/2508.21634 Yeah it's based on older models. I'm sure you will have issues with it's methodology. But it mostly matches my experience when reviewing code in that there *are* differences between the kinds of code and bugs a human would write and a model would generate. I'm sure there are more such papers if one really wants to look further. I have seen people put up AI MRs with bugs that contained bugs that a humand understanding the structure of GHC would be *very* unlikely to make. I'm not pointing at specific AI's because the point here is not to name and shame them. I'm not even saying they are always worse. For example I watch out more closely for shadowing bugs in human written code than I do in AI generated code. They are just different in a way where I as reviewer see it as valuable to know about the origin.
I am so vehemently against a policy that tries to classify LLMs as something special.
Personally I don't see the big deal. I attribute it when I use code from some library. When I implement an algorithm from some paper I reference it. When I let AI do most of the work I similarly do the same. There are references to stack overflow in GHC iirc and I think that's a good thing to be liberal in referencing your sources. Yes there is no clear cut here. There will be edge cases. What if you use it to review your hand written code and hand apply the suggested fixes? What about having the LLM apply them? What about ... it really doesn't matter. If I use a paper or a library as inspiration and then rework the algo massively it's up to me to decide if the reference is still useful. I don't see it as much different with LLMs. If there is honest confusion we can provide guide lines. But I'm not sure there really is. And if people sometimes get it wrong so be it. The goal here is not to ostracise contributions that are partially LLM generated. The goal is to make review easier. And if in 5 years no one can tell the difference between hand written contributions and LLMs we can simply change our policy. Maybe it's simply a point we will have to agree to disagree on. But as I see it with the state of this technology, and how it's used in practice, it's in GHCs best interest to ask people to mark LLM generated contributions as such for the time being. On 15/07/2026 07:00, Moritz Angermann via ghc-devs wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy: 1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
* Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. * Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) * Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that /involve /LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
> In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
> P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
> P2: Full responsibility
> You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
> P3: Strong preference for human authorship
> We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
> Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
> We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
Hello, I like the document Simon has written because it established expectations and it does so with nuance. I also might be in the minority, but it doesn't seem overly long to me. I view such documents as guidelines, rather than law, and as such I am not worried about it being "weaponized": if we have disagreements we should still discuss them directly rather then appealing to the document, as an arbiter if truth. Here are a few of my experiences with LLMs so far: * I find them very useful for refactoring code * For generating new code, I am still experimenting with the amount of guidance to give the LLM. My impression is that I tend to be a lot more controlling than other folks using them (I don't really try to "one shot" things). I do this because I find it a lot easier to review the code as it is being written, then doing it all at once after the fact. * For complex features, I find working on a plan with an LLM to be pretty handy: it's a bit like having a fancy rubber duck, to clarify my thinking and try to think of all possibilities * I've had some good luck with having the LLM find bugs in the code * I also find them a pretty handy tool for getting familiar with a new code base. I've used them to sketch architecture diagrams, pointing to important modules, and it is pretty convenient to be able to ask questions about where to look for things in the code On the more negative side: * It is important to clearly scope your work, as LLMs make it easy to make giant PRs, even if you do it a little bit at a time. I just did this on a project (not on purpose!), and now we have a giant PR that I am the only person who understands. I was too focused on implementing the features, and not thinking of how it would be reviewed, which is a mistake (in retrospect an obvious one) * We've had issues with "drive by PRs" where a new contributor dumps a bunch of code. Some of my colleagues try to review those, but I am inclined to just delete them unless I can get some engagement from the contributor and get a sense that they know what they did (which hasn't happened yet) I think that most of my experiences are aligned with the proposed GHC policy. The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit. Not so much opposed to this I just wouldn't know what to label. More long term, I think as a community, it would be useful to focus on getting more folks to be able to and comfortable to review code. Traditionally, I think we've encouraged new contributors to implement some small feature, and then have somebody experienced review their code. I wonder if this might work the other way around too, where a new contributor reviews a PR of an experienced contributor (perhaps in addition to another review). Anyway, I hope this helps! Cheers, Iavor On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I think
this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Thanks for your feedback Iavor. The only bit I have some reservations about is the bit that any LLM use
needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit.
I have clarified that section (P4). I never intended to cover "any LLM use", so I have made that more explicit. I intended NOT to require declaration of use of LLMs to help you find your way around the code base, draw diagrams etc. Just declare if the material you are asking others to review was LLM-generated, even if (P2) you take full responsibility for every line. Doing so is not a weakness; it just provides context. I hope that may address your unease. Simon On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
Hello,
I like the document Simon has written because it established expectations and it does so with nuance. I also might be in the minority, but it doesn't seem overly long to me. I view such documents as guidelines, rather than law, and as such I am not worried about it being "weaponized": if we have disagreements we should still discuss them directly rather then appealing to the document, as an arbiter if truth.
Here are a few of my experiences with LLMs so far: * I find them very useful for refactoring code * For generating new code, I am still experimenting with the amount of guidance to give the LLM. My impression is that I tend to be a lot more controlling than other folks using them (I don't really try to "one shot" things). I do this because I find it a lot easier to review the code as it is being written, then doing it all at once after the fact. * For complex features, I find working on a plan with an LLM to be pretty handy: it's a bit like having a fancy rubber duck, to clarify my thinking and try to think of all possibilities * I've had some good luck with having the LLM find bugs in the code * I also find them a pretty handy tool for getting familiar with a new code base. I've used them to sketch architecture diagrams, pointing to important modules, and it is pretty convenient to be able to ask questions about where to look for things in the code
On the more negative side: * It is important to clearly scope your work, as LLMs make it easy to make giant PRs, even if you do it a little bit at a time. I just did this on a project (not on purpose!), and now we have a giant PR that I am the only person who understands. I was too focused on implementing the features, and not thinking of how it would be reviewed, which is a mistake (in retrospect an obvious one) * We've had issues with "drive by PRs" where a new contributor dumps a bunch of code. Some of my colleagues try to review those, but I am inclined to just delete them unless I can get some engagement from the contributor and get a sense that they know what they did (which hasn't happened yet)
I think that most of my experiences are aligned with the proposed GHC policy. The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit. Not so much opposed to this I just wouldn't know what to label.
More long term, I think as a community, it would be useful to focus on getting more folks to be able to and comfortable to review code. Traditionally, I think we've encouraged new contributors to implement some small feature, and then have somebody experienced review their code. I wonder if this might work the other way around too, where a new contributor reviews a PR of an experienced contributor (perhaps in addition to another review).
Anyway, I hope this helps!
Cheers, Iavor
On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I think
this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Andreas, I should probably not have dealt in extremes to try to make my point. What I'm trying to convey is that LLMs are not special in the ability to produce poor code. They _do_ lower the bar, but LLMs are fundamentally orthogonal to the problem we face with them. As such I mostly question the necessity for large parts of the policy. Especially as I question the enforceability of the policy, and what value does a policy without teeth have? From the interactions you had with me, you might know that I deeply value simplicity over (unnecessary) complexity. And this policy as it grows to me becomes increasingly complex. I think we could do with a much shorter policy, that doesn't even mention LLMs/AI, ... and sets the general expectations that would cover much more than just the challenges with LLMs. I've taken the part from the policy that I consider very valuable and modified it slightly below. I would like us to set a frame that transcends LLM and similar concerns, and focuses on the outcome we want, not on the particulars. Best, Moritz *Basic principles of GHC Development:* - We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment. - We want to build software that is the province of humans, where it is understood and developed by a community of people. - We want to build a code base that we can be proud of: well structured, well documented, even beautiful. *Collaboration* - Human conversation. In offering a contribution to GHC you are becoming a valued part of a community of living, breathing people. You are offering your work for free, and members of the community are likewise offering their work to you for free, to review and improve your MR, and to help you to learn your way around the code base. They should treat you with respect, and you should treat them likewise. You are expected to enter a direct conversation with a human reviewer, and be able to fully motivate, explain and stand behind the contributions you offer. They want to talk to you. - Supporting contributors. We aspire to nurture a mutually-supportive community of human beings who contribute to GHC. GHC is a large code base, which can be intimidating. Many GHC experts hang out on ghc-devs mailing list, or the Matrix channel, and IRC, and are happy to help. Here's a list of channels <https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc>. - *No Right to Reviews*. Your contribution to GHC may not be automatically reviewed. There is only a small pool of active reviewers, and it is often best to reach out to people through the mailing list, irc, matrix, ... and find reviewers this way. We very much look forward to having you as a reviewer as well. Contributions that fail to enlist a reviewer or sheperd may be closed as-is after a reasonable timeframe (e.g. 3mo). *Always be sure that your MRs meet your own expectations on MRs you'd like to review.* - *Bad actors and poor quality contributions.* In the rare case where contributions to GHC are of sloppy, and poor quality, we reserve the right to ignore and eventually ban aspiring contributors. On Wed, 15 Jul 2026 at 15:44, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Thanks for your feedback Iavor.
The only bit I have some reservations about is the bit that any LLM use
needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit.
I have clarified that section (P4). I never intended to cover "any LLM use", so I have made that more explicit. I intended NOT to require declaration of use of LLMs to help you find your way around the code base, draw diagrams etc. Just declare if the material you are asking others to review was LLM-generated, even if (P2) you take full responsibility for every line. Doing so is not a weakness; it just provides context.
I hope that may address your unease.
Simon
On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
Hello,
I like the document Simon has written because it established expectations and it does so with nuance. I also might be in the minority, but it doesn't seem overly long to me. I view such documents as guidelines, rather than law, and as such I am not worried about it being "weaponized": if we have disagreements we should still discuss them directly rather then appealing to the document, as an arbiter if truth.
Here are a few of my experiences with LLMs so far: * I find them very useful for refactoring code * For generating new code, I am still experimenting with the amount of guidance to give the LLM. My impression is that I tend to be a lot more controlling than other folks using them (I don't really try to "one shot" things). I do this because I find it a lot easier to review the code as it is being written, then doing it all at once after the fact. * For complex features, I find working on a plan with an LLM to be pretty handy: it's a bit like having a fancy rubber duck, to clarify my thinking and try to think of all possibilities * I've had some good luck with having the LLM find bugs in the code * I also find them a pretty handy tool for getting familiar with a new code base. I've used them to sketch architecture diagrams, pointing to important modules, and it is pretty convenient to be able to ask questions about where to look for things in the code
On the more negative side: * It is important to clearly scope your work, as LLMs make it easy to make giant PRs, even if you do it a little bit at a time. I just did this on a project (not on purpose!), and now we have a giant PR that I am the only person who understands. I was too focused on implementing the features, and not thinking of how it would be reviewed, which is a mistake (in retrospect an obvious one) * We've had issues with "drive by PRs" where a new contributor dumps a bunch of code. Some of my colleagues try to review those, but I am inclined to just delete them unless I can get some engagement from the contributor and get a sense that they know what they did (which hasn't happened yet)
I think that most of my experiences are aligned with the proposed GHC policy. The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit. Not so much opposed to this I just wouldn't know what to label.
More long term, I think as a community, it would be useful to focus on getting more folks to be able to and comfortable to review code. Traditionally, I think we've encouraged new contributors to implement some small feature, and then have somebody experienced review their code. I wonder if this might work the other way around too, where a new contributor reviews a PR of an experienced contributor (perhaps in addition to another review).
Anyway, I hope this helps!
Cheers, Iavor
On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I
think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I think we could do with a much shorter policy, that doesn't even mention LLMs/AI
I agree that brevity and maybe simplicity could be improved. But being explicit about LLMs/AI is not unnecessary. People have been asking, and will keep asking, what our policy in this respect is. Pointing them to a document that doesn't acknowledge the thing they are asking about in any way will not be as helpful.
What I'm trying to convey is that LLMs are not special in the ability to produce poor code.
The goal of attributing LLM involvement is not to mark a contribution as bad. If I thought such MRs are categorically worse I would argue for a blanket ban instead of being onboard with this policy. I do agree with what you put into your condensed version. But personally I do want to see (mostly) LLM generated code to be marked as such. And the topic of LLMs to be explicitly addressed so we can point people at the policy instead of repeating the same discussion over and over again. On 15/07/2026 12:01, Moritz Angermann via ghc-devs wrote:
Andreas,
I should probably not have dealt in extremes to try to make my point. What I'm trying to convey is that LLMs are not special in the ability to produce poor code. They _do_ lower the bar, but LLMs are fundamentally orthogonal to the problem we face with them. As such I mostly question the necessity for large parts of the policy. Especially as I question the enforceability of the policy, and what value does a policy without teeth have?
From the interactions you had with me, you might know that I deeply value simplicity over (unnecessary) complexity. And this policy as it grows to me becomes increasingly complex. I think we could do with a much shorter policy, that doesn't even mention LLMs/AI, ... and sets the general expectations that would cover much more than just the challenges with LLMs.
I've taken the part from the policy that I consider very valuable and modified it slightly below. I would like us to set a frame that transcends LLM and similar concerns, and focuses on the outcome we want, not on the particulars.
Best, Moritz
*Basic principles of GHC Development:*
*
We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment.
*
We want to build software that is the province of humans, where it is understood and developed by a community of people.
*
We want to build a code base that we can be proud of: well structured, well documented, even beautiful.
*Collaboration*
*
Human conversation. In offering a contribution to GHC you are becoming a valued part of a community of living, breathing people. You are offering your work for free, and members of the community are likewise offering their work to you for free, to review and improve your MR, and to help you to learn your way around the code base.
They should treat you with respect, and you should treat them likewise. You are expected to enter a direct conversation with a human reviewer, and be able to fully motivate, explain and stand behind the contributions you offer. They want to talk to you.
*
Supporting contributors. We aspire to nurture a mutually-supportive community of human beings who contribute to GHC. GHC is a large code base, which can be intimidating. Many GHC experts hang out on ghc-devs mailing list, or the Matrix channel, and IRC, and are happy to help. Here's a list of channels <https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc>.
*
*No Right to Reviews*. Your contribution to GHC may not be automatically reviewed. There is only a small pool of active reviewers, and it is often best to reach out to people through the mailing list, irc, matrix, ... and find reviewers this way. We very much look forward to having you as a reviewer as well. Contributions that fail to enlist a reviewer or sheperd may be closed as-is after a reasonable timeframe (e.g. 3mo). *Always be sure that your MRs meet your own expectations on MRs you'd like to review.*
*
*Bad actors and poor quality contributions.* In the rare case where contributions to GHC are of sloppy, and poor quality, we reserve the right to ignore and eventually ban aspiring contributors.
On Wed, 15 Jul 2026 at 15:44, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:
Thanks for your feedback Iavor.
The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit.
I have clarified that section (P4). I never intended to cover "any LLM use", so I have made that more explicit. I intended NOT to require declaration of use of LLMs to help you find your way around the code base, draw diagrams etc. Just declare if the material you are asking others to review was LLM-generated, even if (P2) you take full responsibility for every line. Doing so is not a weakness; it just provides context.
I hope that may address your unease.
Simon
On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
Hello,
I like the document Simon has written because it established expectations and it does so with nuance. I also might be in the minority, but it doesn't seem overly long to me. I view such documents as guidelines, rather than law, and as such I am not worried about it being "weaponized": if we have disagreements we should still discuss them directly rather then appealing to the document, as an arbiter if truth.
Here are a few of my experiences with LLMs so far: * I find them very useful for refactoring code * For generating new code, I am still experimenting with the amount of guidance to give the LLM. My impression is that I tend to be a lot more controlling than other folks using them (I don't really try to "one shot" things). I do this because I find it a lot easier to review the code as it is being written, then doing it all at once after the fact. * For complex features, I find working on a plan with an LLM to be pretty handy: it's a bit like having a fancy rubber duck, to clarify my thinking and try to think of all possibilities * I've had some good luck with having the LLM find bugs in the code * I also find them a pretty handy tool for getting familiar with a new code base. I've used them to sketch architecture diagrams, pointing to important modules, and it is pretty convenient to be able to ask questions about where to look for things in the code On the more negative side: * It is important to clearly scope your work, as LLMs make it easy to make giant PRs, even if you do it a little bit at a time. I just did this on a project (not on purpose!), and now we have a giant PR that I am the only person who understands. I was too focused on implementing the features, and not thinking of how it would be reviewed, which is a mistake (in retrospect an obvious one) * We've had issues with "drive by PRs" where a new contributor dumps a bunch of code. Some of my colleagues try to review those, but I am inclined to just delete them unless I can get some engagement from the contributor and get a sense that they know what they did (which hasn't happened yet)
I think that most of my experiences are aligned with the proposed GHC policy. The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit. Not so much opposed to this I just wouldn't know what to label.
More long term, I think as a community, it would be useful to focus on getting more folks to be able to and comfortable to review code. Traditionally, I think we've encouraged new contributors to implement some small feature, and then have somebody experienced review their code. I wonder if this might work the other way around too, where a new contributor reviews a PR of an experienced contributor (perhaps in addition to another review).
Anyway, I hope this helps!
Cheers, Iavor
On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs <ghc-devs@haskell.org> wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy: 1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think > code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to: > if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
* Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. * Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) * Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that /involve /LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs <ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
> In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
> P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
> P2: Full responsibility
> You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
> P3: Strong preference for human authorship
> We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
> Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
> We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ 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 toghc-devs-leave@haskell.org
Andreas, Assuming we actually need to have an explicit LLM policy, because people ask for it: I think the LLM policy should be "see general contribution policy (e.g. the text from the last email); PS: We strongly encourage clear attribution of LLM usage where applicable; this helps everyone to know what to look out for." Aren't we all adults, can't we expect a basic level of common sense? Do we need to drown in legislation, policies, ...? PS: for the "were LLMs used during this creation?" I'd also suggest to have either a checkbox, or yes/no toggle on the MR creation page. Or maybe just in the MR creation template (so that it's not tied to some GitLab customization needs). Best, Moritz On Wed, 15 Jul 2026 at 18:57, Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote:
I think we could do with a much shorter policy, that doesn't even mention LLMs/AI
I agree that brevity and maybe simplicity could be improved.
But being explicit about LLMs/AI is not unnecessary. People have been asking, and will keep asking, what our policy in this respect is. Pointing them to a document that doesn't acknowledge the thing they are asking about in any way will not be as helpful.
What I'm trying to convey is that LLMs are not special in the ability to produce poor code.
The goal of attributing LLM involvement is not to mark a contribution as bad. If I thought such MRs are categorically worse I would argue for a blanket ban instead of being onboard with this policy.
I do agree with what you put into your condensed version. But personally I do want to see (mostly) LLM generated code to be marked as such. And the topic of LLMs to be explicitly addressed so we can point people at the policy instead of repeating the same discussion over and over again.
On 15/07/2026 12:01, Moritz Angermann via ghc-devs wrote:
Andreas,
I should probably not have dealt in extremes to try to make my point. What I'm trying to convey is that LLMs are not special in the ability to produce poor code. They _do_ lower the bar, but LLMs are fundamentally orthogonal to the problem we face with them. As such I mostly question the necessity for large parts of the policy. Especially as I question the enforceability of the policy, and what value does a policy without teeth have?
From the interactions you had with me, you might know that I deeply value simplicity over (unnecessary) complexity. And this policy as it grows to me becomes increasingly complex. I think we could do with a much shorter policy, that doesn't even mention LLMs/AI, ... and sets the general expectations that would cover much more than just the challenges with LLMs.
I've taken the part from the policy that I consider very valuable and modified it slightly below. I would like us to set a frame that transcends LLM and similar concerns, and focuses on the outcome we want, not on the particulars.
Best, Moritz
*Basic principles of GHC Development:*
-
We want to nurture the community of passionate volunteers who maintain and develop GHC, their motivation, their relationships, and their enjoyment. -
We want to build software that is the province of humans, where it is understood and developed by a community of people. -
We want to build a code base that we can be proud of: well structured, well documented, even beautiful.
*Collaboration*
-
Human conversation. In offering a contribution to GHC you are becoming a valued part of a community of living, breathing people. You are offering your work for free, and members of the community are likewise offering their work to you for free, to review and improve your MR, and to help you to learn your way around the code base.
They should treat you with respect, and you should treat them likewise. You are expected to enter a direct conversation with a human reviewer, and be able to fully motivate, explain and stand behind the contributions you offer. They want to talk to you.
-
Supporting contributors. We aspire to nurture a mutually-supportive community of human beings who contribute to GHC. GHC is a large code base, which can be intimidating. Many GHC experts hang out on ghc-devs mailing list, or the Matrix channel, and IRC, and are happy to help. Here's a list of channels <https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc>. -
*No Right to Reviews*. Your contribution to GHC may not be automatically reviewed. There is only a small pool of active reviewers, and it is often best to reach out to people through the mailing list, irc, matrix, ... and find reviewers this way. We very much look forward to having you as a reviewer as well. Contributions that fail to enlist a reviewer or sheperd may be closed as-is after a reasonable timeframe (e.g. 3mo). *Always be sure that your MRs meet your own expectations on MRs you'd like to review.* -
*Bad actors and poor quality contributions.* In the rare case where contributions to GHC are of sloppy, and poor quality, we reserve the right to ignore and eventually ban aspiring contributors.
On Wed, 15 Jul 2026 at 15:44, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Thanks for your feedback Iavor.
The only bit I have some reservations about is the bit that any LLM use
needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit.
I have clarified that section (P4). I never intended to cover "any LLM use", so I have made that more explicit. I intended NOT to require declaration of use of LLMs to help you find your way around the code base, draw diagrams etc. Just declare if the material you are asking others to review was LLM-generated, even if (P2) you take full responsibility for every line. Doing so is not a weakness; it just provides context.
I hope that may address your unease.
Simon
On Wed, 15 Jul 2026 at 09:26, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
Hello,
I like the document Simon has written because it established expectations and it does so with nuance. I also might be in the minority, but it doesn't seem overly long to me. I view such documents as guidelines, rather than law, and as such I am not worried about it being "weaponized": if we have disagreements we should still discuss them directly rather then appealing to the document, as an arbiter if truth.
Here are a few of my experiences with LLMs so far: * I find them very useful for refactoring code * For generating new code, I am still experimenting with the amount of guidance to give the LLM. My impression is that I tend to be a lot more controlling than other folks using them (I don't really try to "one shot" things). I do this because I find it a lot easier to review the code as it is being written, then doing it all at once after the fact. * For complex features, I find working on a plan with an LLM to be pretty handy: it's a bit like having a fancy rubber duck, to clarify my thinking and try to think of all possibilities * I've had some good luck with having the LLM find bugs in the code * I also find them a pretty handy tool for getting familiar with a new code base. I've used them to sketch architecture diagrams, pointing to important modules, and it is pretty convenient to be able to ask questions about where to look for things in the code
On the more negative side: * It is important to clearly scope your work, as LLMs make it easy to make giant PRs, even if you do it a little bit at a time. I just did this on a project (not on purpose!), and now we have a giant PR that I am the only person who understands. I was too focused on implementing the features, and not thinking of how it would be reviewed, which is a mistake (in retrospect an obvious one) * We've had issues with "drive by PRs" where a new contributor dumps a bunch of code. Some of my colleagues try to review those, but I am inclined to just delete them unless I can get some engagement from the contributor and get a sense that they know what they did (which hasn't happened yet)
I think that most of my experiences are aligned with the proposed GHC policy. The only bit I have some reservations about is the bit that any LLM use needs to be clearly indicated, as often the LLM use tends to be a bit "blurry", and I generally tend to think of the code as something I did, even if I happened to use an LLM for some bit. Not so much opposed to this I just wouldn't know what to label.
More long term, I think as a community, it would be useful to focus on getting more folks to be able to and comfortable to review code. Traditionally, I think we've encouraged new contributors to implement some small feature, and then have somebody experienced review their code. I wonder if this might work the other way around too, where a new contributor reviews a PR of an experienced contributor (perhaps in addition to another review).
Anyway, I hope this helps!
Cheers, Iavor
On Wed, Jul 15, 2026, 8:01 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
After having another lively debate with Julian about this topic, and getting a general notion I'm not being well understood, let me share the following: Julians argument is mostly that he doesn't want to spend his time reviewing LLM generated code. I don't even disagree with the fundamentals here, but I think this can be easily extended, in that we don't want to review poor, sloppy, or similar code however one arrives at that (I've tried to make this point by using various approaches so far, but I feel this is not being understood) and is completely orthogonal to LLM use. I've tried to outline what my expected outcome of a LLM ban or similar policy would be and why I am so vehemently against a policy that tries to classify LLMs as something special. Maybe it's worth sharing here as well:
LLM ban policy:
1. a person who reads the policy and adheres to the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free MR. 2. a person who reads the policy and would adhere to the policy, but isn't 100% sure he might not for a fraction of the MR end up using LLMs -> won't open a MR. 3. a person who doesn't read the policy -> Opens a MR -> no one other than him can truly tell if it's a LLM free or not MR. 4. a person who reads the policy, but still doesn't care and uses LLMs -> Opens a MR -> will lie about using LLMs. 5. person who reads the policy, but thinks they might get away with LLM use -> Opens a MR -> maybe mentioned they use LLMs when pressed. (1) is the MR you want. (2) is maybe the person you'd be ok to still review the MR, because they used an LLM to maybe help them translate some native language to english. (3) is the person you probably don't want, but can't tell from the outside. (4) is the person you probably don't want, but still can't tell from the outside. (5) is the person you probably don't want, and might find out later. Person (3), and (4) probably don't care in the slightest even if told they submitted LLM MRs. Person (5) will feel ashamed if called out. Reviewers still have to deal with (3), (4), (5). And there will be people in group (3), and (4), who consider this a challenge even. To use LLMs and see if they can fool the reviewers to not notice.
And I _really_ _really_ think we want people especially from group (1) and (2).
I honestly think
code may be reviewed if you find a reviewer
is enough to codify that it is on the submitter to find someone to review their code. I still don't know where this notion of every MR submitted must be reviewed comes from. And I think that's a self-sabotaging approach.
Even extending it to:
if you submit a LLM PR, you should find a potential reviewer before doing so
I find it questionable, because (as illustrated above) I feel it discourages contributions from the people we _do_ want contributions from, and encourages those whom we'd rather not have contributions for. It also starts segregating contributors into "pure" and "impure" people and creates a class system with an implied hierarchy.
I think we could probably also coupled this with a policy that MRs that haven't been reviewed, or found a shepherd > 3mo will be auto-closed. Or some other deadline. It is always on the submitter to engage with the community to find someone to review their contributions. This is part of partaking in the community and collaborating with others. Throwing code over the wall and not engaging with the project is the core issue we seem to address? Or are we trying to address a more ideological (LLMs are fundamentally bad for humanity) issue? If so, please let's be clear about this and call this out that GHC as a project sees LLMs as fundamentally detrimental to humanity and as such enacts a policy to ban LLM contributions in any form whatsoever.
Ultimately this is all about social credit. If someone asks me to review their code, I may do so if I know them personally, from IRC, maybe matrix, or discourse, reddit, or 𝕏, ... or I may not. Maybe someone whom I trust refers that MR to me for review. They are basically putting their own social credit with me on the line for someone else. If I end up feeling they made me review a sloppy, poorly written, and barely understood MR, I'll think twice the next time they ask me to review something. Similarly if I end up reviewing someone's MR and find it of exceptionally poor quality, I will likely hold it against them the next time I end up being asked to review their MR. The inverse of course works as well, if I review a MR of stellar quality, I'm more likely to be inclined to review another MR by the same person. This is the same concept as how we deal with this in other circles as well: academia, hiring, ...
But then again, maybe this all isn't about the technical questions and collaboration on a technical project, but trying to use technical arguments to achieve a socio-economic change; all I'm asking then is that we are going to be absolutely frank about it.
In the end I'll remain highly sceptical about any policy that states vague goals that can not be properly enforced (and proven), because at that point they become easily weaponized.
Best, Moritz
On Wed, 15 Jul 2026 at 06:08, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks for taking the time to write, Simon.
I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help.
I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours.
For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most.
Instead of trying to discourage contributions that involve LLMs, I
think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands.
thanks again
Simon
On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < ghc-devs@haskell.org> wrote:
Hi Simon,
here are my comments on the policy document:
> In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
> P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
> P2: Full responsibility
> You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
> P3: Strong preference for human authorship
> We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
> Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
> We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ 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
_______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
From what I understand you are worried that LLM users will be stigmatized for their LLM use, even if their use is entirely reasonable, adheres to the policy and the code is well understood, free of bugs and so on. If we treat LLM assisted contributions differently from non-LLM assisted contributions, then this is a somewhat implicit signal of distrust: you used an LLM, therefore we will penalize you with stricter reviews, require additional proof, etc. That may make contributors feel excluded or like second-class citizens, even if they did all the work necessary and used LLMs responsibly. How code was "conceived" is entirely private and is no ones business: I could have had a vision during my dream or found the code in a drift bottle, deciphered it and are now submitting it to you. All that matters is that I affirm: **I own the code, intellectually and legally... I can explain it and I can reproduce it manually if need be.** I think given infinite resources, this would be an ok position. We would process all MRs in the same fashion, mechanically and not assume anything. But the reality is that collaboration in large projects is very often trust based. Everyone knows that Simon likes to rewrite the simplifier and that he's intimately familiar with it and so people would adjust their reviews based on the context. If he would start delegating such rewrites to an LLM... the situation would be quite different now, wouldn't it? Now it's not about "does Simon know what he is doing?"... we know he knows the subsystem, but it's suddenly harder to tell how much *effort* went into a particular part of a patch! This is significant and we can't really ignore this. But I am sure Simon would write that down in his MR happily: "I had claude help me with this humongous task, can you people please look more carefully over this part of the patch?". What this policy is saying in spirit (I think) is exactly that: please help us understand which part of the patch needs more egregious review. Which part are you very familiar with and confident about? So we must rely on self-disclosure. We can't force this disclosure anyway, so we simply assume that patch authors are truthful. And yet, I still think that the wording of the policy is largely fine: - P1 mentions that effort matters and reviewers time needs to be respected - P2 says explicitly "We value the contribution itself, regardless of how it was produced" - P3 says we prefer human authorship, simply because we're more familiar with the dynamics and the process... I think this is totally fair - P4 asks for self-disclosure, but clearly says it's "an acknowledgement, not a weakness" Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it's a good deal for everyone.
Am Mi 15.07.2026 16:20 schrieb Julian Ospald:
Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it’s a good deal for everyone.
Given that I have way more strong opinions on this, I cannot get behind this policy. That said, if the goal is to somehow move forward with more or less everybody still on board, then we likely don’t have any considerably different option than using this policy that Simon proposes. Maybe it would be a good next step to just adopt it for now and check in a year how things have been going. All the best, Wolfgang
Thanks to everyone for their input. I have been editing the draft in direct response, as you'll have seen. Moritz would like to make it non-LLM-specific, and helpfully offered some concrete wording. But I think we really do need something that tackles LLMs head on. (I tried to say "we value the contribution, regardless of how it was produced", although I know that is not really satisfying to you.) Moritz thanks for the "no right to review" draft. I adapted it to give it a more positive spin -- see under "Human conversation". Some would like a briefer policy, and I see merit in brevity. But there is a lot of nuance here, as we can see in the debate, and my (fairly strong) preference is to value clarity, precision, and explicitness over length. I'm grateful that a few people with strong opinions have generously said (I am paraphrasing) "It's not what I really want, but it's a reasonable basis to move forward". That's what I meant about disagreeing agreeably. We all truly want to work together, even though our views differ. We may well want to iterate the draft in the light of experience. I think we may have reached the point of diminishing returns, where we can freeze the wording for now. Would you like to take a last look at the current state, and say if there are any drafting changes you'd like to make? Thanks! Simon On Wed, 15 Jul 2026 at 18:18, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Am Mi 15.07.2026 16:20 schrieb Julian Ospald:
Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it’s a good deal for everyone.
Given that I have way more strong opinions on this, I cannot get behind this policy. That said, if the goal is to somehow move forward with more or less everybody still on board, then we likely don’t have any considerably different option than using this policy that Simon proposes. Maybe it would be a good next step to just adopt it for now and check in a year how things have been going.
All the best, Wolfgang _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Thank you for your work on this, Simon. This draft to me looks like an agreeable compromise. However, I'll call out one bullet point which may require further discussion: under "P4: Declare use of LLMs," you ask that "if you used an LLM in a substantive way to generate your code or documentation, that should be acknowledged explicitly." Bullet point #2 says "How substantive is "substantive"? 90%? 50%? 10%? There is no hard and fast rule, but you will probably know." It's hard for me to imagine a scenario where a 90% or even 50% AI-generated contribution doesn't merit a declaration of AI usage. I'd suggest at _minimum_ dividing this number by 10, i.e.: "How substantive is "substantive"? 9%? 5%? 1%?," but really even 9% or 5% AI generation does not really qualify for the de minimis concerns of a person asking whether using Copilot to generate a for-loop counts as AI usage. Setting 10% as the lower bound for "substantial" is also certainly not what I'd want as a reviewer. My preference for these numbers would be more along the lines of "How substantive is "substantive"? 2%? 1%? 0.1%?" If I were a new contributor using LLMs and saw that a 90% contribution might be viewed as not worth acknowledging, I might be much less likely to add an acknowledgement on my own contributions, and it might seem unreasonable to me if a reviewer later takes issue with my not having acknowledged a large LLM contribution. Thanks, Tom
On 07/16/2026 12:53 AM CEST Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> wrote:
Thanks to everyone for their input. I have been editing the draft in direct response, as you'll have seen.
Moritz would like to make it non-LLM-specific, and helpfully offered some concrete wording. But I think we really do need something that tackles LLMs head on. (I tried to say "we value the contribution, regardless of how it was produced", although I know that is not really satisfying to you.)
Moritz thanks for the "no right to review" draft. I adapted it to give it a more positive spin -- see under "Human conversation".
Some would like a briefer policy, and I see merit in brevity. But there is a lot of nuance here, as we can see in the debate, and my (fairly strong) preference is to value clarity, precision, and explicitness over length.
I'm grateful that a few people with strong opinions have generously said (I am paraphrasing) "It's not what I really want, but it's a reasonable basis to move forward". That's what I meant about disagreeing agreeably. We all truly want to work together, even though our views differ.
We may well want to iterate the draft in the light of experience.
I think we may have reached the point of diminishing returns, where we can freeze the wording for now. Would you like to take a last look at the current state, and say if there are any drafting changes you'd like to make?
Thanks!
Simon
On Wed, 15 Jul 2026 at 18:18, Wolfgang Jeltsch via ghc-devs <ghc-devs@haskell.org> wrote:
Am Mi 15.07.2026 16:20 schrieb Julian Ospald:
Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it’s a good deal for everyone.
Given that I have way more strong opinions on this, I cannot get behind this policy. That said, if the goal is to somehow move forward with more or less everybody still on board, then we likely don’t have any considerably different option than using this policy that Simon proposes. Maybe it would be a good next step to just adopt it for now and check in a year how things have been going.
All the best, Wolfgang _______________________________________________ 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
Tom, I've been pondering that very same question. And--for myself--I'll just declare for every MR/Issue I'm going to open in the future that LLMs may have been used in the creation. This gives me the peace of mind that I'm not lying to anyone, while also allowing me to not have to spend excessive mental capacity and bookkeeping to ensure that I did not intentionally or unintentionally use any LLM (Copilot, ...) during the creation of any such contribution. I simply can not guarantee that over a span of a week or more, I didn't somehow end up using LLM tech these days. I accept that the net result will be that I'll be viewed as a second class contributor; however I will not compromise my integrity by accidentally lying about LLM usage. I do not want to open myself up to the debate of weather or not LLMs have been used during the creation. There is no way I could even exhaustively prove that I haven't and the policy gives human-written work a presumptive normative advantage. The policy in essence reads to me like this: 1. LLMs are ubiquitous. 2. LLM usage is part of life. 3. We prefer human written code over AI assisted code. 4. AI assistance must be declared. This leads (with the other notes from the document to the following understanding--AI was used to phrase this hopefully in a way that's easier to understand and get my argument across): P4 calls disclosure “merely an acknowledgement, not a weakness.” But
elsewhere the policy says that:
- human-written code and documentation are strongly preferred;
- reviewers may adjust their “feedback and discourse” after disclosure;
- AI-generated submissions are associated with inadequate understanding, reviewer burden, technical debt, de-skilling, and weakened human relationships.
Consequently, disclosure cannot realistically be completely neutral. It communicates membership in a category that the policy has already characterised as riskier and less desirable. A contributor who over-discloses borderline autocomplete use may therefore suffer a reputational or review disadvantage
The policy states "I'm guessing that this MR was authored at least partly by an LLM", which puts suspicion on the faithful declaration of AI use by the author. The policy does not say A contributor’s good-faith declaration concerning LLM use should be
accepted unless there is specific evidence that it is false. Stylistic impressions or unverified AI-detection results are not sufficient grounds for adverse treatment.
Consequently, because I can't prove to myself that I didn't use any LLM assistance, I will rather disclose that LLMs may have been used, to be on the safe side (“err on the side” of declaration). Subsequently I accept that I'll be viewed as a second class contributor. I guess that is why I find this policy (and discussion around) in part hostile to contributions. In an age of LLM proliferation, I think this will not attract fewer contributors. There is a book that has had a very lasting effect on me: https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think. Best, Moritz On Thu, 16 Jul 2026 at 06:34, amindfv--- via ghc-devs <ghc-devs@haskell.org> wrote:
Thank you for your work on this, Simon.
This draft to me looks like an agreeable compromise. However, I'll call out one bullet point which may require further discussion: under "P4: Declare use of LLMs," you ask that "if you used an LLM in a substantive way to generate your code or documentation, that should be acknowledged explicitly." Bullet point #2 says "How substantive is "substantive"? 90%? 50%? 10%? There is no hard and fast rule, but you will probably know."
It's hard for me to imagine a scenario where a 90% or even 50% AI-generated contribution doesn't merit a declaration of AI usage. I'd suggest at _minimum_ dividing this number by 10, i.e.: "How substantive is "substantive"? 9%? 5%? 1%?," but really even 9% or 5% AI generation does not really qualify for the de minimis concerns of a person asking whether using Copilot to generate a for-loop counts as AI usage.
Setting 10% as the lower bound for "substantial" is also certainly not what I'd want as a reviewer. My preference for these numbers would be more along the lines of "How substantive is "substantive"? 2%? 1%? 0.1%?"
If I were a new contributor using LLMs and saw that a 90% contribution might be viewed as not worth acknowledging, I might be much less likely to add an acknowledgement on my own contributions, and it might seem unreasonable to me if a reviewer later takes issue with my not having acknowledged a large LLM contribution.
Thanks, Tom
On 07/16/2026 12:53 AM CEST Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks to everyone for their input. I have been editing the draft in direct response, as you'll have seen.
Moritz would like to make it non-LLM-specific, and helpfully offered some concrete wording. But I think we really do need something that tackles LLMs head on. (I tried to say "we value the contribution, regardless of how it was produced", although I know that is not really satisfying to you.)
Moritz thanks for the "no right to review" draft. I adapted it to give it a more positive spin -- see under "Human conversation".
Some would like a briefer policy, and I see merit in brevity. But there is a lot of nuance here, as we can see in the debate, and my (fairly strong) preference is to value clarity, precision, and explicitness over length.
I'm grateful that a few people with strong opinions have generously said (I am paraphrasing) "It's not what I really want, but it's a reasonable basis to move forward". That's what I meant about disagreeing agreeably. We all truly want to work together, even though our views differ.
We may well want to iterate the draft in the light of experience.
I think we may have reached the point of diminishing returns, where we can freeze the wording for now. Would you like to take a last look at the current state, and say if there are any drafting changes you'd like to make?
Thanks!
Simon
On Wed, 15 Jul 2026 at 18:18, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Am Mi 15.07.2026 16:20 schrieb Julian Ospald:
Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it’s a good deal for everyone.
Given that I have way more strong opinions on this, I cannot get behind this policy. That said, if the goal is to somehow move forward with more or less everybody still on board, then we likely don’t have any considerably different option than using this policy that Simon proposes. Maybe it would be a good next step to just adopt it for now and check in a year how things have been going.
All the best, Wolfgang _______________________________________________ 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
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On 07/15/2026 6:20 PM CEST Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote: [...] All that matters is that I affirm: **I own the code, intellectually and legally. [...]
As a side note, has the legal portion of this been thought through? At least here in the US, it appears to be far from settled case law that you won't, for example, be infringing copyright if an LLM generates code very similar to existing code that's under a different license, even if the person using the LLM has no knowledge of the similarity. It also appears to be the case (at least in the US) that an author can't say "I own the code, intellectually and legally" if they've generated code with an LLM and left it unmodified: Thaler v. Perlmutter (a lower-court case) held that all copyrightable works must "be authored by a human being." So, bits of GHC may now be public domain rather than under GHC's licence. Tom
On copyright/licensing: I don't think parts of GHC potentially becoming public domain would be an issue for the project itself. As for copyright, what feels like a long time ago I listed it as one of the reasons for declaring AI tooling use. Even if in practice I don't see a realistic process to check if some AI generated part violates copyright. But our contribution guidelines already state:
*Licensing*: make sure you are familiar with GHC's Licensing. Unless you say otherwise, we will assume that if you submit a contribution to GHC, then you intend to supply it to us under the same license as the existing code. However, we do not ask for copyright attribution; you retain copyright on any contributions you make, so feel free to add your copyright to the top of any file in which you make non-trivial changes.
See also: https://gitlab.haskell.org/ghc/ghc/-/wikis/licensing This definitely doesn't protect the individual contributor, but it's their choice to use such tools. It's impossible to answer if this is enough to avoid maintainers being held responsible for copyright violations others contributed to GHC, but I would hope it would help. From a maintainer perspective I think it's more likely that someone carelessly commits license violation by copying code from another project rather than through LLM generation. So while worth thinking about, I think from a maintainer perspective we don't need special treatment on this in the AI policy. But given it's current length, perhaps adding one line that contributors are responsible for generated code being compatible with GHCs license would be sensible. Andreas On 16/07/2026 00:31, amindfv--- via ghc-devs wrote:
On 07/15/2026 6:20 PM CEST Julian Ospald via ghc-devs<ghc-devs@haskell.org> wrote: [...] All that matters is that I affirm: **I own the code, intellectually and legally. [...] As a side note, has the legal portion of this been thought through? At least here in the US, it appears to be far from settled case law that you won't, for example, be infringing copyright if an LLM generates code very similar to existing code that's under a different license, even if the person using the LLM has no knowledge of the similarity.
It also appears to be the case (at least in the US) that an author can't say "I own the code, intellectually and legally" if they've generated code with an LLM and left it unmodified: Thaler v. Perlmutter (a lower-court case) held that all copyrightable works must "be authored by a human being." So, bits of GHC may now be public domain rather than under GHC's licence.
Tom _______________________________________________ ghc-devs mailing list --ghc-devs@haskell.org To unsubscribe send an email toghc-devs-leave@haskell.org
Julian,
If we treat LLM assisted contributions differently from non-LLM assisted contributions, then this is a somewhat implicit signal of distrust: you used an LLM, therefore we will penalize you with stricter reviews, require additional proof, etc. [...] collaboration in large projects is very often trust based [...] We can't force this disclosure anyway, so we simply assume that patch authors are truthful.
You see the discrepancy in this? This leads to the following bizarre situation (Conduct => Review): Truthfully discloses LLM generation => Additional scrutiny or stricter review, because we distrust you Does not disclose it => Receives ordinary review unless discovered Did not use an LLM => Receives ordinary review, may still be accused of LLM use. This creates an incentive structure in which honest contributors that comply with the honor system are automatically placed in the less-trusted category. You also hold the following four views concurrently: 1. Responsible LLM users should not be stigmatized. 2. How the code was produced is private and should not matter. 3. LLM generation should be disclosed because it justifies stricter review. 4. Such disclosure is not a weakness and does not make contributors second-class. However two conflicts with three, and three makes four difficult to sustain. And while the first is aspirational, the proposed review practices is the mechanism by which the stigma would arise. This is then justified by operational constraints (I think given infinite resources, this would be an ok position). Best, Moritz On Wed, 15 Jul 2026 at 23:20, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
From what I understand you are worried that LLM users will be stigmatized for their LLM use, even if their use is entirely reasonable, adheres to the policy and the code is well understood, free of bugs and so on.
If we treat LLM assisted contributions differently from non-LLM assisted contributions, then this is a somewhat implicit signal of distrust: you used an LLM, therefore we will penalize you with stricter reviews, require additional proof, etc. That may make contributors feel excluded or like second-class citizens, even if they did all the work necessary and used LLMs responsibly.
How code was "conceived" is entirely private and is no ones business: I could have had a vision during my dream or found the code in a drift bottle, deciphered it and are now submitting it to you. All that matters is that I affirm: **I own the code, intellectually and legally... I can explain it and I can reproduce it manually if need be.**
I think given infinite resources, this would be an ok position. We would process all MRs in the same fashion, mechanically and not assume anything. But the reality is that collaboration in large projects is very often trust based. Everyone knows that Simon likes to rewrite the simplifier and that he's intimately familiar with it and so people would adjust their reviews based on the context. If he would start delegating such rewrites to an LLM... the situation would be quite different now, wouldn't it? Now it's not about "does Simon know what he is doing?"... we know he knows the subsystem, but it's suddenly harder to tell how much *effort* went into a particular part of a patch! This is significant and we can't really ignore this.
But I am sure Simon would write that down in his MR happily: "I had claude help me with this humongous task, can you people please look more carefully over this part of the patch?".
What this policy is saying in spirit (I think) is exactly that: please help us understand which part of the patch needs more egregious review. Which part are you very familiar with and confident about? So we must rely on self-disclosure. We can't force this disclosure anyway, so we simply assume that patch authors are truthful.
And yet, I still think that the wording of the policy is largely fine:
- P1 mentions that effort matters and reviewers time needs to be respected - P2 says explicitly "We value the contribution itself, regardless of how it was produced" - P3 says we prefer human authorship, simply because we're more familiar with the dynamics and the process... I think this is totally fair - P4 asks for self-disclosure, but clearly says it's "an acknowledgement, not a weakness"
Given that I have way more strong opinions on this and can still get behind this policy, I would suggest that it's a good deal for everyone. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Truthfully discloses LLM generation => Additional scrutiny or stricter review, because we distrust you
This is not what the policy says. Even pre-LLM it was common sense and common courtesy to disclose when you copy-pasted code from other sources, be it stackoverflow or some other project. I do that and it's also a legal requirement for a fair number of open source licenses and it doesn't matter whether you reviewed all of that... it doesn't absolve you from declaring it. It also helps the reviewer get more context: where do the ideas originate from, how much effort was potentially involved in certain parts of the patches... those are all fuzzy intuitions... not final judgements. Whether LLM generated (or copy-pasted) code needs more scrutiny or not depends on a lot of factors. It may very well require more scrutiny, it depends on the scope, the workflow, the patch owner, etc. Withholding that information is simply poor collaboration. You're interacting with another human and their time and energy. Your reviewer may not care or they may. We won't be able to impose opinions on anyone, but this disclosure is essential for other people to get the context they need to conduct a review. It doesn't say whether the reviewer will be negatively biased against AI or not. This discussion won't change those positions. But it will set boundaries as to how they can treat you: they won't be able to reject your patch just because it's AI generated. So in a way, this policy is trying to protect both sides.
Julian, I've quoted your email on purpose. You clearly state that LLM usage for you is a signal of distrust. The policy itself has a strong bias towards human written code. It does not protect people who use LLMs in any form; it tolerates LLM usage, and it classifies LLM users. It protects, and codifies a bias, while not outright banning LLMs. I have no issue with attribution, you'll find plenty of comments/notes with attributions from me. Again, my point is that it sets incentives that I believe are not aligned with your preferred outcome. Best, Moritz On Thu, 16 Jul 2026 at 11:34, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Truthfully discloses LLM generation => Additional scrutiny or stricter review, because we distrust you
This is not what the policy says.
Even pre-LLM it was common sense and common courtesy to disclose when you copy-pasted code from other sources, be it stackoverflow or some other project. I do that and it's also a legal requirement for a fair number of open source licenses and it doesn't matter whether you reviewed all of that... it doesn't absolve you from declaring it. It also helps the reviewer get more context: where do the ideas originate from, how much effort was potentially involved in certain parts of the patches... those are all fuzzy intuitions... not final judgements.
Whether LLM generated (or copy-pasted) code needs more scrutiny or not depends on a lot of factors. It may very well require more scrutiny, it depends on the scope, the workflow, the patch owner, etc. Withholding that information is simply poor collaboration. You're interacting with another human and their time and energy. Your reviewer may not care or they may. We won't be able to impose opinions on anyone, but this disclosure is essential for other people to get the context they need to conduct a review. It doesn't say whether the reviewer will be negatively biased against AI or not. This discussion won't change those positions. But it will set boundaries as to how they can treat you: they won't be able to reject your patch just because it's AI generated.
So in a way, this policy is trying to protect both sides. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
You clearly state that LLM usage for you is a signal of distrust.
Yes, I personally distrust patches with heavy LLM assistance and I do not believe people who say "but I know what I am doing". This also means that I don't want to spend my free time interacting with such works. So who is protecting me? The disclosure does that: it allows me to just walk away and have someone else look at the patch. And it definitely does protect you, because my negative bias won't be able to drive decisions (unlike in my own projects, where I outright reject such patches). I'm confused why you don't see that this is literally the only compromise that is possible. I won't be contributing to projects, where people do not want to disclose their LLM use, even if it's "well, I use it all the time". That helps me set the expectations.
Julian, What I've been trying to illustrate multiple times now is that the incentives you are creating through this policy are not protecting you, but to the contrary make people think twice if they want to be honest with you and declare LLM use (however tiny that might have been, or not). You are even opening a game of "lets. see if I can use LLMs, not declare them, and have Julian review them without noticing." What kind of incentive is this? If all you want to be protected is a labeling, the policy should simply read: *We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.* If you really wanted to you could even add a fairly neutral: It helps reviewers set expectations. This above wouldn't be enough for me though, as it does not say that we discourage drive-by-llm-contributions, and expect people to fully own their contributions. That however is completely irrelevant to you, as you don't want to interact with any of those, and as such will disregard them as soon as they are LLM-assisted labeled. And there is zero need for any form of judgement in either direction. You can at your discretion just not review PRs that have the LLM assisted label. If someone explicitly asks you to review a patch that has LLM-assisted, you can let them know that you'd prefer them to find another reviewer. Again, what I said before, there is *no right to review*. If you goal is to make sure people disclose their LLM use honestly, let's not have a policy that is outright stigmatizing people who use LLMs (because they did not share the "we strongly prefer hand crafted bytes" sentiment). If on the other hand you want GHC to be a project that actively pushes away (or makes people question if their contribution is welcome if they use LLMs -- even a hint of doubt is enough to discourage people, It's the UD part of FUD) a certain class of contributors with integrity, honesty but also occasional LLM use, write a policy that not only states LLM labeling, but also comes with a judgement call. Hence, and why I keep coming back to this, I don't see this as a compromise, even though I can understand why you see it as such. I see this as a judgement (and classification) of people, which is what I reject. What is most perplexing to me is, that you multiple times say you want more collaboration, but the incentives you seem to lay out, seem to contradict this. The incentives seem to push people away, make them question whether or not they are truly welcome or just tolerated. Maybe I'm fundamentally misunderstanding what you consider collaboration. To me this is fundamentally building trust between people. Throwing code over the wall, however conceived, is not that. Entering into a discussion, while providing contributions is closer to that. However putting up incentives to make contributors start out in the defensive is not that, insinuating distrust is not that, it all just leads to a corrupted interaction, not collaboration. If one party always has to assume they could at any point be accused of something, that they simply can not prove to be incorrect, we create a hostile environment. There is a reason why we generally follow in dubio pro reo and assume good-faith. This policy moves us from good-faith not outright to bad-faith, but into that direction; I object to _that_. Best, Moritz On Thu, 16 Jul 2026 at 12:00, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
You clearly state that LLM usage for you is a signal of distrust.
Yes, I personally distrust patches with heavy LLM assistance and I do not believe people who say "but I know what I am doing".
This also means that I don't want to spend my free time interacting with such works. So who is protecting me?
The disclosure does that: it allows me to just walk away and have someone else look at the patch. And it definitely does protect you, because my negative bias won't be able to drive decisions (unlike in my own projects, where I outright reject such patches).
I'm confused why you don't see that this is literally the only compromise that is possible. I won't be contributing to projects, where people do not want to disclose their LLM use, even if it's "well, I use it all the time". That helps me set the expectations. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Julian is not making this policy. He is saying how it applies *to him*. On Thu, Jul 16, 2026 at 1:49 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Julian,
What I've been trying to illustrate multiple times now is that the incentives you are creating through this policy are not protecting you, but to the contrary make people think twice if they want to be honest with you and declare LLM use (however tiny that might have been, or not). You are even opening a game of "lets. see if I can use LLMs, not declare them, and have Julian review them without noticing." What kind of incentive is this?
If all you want to be protected is a labeling, the policy should simply read:
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
If you really wanted to you could even add a fairly neutral: It helps reviewers set expectations.
This above wouldn't be enough for me though, as it does not say that we discourage drive-by-llm-contributions, and expect people to fully own their contributions. That however is completely irrelevant to you, as you don't want to interact with any of those, and as such will disregard them as soon as they are LLM-assisted labeled.
And there is zero need for any form of judgement in either direction. You can at your discretion just not review PRs that have the LLM assisted label. If someone explicitly asks you to review a patch that has LLM-assisted, you can let them know that you'd prefer them to find another reviewer. Again, what I said before, there is *no right to review*.
If you goal is to make sure people disclose their LLM use honestly, let's not have a policy that is outright stigmatizing people who use LLMs (because they did not share the "we strongly prefer hand crafted bytes" sentiment). If on the other hand you want GHC to be a project that actively pushes away (or makes people question if their contribution is welcome if they use LLMs -- even a hint of doubt is enough to discourage people, It's the UD part of FUD) a certain class of contributors with integrity, honesty but also occasional LLM use, write a policy that not only states LLM labeling, but also comes with a judgement call.
Hence, and why I keep coming back to this, I don't see this as a compromise, even though I can understand why you see it as such. I see this as a judgement (and classification) of people, which is what I reject.
What is most perplexing to me is, that you multiple times say you want more collaboration, but the incentives you seem to lay out, seem to contradict this. The incentives seem to push people away, make them question whether or not they are truly welcome or just tolerated. Maybe I'm fundamentally misunderstanding what you consider collaboration. To me this is fundamentally building trust between people. Throwing code over the wall, however conceived, is not that. Entering into a discussion, while providing contributions is closer to that. However putting up incentives to make contributors start out in the defensive is not that, insinuating distrust is not that, it all just leads to a corrupted interaction, not collaboration. If one party always has to assume they could at any point be accused of something, that they simply can not prove to be incorrect, we create a hostile environment. There is a reason why we generally follow in dubio pro reo and assume good-faith. This policy moves us from good-faith not outright to bad-faith, but into that direction; I object to _that_.
Best, Moritz
On Thu, 16 Jul 2026 at 12:00, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
You clearly state that LLM usage for you is a signal of distrust.
Yes, I personally distrust patches with heavy LLM assistance and I do not believe people who say "but I know what I am doing".
This also means that I don't want to spend my free time interacting with such works. So who is protecting me?
The disclosure does that: it allows me to just walk away and have someone else look at the patch. And it definitely does protect you, because my negative bias won't be able to drive decisions (unlike in my own projects, where I outright reject such patches).
I'm confused why you don't see that this is literally the only compromise that is possible. I won't be contributing to projects, where people do not want to disclose their LLM use, even if it's "well, I use it all the time". That helps me set the expectations. _______________________________________________ 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
-- brandon s allbery kf8nh allbery.b@gmail.com
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
I'm also starting to think this discussion has run its course. Are we now arguing about whether to say "prefer" or "must" and that difference is going to make the world whether people will still be contributing to GHC? We can't force people to disclose anything. As you've explained in your earlier emails, we have to assume good faith. And now you're turning around and say "oh, but we can't assume good faith, so it's not enforcable anyway". You gotta pick one. I think we should: - require LLM contributions to be labeled as such: this is important for context and is part of respectful collaboration - assume good faith: if people (actively) mislabel their contributions, we will notice and ask them to correct that I think a project is well within its right to make this demand and I do absolutely disagree with you that this labelling act in its own is hostile towards contributors.
Brandon, By extension, yes Julian _is_ the one driving this policy: https://gitlab.haskell.org/ghc/ghc/-/issues/27433. Julian, You seem to want to misunderstand me. I have said nowhere that the following labeling is on its own hostile towards contributors. Whether or not it is
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.* or *We require contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
is pretty much irrelevant to me. I've defaulted to prefer, simply because the ask is non-enforceable, and again, I feel very uncomfortable explicitly dictating to others what to do. The implicit judgement from the policy is not. You are fine with the policy because it reinforces your fundamental belief (I assume) that LLMs are bad, horrible, corrupting, and society damaging tech-bro inventions. I am not, because it tells people that they are less welcome if they use LLMs in any form ("we strongly prefer"), I object especially to *P3*'s wording in the document. You do not seem to (want to?) understand that this can be understood as hostile language. The policy ends up prescribing a process of how people should act, instead of describing what we want. The policy exaggerated states: we want you to write code by hand without the use of assistive technology, and if you end up writing code with assistive technology, we think less of you. Now this (I assume) very much aligns with your worldview. But I fundamentally disagree with that. It's not inclusive. Just FTR so you can refer back to this: (1) Easy to review, high quality MRs. 🤝 (2) Full responsibility. 🤝 (3) Declaration/Labeling 🤝 -- although, again I don't think LLMs are special here, it's a class of assistive technologies. (4) Segregating contributors/judging them based on their preferences ❌ Best, Moritz On Thu, 16 Jul 2026 at 13:13, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
I'm also starting to think this discussion has run its course. Are we now arguing about whether to say "prefer" or "must" and that difference is going to make the world whether people will still be contributing to GHC?
We can't force people to disclose anything. As you've explained in your earlier emails, we have to assume good faith. And now you're turning around and say "oh, but we can't assume good faith, so it's not enforcable anyway". You gotta pick one.
I think we should:
- require LLM contributions to be labeled as such: this is important for context and is part of respectful collaboration - assume good faith: if people (actively) mislabel their contributions, we will notice and ask them to correct that
I think a project is well within its right to make this demand and I do absolutely disagree with you that this labelling act in its own is hostile towards contributors. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
But you did assert
I accept that the net result will be that I'll be viewed as a second class contributor
(in Message-ID: < CAKfdd-y7VeCLMqRv3p0p1F8vqR+dJOAav1CGrzDAG27P-u1kUg@mail.gmail.com>) with the implication from context that declaring LLM use (the specific topic you were responding to) does that. On Thu, Jul 16, 2026 at 3:41 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Brandon,
By extension, yes Julian _is_ the one driving this policy: https://gitlab.haskell.org/ghc/ghc/-/issues/27433.
Julian,
You seem to want to misunderstand me. I have said nowhere that the following labeling is on its own hostile towards contributors. Whether or not it is
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.* or *We require contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
is pretty much irrelevant to me. I've defaulted to prefer, simply because the ask is non-enforceable, and again, I feel very uncomfortable explicitly dictating to others what to do. The implicit judgement from the policy is not. You are fine with the policy because it reinforces your fundamental belief (I assume) that LLMs are bad, horrible, corrupting, and society damaging tech-bro inventions. I am not, because it tells people that they are less welcome if they use LLMs in any form ("we strongly prefer"), I object especially to *P3*'s wording in the document. You do not seem to (want to?) understand that this can be understood as hostile language. The policy ends up prescribing a process of how people should act, instead of describing what we want.
The policy exaggerated states: we want you to write code by hand without the use of assistive technology, and if you end up writing code with assistive technology, we think less of you.
Now this (I assume) very much aligns with your worldview. But I fundamentally disagree with that. It's not inclusive.
Just FTR so you can refer back to this: (1) Easy to review, high quality MRs. 🤝 (2) Full responsibility. 🤝 (3) Declaration/Labeling 🤝 -- although, again I don't think LLMs are special here, it's a class of assistive technologies. (4) Segregating contributors/judging them based on their preferences ❌
Best, Moritz
On Thu, 16 Jul 2026 at 13:13, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
I'm also starting to think this discussion has run its course. Are we now arguing about whether to say "prefer" or "must" and that difference is going to make the world whether people will still be contributing to GHC?
We can't force people to disclose anything. As you've explained in your earlier emails, we have to assume good faith. And now you're turning around and say "oh, but we can't assume good faith, so it's not enforcable anyway". You gotta pick one.
I think we should:
- require LLM contributions to be labeled as such: this is important for context and is part of respectful collaboration - assume good faith: if people (actively) mislabel their contributions, we will notice and ask them to correct that
I think a project is well within its right to make this demand and I do absolutely disagree with you that this labelling act in its own is hostile towards contributors. _______________________________________________ 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
-- brandon s allbery kf8nh allbery.b@gmail.com
Brandon, yes, but only because two things from the policy play together: P3, and P4. An insinuation that human-written code[1] is somehow superior to LLM-assisted code, and the requirement to declare such assisted code. That makes it not a neutral declaration. That makes it a judgmental declaration. The policy again states: we value hand written code higher than LLM written/assisted/... code *and* we require you to declare the use of LLMs. That is a materially different statement to: we require you to declare the use of LLMs. I hope this clarifies the confusion. Best, Moritz -- [1]: Sidenote: P3 states human authored, and then uses human-written. From context the assumption has to be that human-written is supposedly the opposite of LLM-written. Hence no-llm assisted code. On Thu, 16 Jul 2026 at 14:52, Brandon Allbery <allbery.b@gmail.com> wrote:
But you did assert
I accept that the net result will be that I'll be viewed as a second class contributor
(in Message-ID: < CAKfdd-y7VeCLMqRv3p0p1F8vqR+dJOAav1CGrzDAG27P-u1kUg@mail.gmail.com>) with the implication from context that declaring LLM use (the specific topic you were responding to) does that.
On Thu, Jul 16, 2026 at 3:41 AM Moritz Angermann via ghc-devs < ghc-devs@haskell.org> wrote:
Brandon,
By extension, yes Julian _is_ the one driving this policy: https://gitlab.haskell.org/ghc/ghc/-/issues/27433.
Julian,
You seem to want to misunderstand me. I have said nowhere that the following labeling is on its own hostile towards contributors. Whether or not it is
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.* or *We require contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
is pretty much irrelevant to me. I've defaulted to prefer, simply because the ask is non-enforceable, and again, I feel very uncomfortable explicitly dictating to others what to do. The implicit judgement from the policy is not. You are fine with the policy because it reinforces your fundamental belief (I assume) that LLMs are bad, horrible, corrupting, and society damaging tech-bro inventions. I am not, because it tells people that they are less welcome if they use LLMs in any form ("we strongly prefer"), I object especially to *P3*'s wording in the document. You do not seem to (want to?) understand that this can be understood as hostile language. The policy ends up prescribing a process of how people should act, instead of describing what we want.
The policy exaggerated states: we want you to write code by hand without the use of assistive technology, and if you end up writing code with assistive technology, we think less of you.
Now this (I assume) very much aligns with your worldview. But I fundamentally disagree with that. It's not inclusive.
Just FTR so you can refer back to this: (1) Easy to review, high quality MRs. 🤝 (2) Full responsibility. 🤝 (3) Declaration/Labeling 🤝 -- although, again I don't think LLMs are special here, it's a class of assistive technologies. (4) Segregating contributors/judging them based on their preferences ❌
Best, Moritz
On Thu, 16 Jul 2026 at 13:13, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
*We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.*
I'm also starting to think this discussion has run its course. Are we now arguing about whether to say "prefer" or "must" and that difference is going to make the world whether people will still be contributing to GHC?
We can't force people to disclose anything. As you've explained in your earlier emails, we have to assume good faith. And now you're turning around and say "oh, but we can't assume good faith, so it's not enforcable anyway". You gotta pick one.
I think we should:
- require LLM contributions to be labeled as such: this is important for context and is part of respectful collaboration - assume good faith: if people (actively) mislabel their contributions, we will notice and ask them to correct that
I think a project is well within its right to make this demand and I do absolutely disagree with you that this labelling act in its own is hostile towards contributors. _______________________________________________ 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
-- brandon s allbery kf8nh allbery.b@gmail.com
You are fine with the policy because it reinforces your fundamental belief (I assume) that LLMs are bad, horrible, corrupting, and society damaging tech-bro inventions.
No, my beliefs are more nuanced than that. And the policy does not reinforce my beliefs. It is mostly void of all my concerns I have about LLMs, like the erosion of taste, values and motivation.
I am not, because it tells people that they are less welcome if they use LLMs in any form ("we strongly prefer"), I object especially to *P3*'s wording in the document.
Yes, I absolutely think we should prefer human written code. Otherwise I do not see how we would be able to protect people who: - cannot use LLMs due to their political beliefs (e.g. the negative effects on the environment) - cannot use LLMs due to their economic situation (frontier models are not free) - cannot use LLMs effectively due to their personal characteristics (although I believe LLMs have devastating effects on most people there's certainly groups that are more vulnerable and have to naturally avoid them or who simply do not derive joy from using them) All these people now need to worry they will be left behind by the community, because they can't keep up with those "10x" engineers who are burning tokens. A "neutral" stance would in fact not be neutral... and it would cement that the primary thing we care about is patches and productivity (just as Linus declared on the linux ML). If that is the view of the project, then it leaves a bitter taste in my mouth that I probably won't be able to get rid of.
Julian, Well, if you want GHC to become a political vehicle for an ideology, we should spell *that* out instead of trying to do so by proxy via some "LLM Policy", which is mostly void of your concerns anyway. And this policy is now, not anymore about LLM declaration, high quality contribution, ownership, respectful collaboration, but about protection of marginalized people due to economic situation, and political beliefs? You also fear that contributors are outrun by other contributors? Best, Moritz On Thu, 16 Jul 2026 at 15:24, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
You are fine with the policy because it reinforces your fundamental belief (I assume) that LLMs are bad, horrible, corrupting, and society damaging tech-bro inventions.
No, my beliefs are more nuanced than that. And the policy does not reinforce my beliefs. It is mostly void of all my concerns I have about LLMs, like the erosion of taste, values and motivation.
I am not, because it tells people that they are less welcome if they use LLMs in any form ("we strongly prefer"), I object especially to *P3*'s wording in the document.
Yes, I absolutely think we should prefer human written code. Otherwise I do not see how we would be able to protect people who:
- cannot use LLMs due to their political beliefs (e.g. the negative effects on the environment) - cannot use LLMs due to their economic situation (frontier models are not free) - cannot use LLMs effectively due to their personal characteristics (although I believe LLMs have devastating effects on most people there's certainly groups that are more vulnerable and have to naturally avoid them or who simply do not derive joy from using them)
All these people now need to worry they will be left behind by the community, because they can't keep up with those "10x" engineers who are burning tokens.
A "neutral" stance would in fact not be neutral... and it would cement that the primary thing we care about is patches and productivity (just as Linus declared on the linux ML). If that is the view of the project, then it leaves a bitter taste in my mouth that I probably won't be able to get rid of. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that: - you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not. If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
Julian, I'm not sure how many more times I need to write this: It is fundamentally against my nature to tell anyone what to do, that includes telling people to use LLMs. It is probably from the same foundational values, that I am against telling people what NOT to do. You of all people probably know this even the best. You explicitly want a policy that puts judgement on people who use LLMs, and segregates the pure (hand written) from the impure (assisted) people, yet you claim you want to keep _all_ of them? You must see how qualified segregation tells one group that they are NOT welcome?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
This is NOT my opinion, and I also do NOT think this logical conclusion follows. Best, Moritz On Thu, 16 Jul 2026 at 15:44, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that:
- you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Alright, it seems we're largely talking past each other, so I'll stop here. But for the record: if P3 and the preference for human authorship is removed, then I withdraw my support for the proposed policy.
I find the framing that this policy is used to "segregate" (given what the term usually refers to) developers to again be crossing a line. Nobody is threatening anyone's existence or dehumanizing them by asking them to disclose if they used an LLM to write their code. Since this is the second time this happened during this discussion, I would really hope we could be a bit less careless with our words. Best Magnus On 7/16/26 10:51, Moritz Angermann via ghc-devs wrote:
Julian,
I'm not sure how many more times I need to write this: It is fundamentally against my nature to tell anyone what to do, that includes telling people to use LLMs. It is probably from the same foundational values, that I am against telling people what NOT to do. You of all people probably know this even the best.
You explicitly want a policy that puts judgement on people who use LLMs, and segregates the pure (hand written) from the impure (assisted) people, yet you claim you want to keep _all_ of them? You must see how qualified segregation tells one group that they are NOT welcome?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
This is NOT my opinion, and I also do NOT think this logical conclusion follows.
Best, Moritz
On Thu, 16 Jul 2026 at 15:44, Julian Ospald via ghc-devs <ghc-devs@haskell.org> wrote:
> Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that:
- you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine. _______________________________________________ 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 toghc-devs-leave@haskell.org
Magnus, I see you did not read my email, but got hung up on the word[1] I chose. It is not about the mere disclosure. It is about the classification of contributors into two categories, those that write code by hand (who are strongly preferred) over those that use assistive technologies to write code. Now, please explain to me how I am supposed to feel about this, as someone who considers themselves in the second category? And what word choice you would prefer me using? Best, Moritz — [1]: https://www.merriam-webster.com/dictionary/segregate On Thu, Jul 16, 2026 at 4:02 PM Magnus Viernickel via ghc-devs < ghc-devs@haskell.org> wrote:
I find the framing that this policy is used to "segregate" (given what the term usually refers to) developers to again be crossing a line. Nobody is threatening anyone's existence or dehumanizing them by asking them to disclose if they used an LLM to write their code. Since this is the second time this happened during this discussion, I would really hope we could be a bit less careless with our words.
Best
Magnus On 7/16/26 10:51, Moritz Angermann via ghc-devs wrote:
Julian,
I'm not sure how many more times I need to write this: It is fundamentally against my nature to tell anyone what to do, that includes telling people to use LLMs. It is probably from the same foundational values, that I am against telling people what NOT to do. You of all people probably know this even the best.
You explicitly want a policy that puts judgement on people who use LLMs, and segregates the pure (hand written) from the impure (assisted) people, yet you claim you want to keep _all_ of them? You must see how qualified segregation tells one group that they are NOT welcome?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
This is NOT my opinion, and I also do NOT think this logical conclusion follows.
Best, Moritz
On Thu, 16 Jul 2026 at 15:44, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that:
- you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine. _______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC.
Although I have contributed to GHC in the past, the above applies to me as well (pending an "again"). Contributing to GHC does not feel like an efficient use of my free time unless I instruct an LLM to carry out the designs I have in mind. The problem is the design that you put the LLM on; it is not the output it produces that needs continuous iteration by the (human) author. Similarly for MR descriptions: If you just take the output of the LLM unmodified you end up with a huge blob of prose that nobody wants to read. It is the same for an MR description produced by a human that has no clue about what they are talking. My eyes tend to glaze over. Same for an overlong mail thread. The problem is the output, not who produced it. Cheers, Sebastian Am Do., 16. Juli 2026 um 11:29 Uhr schrieb Moritz Angermann via ghc-devs < ghc-devs@haskell.org>:
Magnus,
I see you did not read my email, but got hung up on the word[1] I chose. It is not about the mere disclosure. It is about the classification of contributors into two categories, those that write code by hand (who are strongly preferred) over those that use assistive technologies to write code.
Now, please explain to me how I am supposed to feel about this, as someone who considers themselves in the second category? And what word choice you would prefer me using?
Best, Moritz
— [1]: https://www.merriam-webster.com/dictionary/segregate
On Thu, Jul 16, 2026 at 4:02 PM Magnus Viernickel via ghc-devs < ghc-devs@haskell.org> wrote:
I find the framing that this policy is used to "segregate" (given what the term usually refers to) developers to again be crossing a line. Nobody is threatening anyone's existence or dehumanizing them by asking them to disclose if they used an LLM to write their code. Since this is the second time this happened during this discussion, I would really hope we could be a bit less careless with our words.
Best
Magnus On 7/16/26 10:51, Moritz Angermann via ghc-devs wrote:
Julian,
I'm not sure how many more times I need to write this: It is fundamentally against my nature to tell anyone what to do, that includes telling people to use LLMs. It is probably from the same foundational values, that I am against telling people what NOT to do. You of all people probably know this even the best.
You explicitly want a policy that puts judgement on people who use LLMs, and segregates the pure (hand written) from the impure (assisted) people, yet you claim you want to keep _all_ of them? You must see how qualified segregation tells one group that they are NOT welcome?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
This is NOT my opinion, and I also do NOT think this logical conclusion follows.
Best, Moritz
On Thu, 16 Jul 2026 at 15:44, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that:
- you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine. _______________________________________________ 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
_______________________________________________ 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
Magnus, Your comment from yesterday has left me a bit restless, so I’ve spent a large part of today educating myself about the usage of the word segregation. I’ve also learned a few new words while doing so. The more precise term for what the policy itself does seems to be stratification, as in: “The policy stratifies contributions (and potentially contributors) according to their production method.” It explicitly says that one method is strongly preferred, while the other is merely permitted. For this to become segregation, though, there would need to be some actual separation or exclusion in practice. I do know that some people will not review contributions that carry an LLM-assistance label, and I don’t even fault them for deciding how to spend their own time. But review is also a necessary part of getting a contribution accepted. So when one labelled class of contributions has access to fewer reviewers -- and may, in some areas, have no willing reviewer at all -- that classification has real consequences. So I think the distinction I would make now is this: the policy does not formally segregate contributors, but it does explicitly stratify methods of contribution and creates a two-tier social status in which assisted authors are treated as less trusted or less desirable. When that status difference produces systematic separation (e.g. “I will not review this kind of contribution”) or practical exclusion because of the LLM label, it becomes de facto segregation within the review process. Best, Moritz On Thu, 16 Jul 2026 at 16:29, Moritz Angermann <moritz.angermann@gmail.com> wrote:
Magnus,
I see you did not read my email, but got hung up on the word[1] I chose. It is not about the mere disclosure. It is about the classification of contributors into two categories, those that write code by hand (who are strongly preferred) over those that use assistive technologies to write code.
Now, please explain to me how I am supposed to feel about this, as someone who considers themselves in the second category? And what word choice you would prefer me using?
Best, Moritz
— [1]: https://www.merriam-webster.com/dictionary/segregate
On Thu, Jul 16, 2026 at 4:02 PM Magnus Viernickel via ghc-devs < ghc-devs@haskell.org> wrote:
I find the framing that this policy is used to "segregate" (given what the term usually refers to) developers to again be crossing a line. Nobody is threatening anyone's existence or dehumanizing them by asking them to disclose if they used an LLM to write their code. Since this is the second time this happened during this discussion, I would really hope we could be a bit less careless with our words.
Best
Magnus On 7/16/26 10:51, Moritz Angermann via ghc-devs wrote:
Julian,
I'm not sure how many more times I need to write this: It is fundamentally against my nature to tell anyone what to do, that includes telling people to use LLMs. It is probably from the same foundational values, that I am against telling people what NOT to do. You of all people probably know this even the best.
You explicitly want a policy that puts judgement on people who use LLMs, and segregates the pure (hand written) from the impure (assisted) people, yet you claim you want to keep _all_ of them? You must see how qualified segregation tells one group that they are NOT welcome?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
This is NOT my opinion, and I also do NOT think this logical conclusion follows.
Best, Moritz
On Thu, 16 Jul 2026 at 15:44, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
Well, if you want GHC to become a political vehicle for an ideology
Not spelling out values doesn't mean that you don't take sides. Your constant "LLMs are here to stay" and "it's just a tool" is exactly doing that, you are implying that:
- you can't resist, stop resisting - you have to follow everyone else or you will be left behind - your value is only your output
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine. _______________________________________________ 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
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Thu, Jul 16, 2026 at 08:44:10AM -0000, Julian Ospald via ghc-devs wrote:
I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
To add my personal point of view on this, it is only the advent of LLMs that has made me think I could possibly become a contributor to GHC. I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC. (The same goes for most projects actually.) Tom
I am sure there are many others like you and they are very capable potential contributors. We do have opposing views in the community but I do not think anyone should feel discouraged to contribute because of those who hold opposing views, it will be detrimental to the project, I am sure they will find enough supporters. The real problem starts only if an otherwise good patch is rejected or totally neglected purely on the basis of LLM use. -harendra On Thu, 16 Jul 2026 at 14:58, Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:
On Thu, Jul 16, 2026 at 08:44:10AM -0000, Julian Ospald via ghc-devs wrote:
I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
To add my personal point of view on this, it is only the advent of LLMs that has made me think I could possibly become a contributor to GHC. I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC. (The same goes for most projects actually.)
Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Thu, Jul 16, 2026 at 05:17:54PM +0530, Harendra Kumar via ghc-devs wrote:
I am sure there are many others like you and they are very capable potential contributors. We do have opposing views in the community but I do not think anyone should feel discouraged to contribute because of those who hold opposing views, it will be detrimental to the project, I am sure they will find enough supporters. The real problem starts only if an otherwise good patch is rejected or totally neglected purely on the basis of LLM use.
Sure, and to be clear I'm glad this dicussion is happening and I'm grateful to everyone who's sharing their opinion. I only chimed in because Julian made a (very good and important in my opinion) point about wanting to maintain a certain culture so we can keep engaged and curious *people* who are the source of ideas and products in the Haskell ecosystem. I agree and I want to say the problem cuts both ways: one way to keep engaged and curious people (I self identify as one) is to welcome LLM use. Tom [Disclaimer: I am financially invested in increased LLM use in various ways]
No one in *this* entire thread has been suggesting to neglect a patch purely on the basis of LLM use. The policy very clearly argues against this. Although often mischaracterized as a loud minority, there's a fair number of people who were in principle pro a blanket LLM ban. You're talking to them right now and if the policy is watered down to "well, quality" I don't see what any of us gets out of this. Why should we meet you half-way? Other communities (see Agda) have effectively split over this. And this thread really makes it look to me like any concerns on LLM use or additional burden on LLM users is seen as an attempt to "segregate", shame or violate those peoples privacy. I find this line of argumentation to be false and actively misleading. Even the current AI policy demands additional burden on LLM users. It is absolutely reasonable and common sense, unless we go back to comparing them with calculators and ignore the large body of scientific evidence of risks and the massive negative fallout in other open source projects. In order to salvage *some* positive use, we have to be mindful about its use, not ignorant. This is not discrimination, this is caution. On Thu, 2026-07-16 at 17:17 +0530, Harendra Kumar via ghc-devs wrote:
I am sure there are many others like you and they are very capable potential contributors. We do have opposing views in the community but I do not think anyone should feel discouraged to contribute because of those who hold opposing views, it will be detrimental to the project, I am sure they will find enough supporters. The real problem starts only if an otherwise good patch is rejected or totally neglected purely on the basis of LLM use.
-harendra
On Thu, 16 Jul 2026 at 14:58, Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:
On Thu, Jul 16, 2026 at 08:44:10AM -0000, Julian Ospald via ghc- devs wrote:
I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
To add my personal point of view on this, it is only the advent of LLMs that has made me think I could possibly become a contributor to GHC. I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC. (The same goes for most projects actually.)
Tom _______________________________________________ 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
I fully agree with you Julian, and until we have proof that there are large-scale cases of calculator-induced psychoses and cognitive degeneration I'd like to suggest that we stop with the false equivalences. LLMs are a powerful tool which means that, much like a power tool, it must be handled with care and safety precautions. Otherwise you're just going to harm yourself and possibly others. On a personal touch, I worry that contributors who absolutely rely on LLMs will be excluded from participating when the token price ceases to be subsidized, and AI companies are brought back to reality and must make profits, if not break even. Another reason why cultivating the contributors is more important that getting code merged at any cost. Le 16/07/2026 à 14:25, Julian Ospald via ghc-devs a écrit :
No one in *this* entire thread has been suggesting to neglect a patch purely on the basis of LLM use.
The policy very clearly argues against this.
Although often mischaracterized as a loud minority, there's a fair number of people who were in principle pro a blanket LLM ban. You're talking to them right now and if the policy is watered down to "well, quality" I don't see what any of us gets out of this. Why should we meet you half-way?
Other communities (see Agda) have effectively split over this. And this thread really makes it look to me like any concerns on LLM use or additional burden on LLM users is seen as an attempt to "segregate", shame or violate those peoples privacy.
I find this line of argumentation to be false and actively misleading.
Even the current AI policy demands additional burden on LLM users. It is absolutely reasonable and common sense, unless we go back to comparing them with calculators and ignore the large body of scientific evidence of risks and the massive negative fallout in other open source projects.
In order to salvage *some* positive use, we have to be mindful about its use, not ignorant. This is not discrimination, this is caution.
On Thu, 2026-07-16 at 17:17 +0530, Harendra Kumar via ghc-devs wrote:
I am sure there are many others like you and they are very capable potential contributors. We do have opposing views in the community but I do not think anyone should feel discouraged to contribute because of those who hold opposing views, it will be detrimental to the project, I am sure they will find enough supporters. The real problem starts only if an otherwise good patch is rejected or totally neglected purely on the basis of LLM use.
-harendra
On Thu, 16 Jul 2026 at 14:58, Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:
On Thu, Jul 16, 2026 at 08:44:10AM -0000, Julian Ospald via ghc- devs wrote:
I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not. To add my personal point of view on this, it is only the advent of LLMs that has made me think I could possibly become a contributor to GHC. I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC. (The same goes for most projects actually.)
Tom _______________________________________________ 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
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- Hécate ✨ WWW: https://glitchbra.in RUN: BSD
Julian, If we assume for simplicity we have two distinct groups: (a) people open to LLMs (b) people against LLMs, And I’ll count myself into (a) and you, Julian, into (b). As it stands: You are asking something of me. Specifically that I accept (1) to be in a group of de-skilled, less valued than hand written code contributors because I don’t share your absolutist view on strongly preferred hand written code, and (2) accept your characterization of LLMs as harmful. What am I asking of you? Best, Moritz On Thu, Jul 16, 2026 at 7:26 PM Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
No one in *this* entire thread has been suggesting to neglect a patch purely on the basis of LLM use.
The policy very clearly argues against this.
Although often mischaracterized as a loud minority, there's a fair number of people who were in principle pro a blanket LLM ban. You're talking to them right now and if the policy is watered down to "well, quality" I don't see what any of us gets out of this. Why should we meet you half-way?
Other communities (see Agda) have effectively split over this. And this thread really makes it look to me like any concerns on LLM use or additional burden on LLM users is seen as an attempt to "segregate", shame or violate those peoples privacy.
I find this line of argumentation to be false and actively misleading.
Even the current AI policy demands additional burden on LLM users. It is absolutely reasonable and common sense, unless we go back to comparing them with calculators and ignore the large body of scientific evidence of risks and the massive negative fallout in other open source projects.
In order to salvage *some* positive use, we have to be mindful about its use, not ignorant. This is not discrimination, this is caution.
On Thu, 2026-07-16 at 17:17 +0530, Harendra Kumar via ghc-devs wrote:
I am sure there are many others like you and they are very capable potential contributors. We do have opposing views in the community but I do not think anyone should feel discouraged to contribute because of those who hold opposing views, it will be detrimental to the project, I am sure they will find enough supporters. The real problem starts only if an otherwise good patch is rejected or totally neglected purely on the basis of LLM use.
-harendra
On Thu, 16 Jul 2026 at 14:58, Tom Ellis via ghc-devs <ghc-devs@haskell.org> wrote:
On Thu, Jul 16, 2026 at 08:44:10AM -0000, Julian Ospald via ghc- devs wrote:
I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
To add my personal point of view on this, it is only the advent of LLMs that has made me think I could possibly become a contributor to GHC. I wouldn't have the stamina to remain engaged otherwise. A policy that discourages LLM use, in effect if not in word, makes it less likely I will ever contribute to GHC. (The same goes for most projects actually.)
Tom _______________________________________________ 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
ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
It is a mechnical view of open source and collaboration that is focused on the product, not on the culture from which those products arise. My view is different... I think it is the human culture from which those ideas and products originate and Haskell has given a home to many engaged and curious people. We want to keep those people, whether they use LLMs or not.
I agree that it's a good idea to focus on positive messaging, even just to reach a baseline consensus on the positive portion of the policy, if we can't on the portions that point out some perceived risks and don't point out others. Maybe it makes sense to clearly delimit the two portions?
If we don't express a preference for human authorship, we're effectively saying "you have to use LLMs so stay relevant". I think this is very clearly your opinion. It is not mine.
Maybe an even lower baseline to start from would be to express appreciation of human (not distinguishing whether LLM-assisted or not) contribution at all, and mark clearly we are not under the same pressures as commercial companies that may decide they can only afford 10x LLM, not bare-human, programmers (I don't suggest here they are right or wrong in doing so nor whether the 10x claim is true). E.g. "we value your contributions, regardless whether they are big and/or frequent or the opposite". A slightly more ambitious next positive message would appreciate quality of contributions, regardless of whether the focus on quality diminishes their volume. Next, value clear attribution of portions of the contributed work with different authorship (treating LLM as "authors" for this purpose) and clear delineation of what the contributor takes responsibility for vs what is taken on authority and trust (e.g,. widely-known published code, a community poll, a formal proof, an LLM review) that may or may not be shared by the GHC reviewers and mtainers. Etc. Only then I'd go into what contributions the GHC maintainers guess have a higher chance of being reviewed and merged, then into what GHC maintainers prefer in the contributions in general and only then what risks they perceive and only then what extra requirements they impose on top of the formal gitlab mechanisms. I'm afraid what I'm proposing is going to make the messaging vague, abstract and verbose, but not as much as if we'd start with ontology, axiology and an exposition of competing worldviews in the community.
Hi Simon (Jakobi), I'm not deeply engaged in the discussion; I just want to insert my two cents.
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
I think you're missing an important aspect of this "good exercise". Writing code by hand allows you to examine the abstractions you've decided to use. Bad abstractions require a lot of code to use, and you quickly grow tired of them. You naturally proceed to think about possible improvements. It's actually beneficial to be bad and extremely slow at writing code if you apply this reasoning =) At the same time, any amount of LLM-produced code is cheap to produce. It's very easy to ignore bad abstractions or the absence of abstraction if it only takes 10–20 minutes to produce thousands of lines of code. Lots of practice provides an intuition about bad and good abstractions, and you may choose the right one from the very beginning. However, writing code by hand is still a good battle test and reality check. I hope this reasoning model is beneficial to the discussion. Cheers, Andrei. P.S. The grammatical structure of this message has been checked by an AI. On 14.07.2026 18:42, Simon Jakobi via ghc-devs wrote:
Hi Simon,
here are my comments on the policy document:
In particular, you must not use AI-generated text in a direct conversation with a human reviewer.
I think this is too restrictive. A contributor may easily reach the limits of their understanding during a code review, and I think it's ok to resort to using an LLM then. I think it's fair to require that they clearly mark the LLM-generated part of their response though.
P1: Write MRs that are easy to review
I fully agree with this, and apologize that some of my MRs have not been easy to review! I do want to point out though that MRs marked as "Draft" should not be held to the same standards as a "ready" / non-draft MR. I frequently open draft MRs mainly to get the CI results. Sometimes I still get detailed reviews on these MRs, and then feel sorry that a reviewer wasted their time on this.
P2: Full responsibility
You must understand, and be able to explain, every line of code, and every sentence of documentation. Every line!
I think that's a good goal, but even for MRs, maybe too strict a requirement. Where do you draw the line? Is the contributor expected to understand every (pre-existing) function they used? To what extent? Strictness and performance characteristics too?
For bug reports, I think GHC should be more lenient, and instead require that LLM use is clearly signalled.
P3: Strong preference for human authorship
We strongly prefer human-written code
I understand that it's "good exercise" to write code by hand.
But I've always been pretty bad and extremely slow to write code. And now that recent models have become so good at producing code, I was relieved that I can now contribute without being so limited by my code-writing skills. I already realize that some core contributors have much disdain for LLM-generated code. If the GHC project decides to devalue contributions of LLM-generated code with this language, I think this will reduce my motivation to contribute.
Writing it yourself forces you to think about every line; and it imposes a cost on you if you write 1000 lines instead of 100.
IMHO contributing to GHC is already quite onerous and "costly", especially for newcomers. Just think of the flaky CI system and recent GitLab performance. Instead of trying to impose additional costs on contributors, I think it would be better to try to reduce the cost of reviewing and maintenance! For example, I think GHC should try using LLMs for "first-line" code review. LLMs are already very capable at debugging. How about investing in fuzzing or better automated testing, so bugs are discovered before they make it into a release?
We strongly prefer human-written documentation.
Documentation generated by recentish models like Claude Opus 4.8 has indeed been quite bad. Claude Fable 5 is already much better at this.
I think the main incentive resulting from this policy is to include _less_ documentation in contributions. In a world where LLMs are very capable of making sense of large code bases, maybe that's not much of a drawback.
---
Overall, I feel that much of the recent discussion about LLMs in GHC and Haskell has been driven by fear and anger. I think many Haskellers are very proud of their skill to produce high-quality code, and as LLMs get better and better at this, this skill is becoming "less special".
Instead of trying to discourage contributions that involve LLMs, I think this project should rather try to welcome creative use of LLMs for the benefit of this project and all Haskell users.
Sorry for the bad wording here and there. I did not use an LLM to write these comments, and it took me an embarrassingly long time.
Cheers, Simon
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
participants (18)
-
amindfv＠mailbox.org -
Andreas Klebinger -
Andrei Borzenkov -
Brandon Allbery -
Bryan Richter -
Harendra Kumar -
Hécate -
Iavor Diatchki -
Josh Meredith -
Julian Ospald -
Magnus Viernickel -
Mikolaj Konarski -
Moritz Angermann -
Sebastian Graf -
Simon Jakobi -
Simon Peyton Jones -
Tom Ellis -
Wolfgang Jeltsch