But you're comparing vibe coding to using a compiler. This is an important comparison but you don't need to use LLMs this way; that's why, I think, senior engineers are more effective with LLMs than juniors.

When coding, a few things are happening. You build a representation of what you want to achieve in your head and translate that to code, aka "typing the code", which is actually a pretty complicated process but certainly not all of the entirety of the software engineering process. Then you review what you wrote and commit.

With LLMs you still maintain steps 1 and 3. you reason about the solution, translate it to English and then let the LLM do the "typing the code". Finally you review the output.

The output review is completely deterministic and you have the opportunity to even tweak the LLM's output to match your mental model. The nondeterministic nature of the LLM isn't super relevant because it just changes how much work you do in this step. At this point it's just like standard coding minus the typing. Ultimately it's still an objective relationship with the compiler. It's very much like how tech leads engineer a system through their teams.

Assuming that you truly understand and own every line of the LLM's output, the model is almost working like a macro.

I agree it can feel like working with a team sometimes, but I wouldn't liken it to a macro. That seems much too idealized.