I code to understand. That's it. That's all. My code is a reflection of a problem definition and a solution. The problem may be under- or poorly defined and the solution may be lousy but by God it's there as a clear reference to be further reasoned about.

Programmers who don't work to deepen their understanding? Nah, sorry, not programmers I want anywhere near the code I'm working on.

To the extent that an LLM can help deepen understanding, good! Use it! Use its code. But you use it according to your intentional, systematic understanding of what the you're doing and why. And that understanding is not a function of code generation or, worse, code churn for the sake of feeling like you're going fast and paying less.

> LLMs can write a large fraction of all the tedious code you’ll ever need to write. And most code on most projects is tedious.

I've been writing code for over 30 years and I can't recall ever writing "tedious code". I don't know what this even means. Code, by definition, should not be tedious. At any layer of the stack, code should solve non-tedious problems. The whole point of code is to avoid tedium.

Most code, most projects? I haven't seen this and doubt it's even close to true - if it is God help us. If you write tedious code, find another place to work or another career.

> Sometimes, gnarly stuff needs doing. But you don’t wanna do it. So you refactor unit tests, soothing yourself with the lie that you’re doing real work.

Seriously who kills time by refactoring unit tests? Is this projection by the author?

> But an LLM can be told to go refactor all your unit tests.

Wtaf?? The unit tests are what stands between the blind ambitions of a statistical model and correct code. Handing over tests to an LLM? One staggers.

Tests represent part of that problem definition and solution. They're integral to the code. They foster and deepen understanding - not to be subject to the musings of statistical process, unless those musings serve as a dialectic.

> If you can’t metabolize the boring, repetitive code an LLM generates: skills issue! How are you handling the chaos human developers turn out on a deadline?

Answer: Slow the F down! Chaos and programming don't belong. Managers who drive their teams like this are bad managers.

> If hallucination matters to you, your programming language has let you down.

The author seems to think that programming is about producing code. Producing code that compiles is not a problem. Producing correct and coherent solutions to problems that need to be solved is a problem. Hallucinations aside, how will you know that generated code is something to keep or reject unless you have some understanding of what the code should do before you see it?

> Does an intern cost $20/month? Because that’s what Cursor.ai costs.

Squee! Code for all my friends!

> but it’s bad at rust

No, it's bad at understanding. And so are humans, initially. But it's our job to build and deepen understanding and we use code to facilitate that.

> Professional software developers are in the business of solving practical problems for people with code.

Correct.

> [LLMs] devour schlep, and clear a path to the important stuff, where your judgement and values really matter.

This begs the question, who defines what's important? It sounds like the author agrees that it's us, not the model. I agree this is a useful method. It's like any code review - it sharpens the reader no matter the code quality.

> As a mid-late career coder, I’ve come to appreciate mediocrity.

How cool and nonchalant what a rebel he says the opposite of everyone what a baddie!

I think the author means "appreciate naivety", meaning, a first pass that's good enough is good enough - there's no need to go further. I'll concede this, but it's a concession and not something to boast about. O...