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 < ghc-devs@haskell.org> wrote:
On Wed, 15 Jul 2026 at 03:24, Wolfgang Jeltsch via ghc-devs < ghc-devs@haskell.org> 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 -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org