Imagine this. You build something in an afternoon, show it to a customer, and they like what they see.
“Looks good. Can we use it tomorrow?”
Built Today. Deployed Tomorrow. Broken Next Week.
It goes live the next day. A week later, something breaks. People are now relying on a prototype that still needed work.
This is where I think the conversation around vibe coding needs to go.
There is value in showing an idea
I’ve seen so many posts dismissing vibe coding. I understand the engineering concern. I also think rapid prototyping has a useful place.
Requirements gathering is a good example. The business wants to see the product. The consultant is trying to explain it through Excel or PowerPoint wireframes, and the idea doesn’t always come across.
AI can help build quick UI mock-ups and proofs of concept. Give the business something to click through, and they can say, “We need another step here,” or “That isn’t how we work.” That helps both sides understand what needs to be built.
It’s like a 3D-printed mock-up. You can hold it, check the fit, and show someone what you mean. You still need to check whether it can do the job of the finished part.
Both sides have a part to play
If you built it, don’t oversell it. Explain what works, what you haven’t checked, and what needs more engineering. A customer may see a finished screen and assume everything behind it is ready.
The customer has a responsibility too. Once those limits are clear, they need to allow time and money for testing and support. The builder has to explain what’s needed; customers cannot be expected to spot every technical problem.
And both need to think about the people who will use it and deal with the problems if it breaks.
The same goes for established products
I also find the blanket criticism unfair. An established product can have years of patches, workarounds, and things nobody wants to touch.
A patch can be a sensible fix. What matters is whether someone understands the problem, checks the fix, and takes responsibility afterward. That should apply to everyone building software.
So what do we do when they want it tomorrow?
With shorts, reels, and so much available in minutes, it’s easy to expect the same speed from a full product. We need to agree on what can responsibly be used tomorrow and what still needs work.
Product teams and engineers need to adapt too. AI tools and what we can do with them keep changing. We need to keep learning and rethink how we build, while taking responsibility for what we deliver.
I think there is weight to both sides. We can take the engineering concerns seriously and still appreciate what a prototype helps people do. Calling the whole thing useless does very little to improve it.
Build it quickly. Be honest about what it’s ready for.