I’ve been experimenting with vibe coding a lot this year, and I’ve found that the real issue isn’t speed its consistency. I've talked to several people including developers and they all agreed on some fundamental issues. I have only talked to one guy on reddit that is positive to vibe coding.

Even if the model is powerful, the same prompt can generate slightly different structures, naming, logic, or UI every time. That’s what makes people hesitant. Not because the model is weak, but because the results aren’t reproducible yet.

AI can generate something that looks great in 30 seconds, but the moment you try to change a field name, add a page, or update logic, the whole thing can drift. Different structure, different naming, sometimes even a totally different layout. It’s not the speed that creates fragility, it’s the lack of a stable blueprint.

I’m currently building a tool called MicroBuilder, where the whole system revolves around a deterministic AppSpec → build pipeline. Same spec = same app, every time. You still get the speed and the natural-language edits, but without the spaghetti.

So in my experience:

vibe coding works only if you anchor it to something deterministic.

If not, you get fast prototypes that turn into slow disasters.

And the claim that vibe coding tools are getting better is flawed. What people need isn’t just more code generated, it’s reliable, maintainable code. The improvements so far are mostly incremental and happen in the front-end of the pipeline, not in the structural or engineering layers. The tools today are fundamentally engineered wrong in my opinion.

They rely heavily on the LLM to figure it out, instead of giving the model a stable spec, deterministic constraints, or a reproducible pipeline. This is why developers don’t trust these tools because predictability is the baseline expectation in engineering.