The only viewpoint I really agree with in this article is the "use it or lose it" mentality. Skills are developed and maintained by practicing them, but if all the author really wants to do is write code, then LLMs are literally an answer to their prayers!

You can enable virtually free test driven development. Write the test names down and let the LLM implement them for you. You save 50% of your time and you get to go to town on implementation and or optimizations.

You can have the LLM take the non-tech-counterparts description of a bug and have it point you at precise lines of code to investigate rather than grepping around a codebase you might not know well.

You can onboard to new languages, frameworks, repositories extremely fast by having a partner (the LLM) explain implementation patterns and approaches on demand! You don't even need to talk to another human being! Get your questions answered in seconds and start coding!

You can rapidly prototype. You can get immediate code reviews. You can rubber duck. You can visualize business/logic flows and code branching to better understand existing implementations. You can even have the LLM write an implementation plan for you then write the code yourself!

If you cant find a way to write more code with LLMs, its either an imagination or skill issue.

>Reviewing is worse than writing

I think the reason this discussion keeps coming up is that the people who are getting a lot out of these tools are people who are, at best, the software-equivalent of assembly-line workers. If something can be easily understood by passively reading it then it probably isn't complicated or novel and therefore it's not surprising a pseudorandom bullshit generator can do it for you; all it lacks is a unit testing system which can verify that its interpretation of the problem-statement matches the interpretation which would be most obvious to a human and that is evidently not a solved problem thus far.

If the hardest part of your job is understanding code written by other people and even code written by yourself in the distant past, then LLMs are of literal use because the problem they solve was never a significant bottleneck and in fact their "solution" only serves to pump a higher volume of fluid through the neck of the proverbial bottle.

It's the difference between reading somebody's paper in a mathematical journal to understand how they came to the conclusion they are presenting, and merely using the identity they have proven on faith. If all that mattered was to perform some calculation based on their work then its clear which approach will get more work done in less time but if you don't take it for granted that everything in the journal is correct or if you want to be able to further develop ideas based upon their proof then you have to spend a few days or even weeks trying to understand how each step leads to its successor.

It's also why i hate the old adage about not reinventing wheels, it promotes ignorance by asserting that education itself is ignorance.

“a new paradigm for software development that you must learn or be left behind” that’s a completely inaccurate statement. Nobody is saying that you will be “left behind”. It certainly is a new paradigm but it doesn’t mean the old way of doing things won’t continue to exist. Just like there are still some problems that require code to be written in C or even assembly. Just like there are hand-made goods. The size of the opportunity is a whole different story.

You're free not to. Time will tell who's right

If you're working on something where the cost of bugs is high and they're tricky to detect, LLM generated code may not be a winning strategy if you're already a skilled programmer. However, LLMs are great for code review in these circumstances - there is a class of bugs that are hard to spot if you're the author.

As a simple example, accidentally inverting feature flag logic will not cause tests to fail if the new behavior you're guarding does not actually break existing tests. I and very senior developers I know have occasionally made this mistake and the "thinking" models are very good at catching issues like this, especially when prompted with a list of error categories to look for. Writing an LLM prompt for an issue class is much easier than a compiler plugin or static analysis pass, and in many cases works better because it can infer intent from comments and symbol names. False positives on issues can be annoying but aren't risky, and also can be a useful signal that the code is not written in a clear way.

We can't uninvent LLMs. They're here already and the best course of action for everyone is to learn to live with them.

That being said I noticed that the more opinionated a language/framework/library is, the worse off one is using LLMs.

I was surprised by this, but then I put a particularly fishy line into GitHub's search box. What I saw were piles upon piles of bad practices and incorrect usages. There's a lot of bad code there and LLMs are learning from it.

I think you wrong the problem is not LLM , the problem is you .

What I don't understand in all that noise from the LLM critics - they keep talking about how LLMs are so horrendously bad at writing code as if that's the only thing we're trying to use them for. As if they're not even genuine programmers, working on real projects, touching code every day.

Software crafting is so much more than merely writing code. There's a significant amount of reading code that goes into it. Code written by you. Code written by someone else. Someone else's code that you butchered with your edits, your own code butchered by someone else, and everything intertwined in between. Code that can't easily be explained by looking at it - sometimes you have to find relevant PRs, tickets, documentation, related online communication, some loosely-related code sitting someplace else, etc.

LLMs absolutely can help you read code, just as they are very capable of helping someone study a book or an academic paper. Denying that fact simply is ignorance. Of course, LLMs are absolutely capable of leading you in the wrong direction, confusing you, and giving you incorrect facts, even when you're studying text in plain English, just like it's possible to end up at the bottom of a lake when driving a car. Everyone needs to exercise caution and "know what the fuck they're doing" when using a model. But calling LLMs "bullshit generators" and "magic 8 balls" is so stupid. Sure, if you use it to perform bullshit stuff, it will generate nothing but bullshit.

I can’t take this article seriously, and neither should you. Being anti AI/anti LLM is solidly in the Luddite camp; there’s really no more debates to be had. Every serious inquiry shows productivity gains by using ai.

It’s anyone’s prerogative to continue to advocate for the horse and buggy over the automobile, but most people won’t bother to take the discussion seriously.