In this context, let's define vibe coding as writing code with LLMs without reading the code. That's very different from writing code with LLMs but reviewing it carefully and improving it with further prompts or manual edits.
While I don't use vibe coding for production, it's still extremely useful.
It's a nice planning tool. Instead of typing up a plan, speed-running a task with a few prompts can give a good idea of feasibility and complexity before writing production code.
I use it almost daily to write one-off code for testing and analysis.
It's great for prototyping: vibe coding a feature lets you see if it's worth building. For product decisions, a screen recording of a vibe-coded feature can be more useful than a typed-out plan.
As a general rule of thumb, I tend to vibe code in cases where it's obvious if the code works or not (e.g., this website) and it's not a problem if it doesn't. In those cases, it's safe to skip reading the code — just see if it works and prompt the LLM to fix it otherwise.
In cases where it isn't obvious if the LLM-produced code works as expected and the consequences would be dire if it doesn't, I carefully review LLM-generated code and improve it with further prompts. Most high-traffic production software fits this definition.
One could argue that thorough testing can show if the code works without reading it. While testing is important, I have not yet seen a test setup so good that one can skip the step of understanding the code and just trust that it works. I'm open to changing my mind — we'll see if such a setup can be created. For now, I continue to ship only code that I have carefully reviewed and that I understand.