TL;DR:
The phrase “vibe coding” trivializes what serious AI-assisted software development actually is. In real projects, the work still includes PRDs, planning, architecture, UX decisions, implementation, review, debugging, and iteration. What changed is not the need for rigor, but where rigor matters most. I am not “vibe coding”; I am orchestrating a system of AI tools and agents the way a conductor trains an orchestra toward a coherent performance.
The term “vibe coding” is catchy, but it is also deeply misleading.
It makes AI-assisted software creation sound like a hazy mix of prompts, intuition, and accidental success. It suggests that the work is casual. Improvised. Almost unserious. That may describe some experiments, but it does not describe what actually happens in any real project that must become stable, usable, and shippable.
In practice, the software process did not disappear. It just changed shape.
You still need a PRD. You still need architecture. You still need implementation plans, sequencing, review loops, debugging discipline, UX judgment, and quality control. The difference is that AI has shifted where the most important work lives. Less value sits in typing every line by hand. More value sits in defining the problem clearly, decomposing it well, directing execution, and knowing when the output is wrong even if the code technically runs.
That is why I think the phrase needs to die.
Across my own project chats, the pattern has been obvious. The moments that went badly were not failures of “vibe.” They were failures of structure. When I let AI-driven implementation run ahead of planning, complexity piled up quickly. Intent drifted. The codebase expanded, but clarity did not. In that mode, AI does not create momentum. It accelerates chaos faster than progress.
One of the clearest examples came in a project I called One Desktop Client To Rule Them All. I reached a point where I had to stop, reset, and rebuild the process itself. Instead of layering more instructions on top of an increasingly muddy foundation, I went back to fundamentals: PRD first, then phase-based instruction sets, then clear orchestration of agents, then ongoing code review. That was not “vibe coding.” That was disciplined product and engineering leadership.
The lesson was simple: AI makes processes more important, not less.
The same thing showed up in UX work. In several chats, I ran into the same frustrating pattern: the code could be correct, yet the product still felt wrong. A modal could function. A project editor could technically work. A drag-and-drop interface could be wired properly. And yet the experience would still lack hierarchy, clarity, restraint, and confidence. The machine had solved the implementation problem without solving the actual product problem.
Trying to fix that purely through code was expensive in time and attention. So the workflow changed. Instead of coding first and hoping the UX would emerge, I started by mocking first and implementing second. I used AI to prototype the visual and interaction intent before asking it to generate the interface. Once the design direction was explicit, implementation improved dramatically.
Again, that is not “vibe coding.” That is process maturity.
More specifically, it is orchestration.
The best metaphor I have found is not a hacker in a flow state. It is a conductor standing in front of an orchestra.
That is what this work feels like when done seriously. I am not sitting back and hoping the music somehow appears. I am directing sections. I am setting the tempo. I am cueing entrances. I am stopping the performance when something sounds off. I am asking one section to soften, another to lead, and a third to repeat the same passage until timing and tone align. Some models are fast but careless. Some are structured but rigid. Some are brilliant in narrow windows and unreliable outside them. My job is to know which one should play when, under what constraints, and toward what outcome.
I’m not fighting the model. I’m orchestrating it.
And the important shift in this new reality is exactly that: the center of gravity has moved. The scarce skill is no longer just manual code production. It is a specification. Judgment. Review. Decomposition. System memory. UX taste. Error detection. Recovery. Sequencing. Leadership.
That is real work. In many cases, it is harder work than simply writing the code yourself, because you are now responsible for both the destination and the behavior of the system producing the output. You have to know what “good” looks like before the machine does. You have to recognize drift early. You have to keep multiple moving parts aligned. You have to train the process as you build the product.
So no, I do not think I am “vibe coding.”
I think I am training a new orchestra.
I am teaching a collection of fast, imperfect, highly capable musicians how to listen, how to enter, how to stay in time, how to recover when the tempo slips, and how to keep playing toward the same musical idea. The goal is not random generation. The goal is coordinated execution. And the hope is that, after enough direction, repetition, correction, and refinement, we perform beautiful symphonies together.
We need a better term for that.
Call it orchestrated development. Call it AI-directed software development. Call it conducted coding. I do not particularly care which phrase wins.
But “vibe coding” is not an accurate description of what is really happening, and the longer we use it, the more it obscures the emerging craft rather than describing it.
So yes: vibe should die.
