> > 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 < [email protected]> 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 < > [email protected]> wrote: > >> >> >> On Wed, 15 Jul 2026 at 03:24, Wolfgang Jeltsch via ghc-devs < >> [email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > 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]
