Programming

And by the fact of the longest part of programming being digesting code you didn’t write, in effect you’ve taken a long-cut and could have written it yourself faster.

The conclusion doesn't follow from the premise. Just because an LLM may need to tweak something doesn't mean it necessarily would have been faster to do it manually. Humans need to tweak things all the time, it's called revising, and it's an important part of improving code.

But I wouldn't claim that using LLMs is always faster than coding manually, nor the opposite. There are times when LLMs do slow me down. It's important to recognize when that risk is high.

But I'm quite certain that for prototyping specifically, i.e. building a desired UX to get a feel for it and experiment with whether the ideas are sound, LLMs are faster.

So you don’t get a valid answer, you just get a convincing one.

That's why you shouldn't trust an LLM's reasoning; it doesn't actually have sound reasoning abilities. You shouldn't rely on an LLM to reason about problems, you should use it to generate code quickly when the reasoning has either already been done by a human and/or it exists in its training set. LLMs are closer to a search engine than a problem solver.

When asking the person why they did it...

I see no reason why this process is mutually exclusive with using an LLM. You can use both human reasoning and LLM code generation.

No disagreement from me about trivial changes. I make them in my editor all the time, assuming I even have an editor in front of me. Sometimes I don't, and it's possible to use dictation to an LLM to make trivial changes without touching a keyboard.

That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.

Not convincing. I've given my reasons