One thing I think people are underestimating about vibe coding: the problem is the prompt, not the AI.
I fully vibe coded Log My Lift. See my previous post on it. And honestly, the first version was impressive. The app worked. It looked good. Making it responsive was just asking it to. Workout tracking, charts, dark mode – everything you’d expect from a real product. Adding auth and templates, just more simple prompts.
But under the surface, there were problems most non-engineers would never notice. The frontend architecture became one giant file (possibly because this was an experiment to explicitly build it with 0 dependencies). Parts of the API weren’t properly protected. The app was built fast, but not necessarily built safely or maintainably.
Here’s the important part though:
The AI wasn’t “bad” at coding. In fact, it was incredibly capable. But having vibe coded for a while, I knew exactly what it has missed. I knew just by a simple glance at the files. When I later asked it to:
improve the architecture
modularize the frontend
tighten security
harden the API
…it did a pretty solid job.
That’s what makes vibe coding both exciting and dangerous. AI usually does exactly what you ask. Not what you forgot to ask. Right now AI feels less like a junior developer and more like an insanely fast developer with infinite stamina, but zero assumptions about your real intent. If you ask for “a workout tracker,” you’ll get a workout tracker. If you ask for “a secure, maintainable, scalable workout tracker,” you’ll get a much better system.
So if you’re vibe coding apps:
Ask about architecture
Ask about security
Ask about maintainability
Ask what could go wrong
Ask the AI to critique its own design
The difference between a demo and a real product is often just a few prompts.