I keep seeing "vibe coding" used as the catch-all term for every facet of AI-assisted software development. But it really only covers a specific, narrow part of what is changing.
Vibe coding is one thing you can do with these tools. What I'm spending most of my time on is something different: figuring out how the entire process of building software needs to change. It's software and systems engineering, and the same old-school principles apply[1].
There is a new SDLC being figured out in real-time and the parameters are shifting rapidly. Faster coding means you also need to uplift how you generate, specify, deliver, test, deploy, debug, and improve features.
When Andrej Karpathy coined the term "vibe coding" he said it was to "fully give in to the vibes... and forget that the code even exists". That's extended to imply a laissez-faire attitude toward the code and how you get the outcome. In many contexts, vibe coding has a connotation of being lazy.
To be fair, there is some truth in it. You can vibe code a pretty good-looking app now. There are other cases like porting, prototyping, upgrades, and refactoring where a pure vibe coded approach can be very effective.
But if you're buying Claude and Codex licenses and asking your engineering team to simply "vibe code a lot", you're in for a surprise (and not a good one). You cannot vibe code the systemic organizational changes needed to get the most out of this new technology. This is a genuine and exciting engineering challenge. For those who are mourning the loss of coding[2], I hope it's one they can grab on to.