“Vibe coding” — describing what you want and iterating with an AI assistant until it feels right, without deliberately engineering every piece yourself — has earned both hype and dismissal it doesn’t fully deserve. It’s neither a revolution nor a joke. It’s a mode of building, and like any mode, it’s excellent for some things and genuinely dangerous for others.
Where it’s a real superpower
Prototypes, throwaway scripts, exploring whether an idea even works before investing real engineering time, internal tools with a small, forgiving blast radius if something’s slightly off. In all of these cases, speed of iteration matters more than rigour, and the cost of a subtle bug is low — someone notices, someone fixes it, nobody’s business breaks. This is where vibe coding is a legitimate, valuable way to work, not a shortcut to feel guilty about.
Where it becomes a liability
Anything touching money, personal data, authentication, or anything that needs to keep working correctly for years, maintained by people who weren’t in the room when it was built. Code produced by iterating on “does this feel right” rather than “do I understand exactly what this does and why” tends to carry invisible assumptions nobody explicitly decided on — and those assumptions surface later, usually at the worst possible time, usually in production.
The failure mode isn’t that the AI wrote bad code. It’s that nobody on the team can fully explain why it works, which means nobody can confidently tell you when it will stop working.
The actual test
Before shipping something built this way to production, ask: can someone on the team explain what this does and why, in detail, without re-reading it first? Has anyone actually reviewed the logic, not just confirmed it runs? Is the blast radius genuinely small if it’s subtly wrong? If the honest answers are no, no, and no, that’s not a vibe-coding problem — it’s a decision to skip engineering on something that needed it.
Our actual take
Vibe code the prototype. Engineer the product. The two aren’t in conflict as long as you’re honest with yourself about which one you’re currently doing — the trouble only starts when a fast, exploratory prototype quietly becomes the production system without anyone deciding that on purpose.
If you’ve got something that started as a quick prototype and is now quietly running a real part of your business, it might be worth a proper review before it becomes a bigger problem than it needs to be.