What a demo is exempt from that production isn't
A demo doesn't need to handle the data it wasn't shown, survive a dependency's breaking change six months later, or be debuggable by someone other than the person who built it. Production software needs all three, and vibe-coded output optimised purely for "looks right in the demo" often satisfies none of them by default.
This isn't a criticism of the practice — it's a scope boundary. Treating a successful demo as evidence the approach is production-ready is the actual mistake, not the vibe coding itself.
The honest transition point
The moment a prototype is being considered for real users or real data, the standard has to shift to specified requirements, independent review, and genuine test coverage — the full discipline covered elsewhere in this pillar. Treat that transition explicitly as a decision point, not something that happens by accidental momentum.
A demo proves an idea works. It says nothing about whether the implementation is safe to depend on — that's a different question, asked a different way.MNB Software Engineering Practice
Key actions
- Use vibe coding deliberately for prototypes, not as a default production method
- Name the explicit transition point before a prototype touches real data
- Re-specify requirements and add independent review at that transition
- Never treat a working demo as evidence of production readiness