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>