Vibe Coding
Vibe coding is building software by describing what you want to an AI coding tool and accepting the code it generates, with little or no reading of the code itself. The term arrived in early 2025 and the practice spread quickly, because the tools are good: a working prototype of a web or mobile application can exist within hours of the idea.
In Detail
What it produces. A vibe-coded application usually does what it was asked to do on the path the author tried. The interface exists, the main screens work, and the demonstration lands. That is the strength of the approach, and it is real.
What it leaves out. What the author did not ask for tends not to exist. Tests, error handling for the paths nobody tried, a data model that survives the second feature, access control, logging, backups, a deployment that someone other than the author can repeat, and the structure that lets a second engineer change one part without breaking another. None of this is visible from the demonstration, which is why the gap is usually found when the application is already in use.
What to do with one. The useful question is not whether the application should have been built this way but what it needs now. A development review reads the application as it is, identifies the changes it needs to be safe, maintainable and operable, and puts them in order. From there the work is either a defined first outcome at a fixed cost or a monthly engagement alongside your own team, with milestone billing available once the application has been audited. Adaca's development review is a once-off AUD 10,000 and ends in a recommendations report; How We Charge sets out the rest.
Common Questions
Is vibe coding bad?
No. It is a fast way to find out whether an idea works, and many applications should start that way. The risk is in treating the prototype as the product.
Can a vibe-coded app be made production-ready?
Usually, yes. A review decides whether it is reworked in place or rebuilt on the same design, and the answer depends on the data model and the code's structure more than on its size.
How do I know if my app has these gaps?
If nobody other than the person who built it can deploy, change or recover it, it has them.
Last updated