Blog, AI and tools, 7 min read
Vibe coding: what it is good for, and where it quietly costs you
Shipping a product by prompting works better than sceptics expect and worse than the demos suggest. The honest version.
Building software by describing it rather than writing it has gone from a joke to a normal way to start a product in about two years. We build for clients who arrive with something they made this way, so this is written from the repair shop rather than the showroom.
It genuinely works for the first version
Getting a working prototype in a weekend is real. For validating an idea, showing an investor something clickable, or replacing an internal spreadsheet, it is the fastest route there has ever been. If someone tells you it does not work, they have not tried it recently.
The wins are concentrated in a specific place: a small app, a clear scope, a single user type, no sensitive data, no integrations that matter.
Where the cost shows up later
The trouble starts when the prototype succeeds. Then the same codebase has to carry real users, and a few things tend to be true at once.
- Nobody knows why the code is the way it is. Generated code carries no reasoning with it, so the first person who has to change it is reading a stranger.
- Security is usually the gap. Keys in the front end, database rules left open, a login that checks the wrong thing.
- There are no tests, so every change is a gamble.
- The data model was invented on the fly and now three features depend on a shape that was never designed.
None of that is fatal. All of it is cheaper to fix at week four than at month eight with paying customers.
How to use it without paying for it twice
- Treat the generated thing as a prototype, out loud, to yourself. Prototypes are allowed to be thrown away. Products are not.
- Before real users, get someone to look at authentication, database access rules and where your keys live. That review is a few hours and it is the highest value money you will spend.
- Keep the scope small while you are moving fast. The failure mode is not bad code, it is too much of it.
- Write down what the app is supposed to do, in plain sentences, somewhere outside the code. You will need it the first time you hand the project to anyone.
What we usually end up doing
A common job for us is taking something a founder built by prompting and making it safe to grow: tightening the data rules, redoing the parts that touch money or personal data, putting a real design over the top, and leaving the rest alone. That is a much smaller project than a rebuild, and it is usually the right one.
The bad version is the rebuild, and you can avoid it by getting a second pair of eyes on it before you have customers rather than after.