This is just fundamentally not the case most of the time. LLMs guess where you're going, but so often what they produce is a "similar looking" non sequitur relative to the lines above it. It guesses, and sometimes that guess is good, but as often, or more, it's not.

The suggestion "think in interfaces" is fine; if you spell out enough context in comments, the LLM may be able to guess more accurately, but in spelling out that much context for it, you've likely already done the mental exercise of the implementation.

Also baffled by "wrong or suboptimal," I don't think I've ever seen an LLM come up with a better solution.

Maybe it's the domain I work in, or the languages I use, but the 20 lines the LLM comes up with is almost certainly wrong.

I agree with the last two sentences but simultaneously think that starting to defacto believe you cannot have an equal or better solution compared to the AI is the start of atrophy of those skills.

> ...and letting go of that urge.

What urge? The urge to understand what the software you're about to build upon is doing? If so, uh... no. No thanks.

I've seen some proponents of these code-generation machines say things like "You don't check the output of your optimizing compiler, so why check the output of Claude/Devon/whatever?". The problem with this analogy is that the output from mainstream optimizing compilers is very nearly always correct. It may be notably worse than hand-generated output, but it's nearly never wrong. Not even the most rabid proponent will claim the same of today's output from these code-generation machines.

So, when these machines emit code, I will inevitably have to switch from "designing and implementing my software system" mode into "reading and understanding someone else's code" mode. Some folks may be actually be able to do this context-shuffling quickly and easily. I am not one of those people. The results from those studies from a while back that found that folks take something like a quarter-hour to really get back into the groove when interrupted while doing a technical task suggest that not that many folks are able to do this.

> Think in interfaces...

Like has been said already, you don't tend to get the right interface until you've attempted to use it with a bunch of client code. "Take a good, educated stab at it and refine it as the client implementations reveal problems in your design." is the way you're going to go for all but the most well-known problems. (And if your problem is that well-known, why are you writing more than a handful of lines solving that problem again? Why haven't you bundled up the solution to that problem in a library already?)

> Successive rendering, not one-shot.

Yes, like nearly all problem-solving, most programming is and always has been an iterative process. One rarely gets things right on the first try.

> The hard truth here is in accepting that the 20 lines in your head were probably wrong, or suboptimal, and letting go of that urge.

Maybe, but the dogshit that Cursor generates is definitely wrong so frankly if it's gonna be my name on the PR then I want it to me my wrong code not hide behind some automated tool

> Think in interfaces, not implementations

In my experience you likely won't know if you've designed the right interface until you successfully implement the solution. Trying to design the perfect interface upfront is almost guaranteed to take longer than just building the thing