I kinda of agree, but still believe that writing most of the critical(!) code yourself has long term benefits. IME the initial mental model hardly survives contact with reality and all those little micro decisions that come up during implementation are good to do on your own and have in your own head instead of being buried in an LLM managed decision record where no human ever ventures.
It all depends of course where the code sits between "low level mission critical code" and "high level throw-away code". every non-trivial project has code across that entire range.
E.g. the lower level the code, the more I want to get directly involved, and that may mean typing each line manually to get that code directly into my head (IME for that purpose, writing is better than reading - have that manually written code reviewed by LLM instead).
Of course that only works if you don't have a manager breathing down your neck who insists on prioritising implementation speed over quality ;)
Also you should try assembly coding with modern (non-LLM) tooling, it feels incredibly more productive than with the primitive tools on slow machines of the past.
Also:
> software engineers can focus on data structures, software architecture and algorithms.
Come on, this is was already "normal" decades before LLMs, that's why an entire zoo of high level languages was created which allow to describe a solution in a highly abstract (yet still precise) way. Replacing this high level problem specification in a programming language with a "sloppy" human language specification is arguably even a step back.
(also tbf, I'm writing this comment while sitting in a cafe while the LLM at home is busy coding a GL mocking library ;) (which is exactly the boring type of throwaway code which should be automated)