I agree it's a skill, but I actually think hear this analogy a lot and think it's not a great one
A feedback loop with an LLM is useful for refinement of ideas and speeding up common tasks. I really even think it can be a massive productivity boost for one of the most common professional dev tasks with the right tooling. I work a lot of mercenary gigs and need to learn new languages all the time, and something like phind.com is great for giving me basic stuff that works in a language whose idioms I don't know, and the fact that it cites its sources and gives me links means I can deal with it being wrong sometimes, and also drill down and learn more when appropriate more easily
However, LLMs are super not like compilers. They simply do not create reliable simplifications in the same way. A higher level language creates a permanent, reliable, and transferable reduction in complexity for the programmer, and this only works because of that reliability. If I write a function in scala, it probably has a more complicated equivalent in JVM bytecode, but it works the same every time and the higher-order abstraction is semantically equivalent and I can compose it with other functions and decompose it into its constituent parts reliably without changing the meaning. Programming languages can be direct translations of each other in a way that adding the fuzziness of natural language makes it basically impossible to. An abstraction in a language can be used in place of the complex underlying reality, and even modified to fit new situations predictably and reliably without drastic risk of not working the same way. This reliability also means that the simplification has compounding returns, as it's easier to reason about and expand on for some future maintainer or even my future self.
LLMs for code generation, at least in their current form, lack all these important properties. The code they generate is a fuzzy guess rather than a one-to-one translation. Often it's a good guess! But even when it is, it's generating code that's no more abstract than needed to be written before, so putting it into your codebase still gives you just as much additional complexity to take into account when expanding on it as before. Maybe the LLM can help with that, maybe not. Asking an LLM to solve a problem in one case can fail to transfer to another one in unpredictable ways.
You also aren't able to use it to make permanent architectural simplifications recursively. We can't for example save a series of simple english instructions instead of the code that's generated, then treat that as a moving piece we can recombine by piping that into another instruction to write a program, etc. This would also increase the cost of computing your program significantly obviously, but that's actually a place where, well, not a compiler but an interpreter is a decent analogy. My main concern with LLMs being deployed by developers en masse is kind of already happening, but it predates LLMs. I notice that codebases where people have used certain IDEs or other code generation tools proliferate a bunch of unnecessary and hard to maintain complexity in codebases, because the programmer using the tools got used to just "autogenerating a bunch of boilerplate" which is fine in a vacuum but accumulates a ton of technical and maintainability debt really fast if you're not actively mindful of it and taking steps in your workflow to prevent it, like having a refinement and refactoring phase in your feedback loop
I think LLMs are useful tools and can help programmers a lot, and even may lead to "barefoot programmers" embedded in local community needs, which I love. I hear the analogy to compilers a lot and I think it's a bad one, managing to miss most of what's good about compilers while also misunderstanding the benefits and pitfalls of generative models