"Vibe coding," the practice of describing what you want to an AI model and iterating on what it produces instead of writing code by hand, went from a niche term to mainstream fast enough that Google's own recap of its AI Agents Intensive course put enrollment at 353,000 people. That is not a hobbyist number. It is a sign the practice has moved well past early adopters and into how a meaningful share of software is now getting built, including inside businesses that are not primarily software companies.
The term gets used loosely enough that it is worth separating what it is actually good for from what it is being asked to do anyway.
Where it holds up
For a prototype, an internal tool nobody outside the team will ever see, or a first pass at a feature to see if an idea is worth building properly, vibe coding is close to the best case for AI-assisted work. The cost of being wrong is low. Iteration speed matters more than architecture. A non-engineer on a marketing or ops team building a working internal dashboard in an afternoon, something that used to require filing a ticket and waiting on engineering, is a genuine capability shift, not a novelty.
This is also where most of the loudest success stories genuinely come from, and they are not exaggerated. The gap is what happens after that first version needs to become something other people depend on.
Where it breaks
The same speed that makes vibe coding good for prototypes is what makes it risky for anything that touches real data, real customers, or real money. A model iterating toward "looks right" optimizes for the thing it can check, which is whether the output behaves correctly on the cases you tried. It has no way to know about the edge case you did not think to test, the security assumption nobody stated out loud, or the reason a previous engineer wrote something the slower, uglier way on purpose.
None of that shows up as a visible bug. It shows up later, as a support ticket, a data leak, or a scaling problem, once the tool has already been trusted with something that mattered.
The distinction that actually matters
The line that actually matters is whether a human with the relevant judgment reviewed what shipped, and whether the process included the parts vibe coding tends to skip: input validation, an authentication check that was actually tested, a look at what happens when the happy path fails.
A team can vibe code the first draft of almost anything and still ship something solid, provided that draft goes through the same review a human-written first draft would get before anything depends on it. Treating "the model did not complain" as equivalent to "this is done" is the actual failure mode, not using the technique itself.
The rule worth keeping
Vibe coding is a legitimate way to get from nothing to a working first version faster than typing every line by hand, and the size of that Google course is real evidence of how far that has already spread. It is not a substitute for the review step that turns a first version into something safe to depend on. The teams getting burned by it are usually skipping the part that comes after, not avoiding the technique itself.