Earlier quoted context omitted.
The advice isn’t about coding vs managing. What John is saying is to deeply understand why you’re building something, so that you can build it better. If you over focus on the what — the implementation, the language, the approach — you won’t be as good, and your work may be increasingly replaced by AI.
I agree but I think I’d call it the “how” rather than the “what”. You might mean “what tool”, but I also think of “what feature”.
It's still "how". Only on a higher level. For example, instead of placing the form elements exactly and designing them you describe data flow and meta info about the data to be gathered via the form, and how it looks and where elements are placed on various screens happens automatically.
Writing code in a higher level vs. assembler still is coding, but you worry about very different things. Just compared with assembler, since looking back is easier than looking forward. Instead of worrying about (the few) registers and interrupts and in which RAM cells you place what you now think about very different things. It still is programming though, and you still tell the machine "how". Only on a different level.
When you lead a large company instead of working with a machine on the factory floor the work is very different, you still need precision and know "how", only on a different level. Even if you have "underlings" who can think, and you can let them execute the sub tasks you create, you still have to know what you are doing, only on a higher level.