Hm… I think it’s fair to say that as a learning tool, when you are not familiar with the domain, coding assistants are the extremely valuable for everyone. I w

Hm… I think it’s fair to say that as a learning tool, when you are not familiar with the domain, coding assistants are the extremely valuable for everyone. I wrote a kotlin idea plugin in a day; I’ve never used kotlin before and the jetbrains ui framework is a dogs breakfast of obscure edge cases. I had no skills in this area, so I could happily lean into the assistance provided to get the job done. And it got done. …but, I don’t use coding assistants day to day in languages I’m very familiar with: because they’re flat out bad compared to what I can do by hand, myself. Even using Python, generated code is often subtly wrong and it takes more time to make sure it is correct than to do it by hand. …now, I would assume that a professional kotlin developer would look at my plugin and go: that’s a heap of garbage, you won’t be able to upgrade that when a new version comes out (turns out, they’re right). So, despite being a (I hope) competent programmer I have three observations: 1) the code I built worked, but was an unmaintainable mess. 2) it only took a day, so it doesn’t matter if I throw it away and build the next one from scratch. 3) There are extremely limited domains where that’s true, and I personally find myself leaning away from LLM anything where maintenance is a long term goal. So, the point here is not that developers are good/bad: It’s the LLM generated code is bad. It is bad. It is the sort of quick, rubbish prototyping code that often ends up in production… …and then gets an expensive rewrite later, if it does the job. The point is that if you’re in the latter phase of working on a project that is not throw away… You know the saying. Betty had a bit of bitter butter, so she mixed the bitter butter with the better butter. But it made the better butter bitter.