[dead]
1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved.
2. Where exactly is the skill to know good code from bad code supposed to come from? I hear this take a lot I don't know any serious engineer that can honestly say that they can recognize good code from bad code without spending time actually writing code. It's makes the people asking for this look like that meme comic about the dog demanding you play fetch but not take the ball away. "No code! Only review!" You don't get one without the other.
Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Also Teaches you how to convert procedures into analytic solutions into numerical solutions aka a single function that gives you an answer through determining the indeterminate of an inductive reasoning (converting a series, procedure or recursive function into an equation that gives you an answer instead of iterating and being dumb.) Networking. (error checking techniques, P2P stuff) Compilers. (Dragon book.) Math. Linear Algebra. (Rocket science) Abstract Algebra (Crypto stuff, compression) Theory of Equations (functional programming). Statistics (very helpful). Geometry. (Proofs).
Taking all these classes makes you smart and a good programmer. "Programming" without them means you're... well. Hard to talk to.
I don't think you need to write any code to be a good programmer. IMHO.
Also again, this logic only works on absolute greenfield project. If you write enterprise code in large organizations, you also have to consider the established architecture and patterns of the code-base. There's no book or usually cohesive documentation to that. There's a reason a lot of devs aren't considered fully on-boarded until after a year.
If you leverage the LLM to write the code for you. Then you never learn about your own codebase. Thus you cannot preform good code review. Which again is why I say reviewing code while never writing code is a paradox statement. You don't have the skills to do the former without doing the latter.
Even if you're take was that typing code into a keyboard was never the main part of your job then the question is ok what is it? And if the answer was being an architect then I ask you. How can you know what code patterns work for this specific business need when you don't write code?
(i.e. I don't think that's your honest opinion and you're just trolling)