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 > <[email protected] > <mailto:[email protected]>> 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 -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to [email protected] <mailto:ghc- > [email protected]> > _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
