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 < [email protected]> wrote: > > > On Thu, 16 Jul 2026 at 18:51, Wolfgang Jeltsch <[email protected]> > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
