On Wed, Jul 29, 2026 at 12:42:45PM +0000, code@jaro.addy.io wrote:
On 29 Jul 2026, at 14:24, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote: Perhaps, or perhaps people use a better, but more expensive, model less?
I expect most people to use a subscription like Claude Max or OpenAI Pro, which encourages using as much as the plan allows.
Subscriptions typically come with a number of credits that refresh every so often. More expensive models use more credits. Subscription use is not "unlimited". https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usag... Tom
On 29 Jul 2026, at 14:58, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:
Subscriptions typically come with a number of credits that refresh every so often. More expensive models use more credits. Subscription use is not "unlimited".
Hence the "as much as the plan allows" in my previous e-mail. I also just find it suspicious that these companies do not openly disclose their energy consumption and emission statistics (which is a hotly debated topic). This makes me think it does not paint them in a good light. Thus, my opinion remains that using LLMs intensively (e.g., as agents) seems to cause significant greenhouse gas emissions. That alone makes its use questionable, but combined with all the other ecological and social factors it is really unacceptable to me. Jaro
Hello, I've been following the discussion on the policy, and I should mention that to me this version also seems entirely reasonable. I have been using agents for work quite a bit lately, but I think the way I use them is very different to how some folks seem to imagine LLM use (at least based on the comments, apologies in advance if I have misunderstood). Even if I work with an agent all day long, I never run the agent continuously all the time (let alone have many agents work autonomously on tasks). As this is obviously new technology I've been experimenting with various workflows, but I have found that when I am not working with the agents quite closely, the results tend to be a bit mixed, but more importantly, it is really hard (and boring) for me to review large chunks of freshly generated code. Instead, I tend to be closely involved with the planning and implementation of each task, as then I can review things as they are being written. It really feels a lot like normal programming, it is just that I don't need to type in all the code. I also tend to be pretty mindful of the context length and caching behavior, which I think reduces both the amount of computation needed, and also the cost. Cheers, Iavor On Wed, Jul 29, 2026, 4:44 PM Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:
On 29 Jul 2026, at 14:58, Tom Ellis via ghc-devs < tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:
Subscriptions typically come with a number of credits that refresh every so often. More expensive models use more credits. Subscription use is not "unlimited".
Hence the "as much as the plan allows" in my previous e-mail.
I also just find it suspicious that these companies do not openly disclose their energy consumption and emission statistics (which is a hotly debated topic). This makes me think it does not paint them in a good light.
Thus, my opinion remains that using LLMs intensively (e.g., as agents) seems to cause significant greenhouse gas emissions. That alone makes its use questionable, but combined with all the other ecological and social factors it is really unacceptable to me.
Jaro _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
On Wed, Jul 29, 2026 at 01:44:05PM +0000, Jaro Reinders via ghc-devs wrote:
On 29 Jul 2026, at 14:58, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:
Subscriptions typically come with a number of credits that refresh every so often. More expensive models use more credits. Subscription use is not "unlimited".
Hence the "as much as the plan allows" in my previous e-mail.
I see, however, the full context was this ... On Wed, Jul 29, 2026 at 12:42:45PM +0000, code@jaro.addy.io wrote:
On 29 Jul 2026, at 14:24, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote: Perhaps, or perhaps people use a better, but more expensive, model less?
I expect most people to use a subscription like Claude Max or OpenAI Pro, which encourages using as much as the plan allows.
... so I assumed you were thinking that, under a subscription, one could use as many tokens of a newer, and "uses more electricity per token", model as of an older model, which is not in general the case. If that wasn't the point you were making, could you try to explain again? I think I don't get it. In any case, I think you are making the point "as models improve individuals will use them to a greater degree, at a higher power consumption, and therefore at a higher rate of carbon emissions", and I agree. What I don't agree with is that we're in a position to determine that this is something that should be discouraged let alone how it should be discouraged.
I also just find it suspicious that these companies do not openly disclose their energy consumption and emission statistics (which is a hotly debated topic). This makes me think it does not paint them in a good light.
Thus, my opinion remains that using LLMs intensively (e.g., as agents) seems to cause significant greenhouse gas emissions.
Assuming "significantly" means something like "outsized relative to other life activities that the general population accepts as normal", am I right that the opinion you state here is based on your suspicion, rather than hard facts and numbers? The numbers shared in this thread so far don't seems to support such an opinion. I certainly won't object to anyone modifying their own behaviour based on such a suspicion. But let's retrace our steps: this subthread started with "Tom amindfv---"'s comment:
Can you spare a bit of empathy for people who are concerned about, e.g. global warming or loss of drinking water due to LLMs (not to mention code quality)?
which I most certainly can. But maybe he meant to imply something further. If he didn't, no problem. Maybe he meant to imply "such people deserve the opportunities to voice their concerns". If he meant that, no problem. But if he meant to imply "such people should be able to influence GHC's LLM policy based on their concerns rather than hard evidence" then I do object to that.
That alone makes its use questionable, but combined with all the other ecological and social factors it is really unacceptable to me.
I have no wish to require you to accept anything, nor an objection to you sharing your point of view. Tom
On 7/29/26 17:21, Tom Ellis via ghc-devs 'ghc-devs at haskell.org' wrote:
"outsized relative to other life activities that the general population accepts as normal",
I think you should clarify which "general population" you mean. If you mean the general world population, I think you might be surprised with how little emissions are normal. Some data: in 2024 total global emissions per capita were 4.73 tonnes (https://ourworldindata.org/co2-emissions). Divide that by 366 and by 24 to get 538 gCO2/h, so I think the 228 gCO2/h is quite significant if you consider the "general population". Not to mention that we have collectively agreed to bring down all our emissions to zero. Jaro
On Wed, Jul 29, 2026 at 04:27:51PM +0000, Jaro Reinders via ghc-devs wrote:
On 7/29/26 17:21, Tom Ellis via ghc-devs 'ghc-devs at haskell.org' wrote:
"outsized relative to other life activities that the general population accepts as normal",
I think you should clarify which "general population" you mean. If you mean the general world population, I think you might be surprised with how little emissions are normal.
Some data: in 2024 total global emissions per capita were 4.73 tonnes (https://ourworldindata.org/co2-emissions). Divide that by 366 and by 24 to get 538 gCO2/h, so I think the 228 gCO2/h is quite significant if you consider the "general population". Not to mention that we have collectively agreed to bring down all our emissions to zero.
Before addressing the issues raised in your latest message, I should first check (and probably should have checked earlier) whether what you've shared in this thread is to make a case about what the GHC LLM policy should be, or whether you're sharing information that you consider of general importance, that informs your behaviour and perspective as a world citizen (and in the hope that others might consider it of importance too), but only doing so in this thread because it happened to come up in the discussion. If the latter then I fear my response will end up with us going down an off-topic rabbit hole (albeit an interesting and important one!) but not actually contributing much insight to the topic at hand. Tom
OpenAI just published this article about improving efficiency wrt to tokens: https://openai.com/index/gpt-5-6-frontier-intelligence-efficiency/ This thread has had me thinking what the impact had been during the time where I had supplied significant CI capacity to GHC. It appears that running a proper CI machine: cpu/memory/disks/networks/cooling/… end up at roughly 1MWh/ year. So for a while my own support of GHCs CI had been at 8MWh/year-10MWh/year of energy expenditure across the windows, linux and macOS builders. There is a strange dynamic in CI becoming more demanding the more capacity is available. I like to think of it along the lines: more available resources make ideas viable that haven’t been viable and thus not even considered before. The inverse of: constraints are liberating. This leads me however to a rather curious thought experiment: given the high energy cost for CI, what are the tradeoff dynamics of using LLMs to screen PRs before running CI on them? As a user of a MacBook Air, I seem to also use one of the most energy efficient computes available right now. To put this in relation, it appears to me that if I were to use a monitor with the MacBook, I’d easily double my energy consumption (e.g. a 24” Dell display), to 30-40W. And my laptop is already fairly capable of running various small models locally without much additional power drain. If we want to reduce emissions ideas like data centers in space powered by solar are rather exiting (although the delivery is has an emission problem) as are data centers powered by renewable energy source (hydro, solar, wind). In my view, the buildout of more renewable and lower emission energy is incentivized by higher energy demands (and national legislation). My family owns an electric vehicle, but the TCO wrt to emissions compare to an ICE vehicle is really complicated as we still have complex mixes of energy generation. So my mental model is: 1. Higher energy demand 2. Higher incentives for diverse energy production forms 3. Wind/Solar/… increase in efficiency and become economically more attractive over fossils energy production. 4. Reduction of emission. I have a hard time believing there are people who want energy but insist on it to be generated in a way that is high in emissions when they could equally well get the same energy for the same price emission free. In the end I’m relieved that the CI I was providing very likely was in a Datacenter that was powered by hydropower. Or so the provider at least claimed. I’m also happy that I can run small models like Gemma, Phi, … locally on my machine without internet and without relying on inference providers. I firmly believe small local models will get better over time as incentives and research will continue in that direction. Ultimately during that short time I have on this planet, I want to be for things, not against. That provides me personally with a positive outlook of what can be and come as well as joy, which I prefer over negative outlook which makes me depressed. On Thu, Jul 30, 2026 at 12:09 AM Tom Ellis via ghc-devs < ghc-devs@haskell.org> wrote:
On Wed, Jul 29, 2026 at 04:27:51PM +0000, Jaro Reinders via ghc-devs wrote:
On 7/29/26 17:21, Tom Ellis via ghc-devs 'ghc-devs at haskell.org' wrote:
"outsized relative to other life activities that the general population accepts as normal",
I think you should clarify which "general population" you mean. If you mean the general world population, I think you might be surprised with how little emissions are normal.
Some data: in 2024 total global emissions per capita were 4.73 tonnes (https://ourworldindata.org/co2-emissions). Divide that by 366 and by 24 to get 538 gCO2/h, so I think the 228 gCO2/h is quite significant if you consider the "general population". Not to mention that we have collectively agreed to bring down all our emissions to zero.
Before addressing the issues raised in your latest message, I should first check (and probably should have checked earlier) whether what you've shared in this thread is to make a case about what the GHC LLM policy should be, or whether you're sharing information that you consider of general importance, that informs your behaviour and perspective as a world citizen (and in the hope that others might consider it of importance too), but only doing so in this thread because it happened to come up in the discussion.
If the latter then I fear my response will end up with us going down an off-topic rabbit hole (albeit an interesting and important one!) but not actually contributing much insight to the topic at hand.
Tom _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Am Do 30.07.2026 07:09 schrieb Moritz Angermann via ghc-devs:
[G]iven the high energy cost for CI, what are the tradeoff dynamics of using LLMs to screen PRs before running CI on them?
Why not just use less CI? I always had the impression that the whole idea of CI is flawed: running a multitude of complete build processes and tests for every tiny change (by default at least) seemed evidently weird to me. Why not run the build processes and tests only at specific points, preferably later during development? If, for example, you’re working on a feature that has nothing to do with code generation, it’s pretty useless to check early in the development process whether your code works also on some other architecture. If it works on yours, it likely will also work on the other, and on your own machine you can build incrementally. All the best, Wolfgang
I think we're quite far down the rabbit hole indeed. I wasn't really planning on going so deep into one small part of my concerns, but you nerdsniped me with your challenge to show real data about the greenhouse gas emissions. I do think it has given me a clearer picture, so I don't think it was wasted effort, but it was a lot of effort. Jaro
On 29 Jul 2026, at 19:10, Tom Ellis via ghc-devs <tom-lists-ghc-devs-2026@jaguarpaw.co.uk> wrote:
Before addressing the issues raised in your latest message, I should first check (and probably should have checked earlier) whether what you've shared in this thread is to make a case about what the GHC LLM policy should be, or whether you're sharing information that you consider of general importance, that informs your behaviour and perspective as a world citizen (and in the hope that others might consider it of importance too), but only doing so in this thread because it happened to come up in the discussion.
If the latter then I fear my response will end up with us going down an off-topic rabbit hole (albeit an interesting and important one!) but not actually contributing much insight to the topic at hand.
Tom
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want. Besides that argument, the only argument I've heard is that LLM use gives people the feeling of being more productive. But this has not been backed up with "hard evidence", let alone under the requirement of "carefully reviewing and understanding every line generated by an LLM". I doubt anyone can really achieve a worthwhile productivity gain compared to limiting LLM use to: prototyping, high level design, asking questions, and reviewing code (uses of LLMs which are not in question). Jaro
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want.
Historically people have been able to use whatever tools they want to *produce* open-source contributions. Nobody has argued that we need some kind of consensus on whether or not people can write their code in Vim or Emacs. We do need consensus on tools that are shared by the whole development community, e.g. CI. That is to say, "we" are not adopting LLMs. Some contributors are. This is one of the reasons why I think Simon's proposal is pretty good: it focusses on the part of the process that exists in the shared space that we all occupy: the contribution and review process; our growth as a community of developers who care about the project. To be blunt, I think this is the best we can do right now. It seems to me that the *crux* of the most heated disagreements in this thread is about whether or not use of LLMs is *immoral*. I think it's totally understandable for people to care about that, in both directions, and I agree that (if you oppose the use of LLMs) collective action via individual projects rejecting them can be effective. But it also seems clear that the GHC developers as a group do *not* have consensus on that question. Maybe other projects do, especially smaller and less diverse ones. But given the state of disagreement it seems to me that the only reasonable goal for a *policy for GHC* can be to focus on the things we *do *agree on, which I think the current policy does pretty well. We should continue to talk about the issues, but I think it would benefit everyone to stamp out even a limited policy now so we have something! M On Fri, 31 Jul 2026 at 12:45, Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want.
Besides that argument, the only argument I've heard is that LLM use gives people the feeling of being more productive. But this has not been backed up with "hard evidence", let alone under the requirement of "carefully reviewing and understanding every line generated by an LLM". I doubt anyone can really achieve a worthwhile productivity gain compared to limiting LLM use to: prototyping, high level design, asking questions, and reviewing code (uses of LLMs which are not in question).
Jaro
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
LLM code generation services are clearly not just tools, though. I find it disingenuous to compare them to Vim and Emacs. Even if you run LLMs completely locally, nobody can be trusted to know what the LLMs are really doing. If Vim introduces subtle bugs into your code that would be a very serious issue. If LLM services generate code with subtle bugs, nobody bats an eye. Even before the advent of LLMs, I would have been similarly opposed to people outsourcing work to unvetted human code writing services. Not just because of immediate code quality concerns, but also because they cannot be trusted to have good intentions. Jaro On 8/1/26 13:17, Michael Peyton-Lebed via ghc-devs 'ghc-devs at haskell.org' wrote:
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want.
Historically people have been able to use whatever tools they want to / produce/ open-source contributions. Nobody has argued that we need some kind of consensus on whether or not people can write their code in Vim or Emacs. We do need consensus on tools that are shared by the whole development community, e.g. CI.
That is to say, "we" are not adopting LLMs. Some contributors are.
This is one of the reasons why I think Simon's proposal is pretty good: it focusses on the part of the process that exists in the shared space that we all occupy: the contribution and review process; our growth as a community of developers who care about the project.
To be blunt, I think this is the best we can do right now. It seems to me that the /crux/ of the most heated disagreements in this thread is about whether or not use of LLMs is /immoral/. I think it's totally understandable for people to care about that, in both directions, and I agree that (if you oppose the use of LLMs) collective action via individual projects rejecting them can be effective. But it also seems clear that the GHC developers as a group do /not/ have consensus on that question. Maybe other projects do, especially smaller and less diverse ones. But given the state of disagreement it seems to me that the only reasonable goal for a /policy for GHC/ can be to focus on the things we /do /agree on, which I think the current policy does pretty well.
We should continue to talk about the issues, but I think it would benefit everyone to stamp out even a limited policy now so we have something!
M
On Fri, 31 Jul 2026 at 12:45, Jaro Reinders via ghc-devs <ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>> wrote:
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want.
Besides that argument, the only argument I've heard is that LLM use gives people the feeling of being more productive. But this has not been backed up with "hard evidence", let alone under the requirement of "carefully reviewing and understanding every line generated by an LLM". I doubt anyone can really achieve a worthwhile productivity gain compared to limiting LLM use to: prototyping, high level design, asking questions, and reviewing code (uses of LLMs which are not in question).
Jaro
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> To unsubscribe send an email to ghc-devs-leave@haskell.org <mailto:ghc- devs-leave@haskell.org>
Am Sa 01.08.2026 12:17 schrieb Michael Peyton-Lebed via ghc-devs:
Historically people have been able to use whatever tools they want to *produce* open-source contributions.
The difference is that previously people produced software with the help of tools, while with LLMs they use tools to produce software for them.
This is one of the reasons why I think Simon’s proposal is pretty good: it focusses on the part of the process that exists in the shared space that we all occupy: the contribution and review process; our growth as a community of developers who care about the project.
The growth of the community cannot be separated from the growth of its members, and this is influenced by the tools they use.
It seems to me that the *crux* of the most heated disagreements in this thread is about whether or not use of LLMs is *immoral*.
That’s not the only thing. Several people, including me, are worried about the negative effects that LLM use will have on the codebase. I realize that my above remarks didn’t add anything new to the discussion, but apparently some things that were already said have been overlooked or forgotten, so that it was probably worthwhile to repeat them. All the best, Wolfgang
Apologies for barging in. On some roads people drive in the left lane, on other roads people drive on the right. It helps though to clarify, which rules apply on each road. Middle of the road drivers take risks and endanger other drivers. Is there any particular reason why the bleeding edge camp, would not fork the GHC repo and go wild, no holds barred ? Or even do a number of repos, each starting with a clean slate ? This would make it a fairly clean experiment. It should be possible to compare the outcome.
Very interesting line of thought, which prompt three questions for me: 1. Why wouldn’t the purist camp fork GHC? Who decides which “side” forks “off”? 2. Why doesn’t the US just split into two countries? One republican and one democrat governed? 3. I believe there are today GHC developers literally driving on the left side of the road and others who drive on the right side of the road; even among the core GHC maintainers. There are even some who occasionally drive on the left and other times on the right. Why hasn’t GHC forked yet? What about the third group? The whole debate is trying to find common ground within a diverse group holding different opinions and beliefs. Something open source has been about (to me!) for a long time: people with different beliefs/orientations/associations/preferences congregating around a shared interest. There have been forks around belief systems (systemd), and there have been fierce discussions around other topics: vim/emacs, linux/macos/windows, permissive/copyleft. I personally do not think a fork is helpful. And I say that as someone who has forked ghc at stable-haskell.org. But the intention is to just explore more radical ideas and eventually upstream what sticks, not start a new lineage. We are a comparatively small community, and I (foolishly?) still believe there is a lot more that unifies us than divides us. On Sun, Aug 2, 2026 at 1:22 AM Imants Cekusins via ghc-devs < ghc-devs@haskell.org> wrote:
Apologies for barging in.
On some roads people drive in the left lane, on other roads people drive on the right. It helps though to clarify, which rules apply on each road. Middle of the road drivers take risks and endanger other drivers.
Is there any particular reason why the bleeding edge camp, would not fork the GHC repo and go wild, no holds barred ?
Or even do a number of repos, each starting with a clean slate ?
This would make it a fairly clean experiment. It should be possible to compare the outcome. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Am So 02.08.2026 06:14 schrieb Moritz Angermann via ghc-devs:
Why wouldn’t the purist camp fork GHC? Who decides which “side” forks “off”?
Clearly, the side that wants to do something different should fork, right?
The whole debate is trying to find common ground within a diverse group holding different opinions and beliefs. Something open source has been about (to me!) for a long time: people with different beliefs/orientations/associations/preferences congregating around a shared interest.
Well, if the differences concern topics not directly associated with the project at hand, then they might not be a problem. However, if the differences directly concern the development of the software, then there might be less of that shared interest of the people. All the best, Wolfgang
Clearly, the side that wants to do something different should fork, right?
Who is doing something different though, I guess that might be seen by both sides? The "others" want to use LLMs vs. The "others" want to impose additional restrictions? Ultimately though I don't think it matters much. The ones with the keys to gitlab.haskell.org will ultimately decide. That I believe are currently the core maintainers. What this discussion ultimately does is shed some light onto the different standpoints and viewpoints. The decision lies ultimately with those who control the canonical assets. Well, if the differences concern topics not directly associated with the
project at hand, then they might not be a problem. However, if the differences directly concern the development of the software, then there might be less of that shared interest of the people.
Granted, if there are concerns that lie on the extreme edges, we won't be able to bridge those differences. Permitting unrestricted autonomous machine contributions, or enforcing a guaranteed no llm involvement standpoint. Generally though, we'd try to work out a compromise that the majority of the contributors to the project can agree on. Again, the ones with the keys ultimately wield the power to make the final decision. Best, Moritz
Am So 02.08.2026 21:28 schrieb Moritz Angermann:
Clearly, the side that wants to do something different should fork, right?
Who is doing something different though; I guess that might be seen by both sides? “The ‘others’ want to use LLMs” vs. “The ‘others’ want to impose additional restrictions”?
I think it’s not so difficult to see who wants to do something different here. The “anti-LLM” people want to develop GHC as it was developed in the past; the “pro-LLM” people want to develop it in a different way. The restrictions that the “anti-LLM” people want to impose aren’t “additional”, given that they would only preserve the previous way of development: they’d just rule out a fundamentally different way of development, which hadn’t been explicitly ruled out previously only because it didn’t exist.
Ultimately though I don’t think it matters much. The ones with the keys to gitlab.haskell.org will ultimately decide.
I’ve been wondering repeatedly who will ultimately decide. Of course, the ones with the keys to the GitLab server can enforce any way of development that someone decided for; so in particular they can enforce what they decided for themselves. However, will they do this? I don’t think they will, but rather they’ll try to implement a decision that “pleases the community”. Which apparently doesn’t exist. In fact, what I’ve been seeing is that no decision has been made for quite some time. There’s only this ongoing discussion, whose only result regarding the AI policy proposal seems to be that it has been shifted towards the LLM side. All the best, Wolfgang
llms are manic interns that need interactive supervision when working on genuinely new stuff. no matter the mechanism of authorship, a human is underwriting their contrib or its trash. its about responsible contributions. eg recently i found / triggered a very insane silent data corruption bug in pytorches compiler in a project of mine, and there was no way i could have bisected into a minimal repro and a one line patch without tools. but at the same token no model would have been able to quickly find the root cause without me micro managing it like a confused intern who needs conceptual hand holding. (turns out having your dimensions all be distinct primes near powers of two really finds a lot of pytorch bugs ;) i have found that with the right setup, are an amazing assistive device (it helps me skip needing social context as much for getting ideas out of my head) i admittedly am biased in that im building my cross platform multi device harness/toolchain for llm stuff i hope can commercialize to support myself i will say that telling these models that they should treat icfp functional pearls as a reference for design taste to be helpful when using those tools. at the end of the day, if a tool helps you do things you care about in a way that you’re happy with and doesnt impose on your collaborators, who cares?!? that said, with string suoer vision these tools are incredible for system design experiments even if the generated code is meh On Mon, Aug 3, 2026 at 7:01 AM Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Am So 02.08.2026 21:28 schrieb Moritz Angermann:
Clearly, the side that wants to do something different should fork, right?
Who is doing something different though; I guess that might be seen by both sides? “The ‘others’ want to use LLMs” vs. “The ‘others’ want to impose additional restrictions”?
I think it’s not so difficult to see who wants to do something different here. The “anti-LLM” people want to develop GHC as it was developed in the past; the “pro-LLM” people want to develop it in a different way.
The restrictions that the “anti-LLM” people want to impose aren’t “additional”, given that they would only preserve the previous way of development: they’d just rule out a fundamentally different way of development, which hadn’t been explicitly ruled out previously only because it didn’t exist.
Ultimately though I don’t think it matters much. The ones with the keys to gitlab.haskell.org will ultimately decide.
I’ve been wondering repeatedly who will ultimately decide. Of course, the ones with the keys to the GitLab server can enforce any way of development that someone decided for; so in particular they can enforce what they decided for themselves. However, will they do this? I don’t think they will, but rather they’ll try to implement a decision that “pleases the community”. Which apparently doesn’t exist. In fact, what I’ve been seeing is that no decision has been made for quite some time. There’s only this ongoing discussion, whose only result regarding the AI policy proposal seems to be that it has been shifted towards the LLM side.
All the best, Wolfgang _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Hi all, I wanted to give some light feedback on this document, unrelated to the current discussion thread. Overall, I feel this document is in a very reasonable spot, we should try this approach and gather initial data on how it performs in practice! Thanks Simon and everyone for working on this. *"R1: Recommendation: write the final version yourself"* could be better softened to something like: *"R1: Make a final human author-led pass." *My thinking is that the current wording somewhat undermines the otherwise tool-neutral position, and could even be interpreted as a requirement in practice despite being labeled a recommendation. In my opinion, hand-typing every character isn't a relevant standard, except as a supplement to (P2). Best, Avi ᐧ On Sat, Aug 1, 2026 at 4:52 AM Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> wrote:
Am Sa 01.08.2026 12:17 schrieb Michael Peyton-Lebed via ghc-devs:
Historically people have been able to use whatever tools they want to *produce* open-source contributions.
The difference is that previously people produced software with the help of tools, while with LLMs they use tools to produce software for them.
This is one of the reasons why I think Simon’s proposal is pretty good: it focusses on the part of the process that exists in the shared space that we all occupy: the contribution and review process; our growth as a community of developers who care about the project.
The growth of the community cannot be separated from the growth of its members, and this is influenced by the tools they use.
It seems to me that the *crux* of the most heated disagreements in this thread is about whether or not use of LLMs is *immoral*.
That’s not the only thing. Several people, including me, are worried about the negative effects that LLM use will have on the codebase.
I realize that my above remarks didn’t add anything new to the discussion, but apparently some things that were already said have been overlooked or forgotten, so that it was probably worthwhile to repeat them.
All the best, Wolfgang _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
-- Avi Press Founder & CEO | Scarf
Hi Avi, On Sun, 2 Aug 2026, at 4:29 PM, Avi Press via ghc-devs wrote:
*"R1: Recommendation: write the final version yourself"* could be better softened to something like: *"R1: Make a final human author-led pass." *My thinking is that the current wording somewhat undermines the otherwise tool-neutral position, and could even be interpreted as a requirement in practice despite being labeled a recommendation. In my opinion, hand-typing every character isn't a relevant standard, except as a supplement to (P2).
I think that would make it quite a different recommendation and one that would no longer effectively "[force] you to think. It's hard to type in code that you don't understand!" In my experience at least, making a pass through LLM generated code can fail to catch both subtle issues and fundamental architectural mistakes. It often looks extremely reasonable until you start to engage with it critically and in earnest. It is extremely helpful to rephrase things in your own words to It seems like putting the cart before the horse to discount a recommendation because it doesn't come across as neutral enough to some. I think it is worth coming up with a policy that is derived from our principles as a community rather than reacting to LLMs ad hoc. And it is a strength of this draft that it takes this approach. Yet, if we derive from our principles that certain aspects of LLMs are harmful then we shouldn't shy away from that! The very purpose of a policy is to draw out these things. Cheers, Teo
I also think that softening R1 is a mistake. Notably R1 is worded quite strongly but is a *recommendation*. I think Simon is quite clear here:
All that said, it is a recommendation, not a requirement. Contributions are evaluated under P1–P3, not according to whether their final text was personally composed. In some extreme cases it would be peculiar to insist that a human type in every character of a code change -- for example, when an LLM finds an obviously-correct one-line code fix. More generally, it is possible to achieve (P2) so by forensically reviewing and revising the output of an LLM, checking that you understand and stand by every line of code, that there is no clearer or simpler way to achieve the goal; and that every sentence of documentation is accurate, necessary, clear, and fully yours. This level of attention may well take as much effort as writing it yourself.
Contributors are free to make the effort to follow P1-P3 however they wish, and so long as they really do manage that, we are not going to reject them (though we have a recommendation). That seems fair to everyone. I think the LLM users would argue that they can make contributions just as good as the manually written ones. Very good - the policy does not forbid that! M On Mon, 3 Aug 2026 at 11:00, Teo Camarasu via ghc-devs <ghc-devs@haskell.org> wrote:
Hi Avi,
On Sun, 2 Aug 2026, at 4:29 PM, Avi Press via ghc-devs wrote:
*"R1: Recommendation: write the final version yourself"* could be better softened to something like: *"R1: Make a final human author-led pass." *My thinking is that the current wording somewhat undermines the otherwise tool-neutral position, and could even be interpreted as a requirement in practice despite being labeled a recommendation. In my opinion, hand-typing every character isn't a relevant standard, except as a supplement to (P2).
I think that would make it quite a different recommendation and one that would no longer effectively "[force] you to think. It's hard to type in code that you don't understand!" In my experience at least, making a pass through LLM generated code can fail to catch both subtle issues and fundamental architectural mistakes. It often looks extremely reasonable until you start to engage with it critically and in earnest. It is extremely helpful to rephrase things in your own words to
It seems like putting the cart before the horse to discount a recommendation because it doesn't come across as neutral enough to some. I think it is worth coming up with a policy that is derived from our principles as a community rather than reacting to LLMs ad hoc. And it is a strength of this draft that it takes this approach. Yet, if we derive from our principles that certain aspects of LLMs are harmful then we shouldn't shy away from that! The very purpose of a policy is to draw out these things.
Cheers, Teo _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
Michael Peyton-Lebed wrote:
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want. Historically people have been able to use whatever tools they want to *produce* open-source contributions.
That statement sounds good, but unfortunately it is not true. In the creation of an MIT licensed code, you were never able to use GPL 3 codes. In the creation of any such code, you were never able to use tools at anyone's disposal such as theft, espionage, plagiarism. Those are facts so basic that it's easy to forget them, so when another such basic fact comes under discussion, its mere discussion is dismissed outright. In fact there have been heated debates about each of those in the programming community before the time of some people discussing this in this thread, so it's important to remind those discussion have indeed happened.
Nobody has argued that we need some kind of consensus on whether or not people can write their code in Vim or Emacs.
There has never been question of who the code belongs to once it's been written out of Vim or Emacs. If an editor attempted this I can assure you there would be considerations, as there have been in the past, e.g. with pastebins that had egregious policies.
We do need consensus on tools that are shared by the whole development community, e.g. CI.
I disagree, everyone can run their own CI if they so wish. Many have.
That is to say, "we" are not adopting LLMs. Some contributors are.
If Bob adopts LLMs and the substance we work with, the code in the repository, now contains LLM output, then if I start working with, or merely even utilizing, this code, then I too have adopted LLMs. Adoption by one contributor immediately means adoption by not just all contributors, but also by all users. I'm surprised people will have long discussions about the "virality of GPL", the outcomes of which can be ignored by every end user, whereas in this situation, where there isn't even a way to excuse yourself out of the outcomes, there is no recognition of such an issue.
This is one of the reasons why I think Simon's proposal is pretty good: it focusses on the part of the process that exists in the shared space that we all occupy: the contribution and review process; our growth as a community of developers who care about the project.
The ownership of the code in the repository everyone commits to is a matter that exists in the shared space we all occupy.
To be blunt, I think this is the best we can do right now. It seems to me that the *crux* of the most heated disagreements in this thread is about whether or not use of LLMs is *immoral*.
There has never been an argument over whether using Vim or Emacs is immoral. Therefore there is no analogy. I am 100% sure if some unsavory people came out with EugenicsEmacs or GenocideVim we'd be having a discussion about it and whether we want contributors using these, and if users caught wind of this being allowed there would at least be five separate boycotts of Haskell as a whole.
I think it's totally understandable for people to care about that, in both directions, and I agree that (if you oppose the use of LLMs) collective action via individual projects rejecting them can be effective. But it also seems clear that the GHC developers as a group do *not* have consensus on that question. Maybe other projects do, especially smaller and less diverse ones. But given the state of disagreement it seems to me that the only reasonable goal for a *policy for GHC* can be to focus on the things we *do *agree on, which I think the current policy does pretty well.
We should continue to talk about the issues, but I think it would benefit everyone to stamp out even a limited policy now so we have something!
M
I think a policy allowing by fiat a questioned practice without addressing the posed questions because those questions are difficult to answer is not a good policy. Instead what Mr Jaro said before applies: "I don't think we should always adopt new technologies or services without careful consideration".
On Fri, 31 Jul 2026 at 12:45, Jaro Reinders via ghc-devs < ghc-devs@haskell.org> wrote:
In an attempt to steer this discussion back in a constructive direction, I would like to state that I don't think we should always adopt new technologies or services without careful consideration. This seems to directly contradict the main argument of the people who are in favor of LLM use, which is that they want to be free to use whatever "tools" they want. Besides that argument, the only argument I've heard is that LLM use gives people the feeling of being more productive. But this has not been backed up with "hard evidence", let alone under the requirement of "carefully reviewing and understanding every line generated by an LLM". I doubt anyone can really achieve a worthwhile productivity gain compared to limiting LLM use to: prototyping, high level design, asking questions, and reviewing code (uses of LLMs which are not in question). Jaro _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org
participants (11)
-
Avi Press -
Carter Schonwald -
code＠jaro.addy.io -
damiancoding＠gmail.com -
Iavor Diatchki -
Imants Cekusins -
Michael Peyton-Lebed -
Moritz Angermann -
Teo Camarasu -
Tom Ellis -
Wolfgang Jeltsch