When an AI writes you a function, you get exactly one thing: code that looks plausible. You don't get a guarantee it works. Most of the time it runs, most of the time it does roughly what you asked, and the gap between “most of the time” and “every time” is where vibe-coded apps quietly fall apart. The fix isn't a cleverer prompt. It's proof.
This is the single most important idea separating a prototype that demos well from software that survives real users, and almost nobody explains it to non-technical founders. So here it is.
01Looks right, runs wrong
An AI model generates code by predicting what plausible code looks like. That is genuinely useful. It's why you can describe a feature in plain English and get something working back. But “plausible” and “correct” are not the same thing. The model has no way to run the code, watch it fail, and notice it was wrong. It hands you its best guess and moves on.
Most of the time the guess is fine. The trouble is the rest of the time. A function that handles the happy path but mishandles an empty list. An auth check that's right for the logged-in case and wrong for the logged-out one. A payment flow that works when the card succeeds and double-charges when the network hiccups. Every one of those looks correct in the chat window. You only find out it isn't when a real user hits the case the demo never did, which is exactly the pattern behind most apps that break with real users.
02What a test actually buys you
A test is just a small, separate piece of code that states what the answer should be. Give it the input 2 + 2 and it insists the result is 4. If the code produces 5, the test fails, loudly and immediately, before a single user is involved.
That sounds obvious, but it changes the entire economics of AI-written code. Without a test, “is this correct?” is a question only a human reading the code can answer, and most founders can't read the code. With a test, correctness becomes a button you can press. The machine can press it too, over and over, in a second, for free.
That last point is the one that unlocks everything else.
03Generate many, keep what passes
Here's the shift. If checking correctness is just running a test, then a single AI answer is no longer the best you can do. You can ask the model for an implementation, run the tests, and when it fails, feed the exact error back and ask again. And again. You can generate ten attempts, score each by how many tests it passes, keep the strongest, and explore from there until something passes everything.
This is no longer hypothetical. An open-source tool called Unvibe (a fitting name for us to write about) does exactly this for Python: you mark a function as AI-generated, write tests describing how it should behave, and it searches across many generated implementations, feeding test failures back to the model, until it lands on one that passes every test. The output isn't “the AI's first guess.” It's “the one attempt out of dozens that actually proved itself.”
The idea isn't niche, either. The same loop (generate candidates, score them against a hard check, keep the winners, repeat) is how DeepMind's FunSearch discovered new results in mathematics, and how their geometry systems reached medal-level performance at the International Mathematical Olympiad. Raw generation gets you a guess. Generation plus a scoring function that can't be fooled gets you something you can rely on.
04What this means for your app
You don't need to run a search algorithm over your own codebase. The takeaway is simpler and it applies whether you build in Lovable, Bolt, Cursor, or Claude:
The parts of your app that must not break need a test that proves they don't. Not all of it (that's a job, not a weekend). But the handful of flows where being wrong actually costs you: login and access control, anything touching money, anything that writes or deletes user data. Those deserve a check that runs every time, not a one-time “it worked when I tried it.”
If you're comfortable in the tool, you can ask the AI itself to write the tests: describe the behavior you expect, including the edge cases (“what happens when the list is empty? when the user is logged out? when the payment fails halfway?”), and have it generate tests before it generates the fix. Then make it keep going until the tests are green. That one habit turns the model from a confident guesser into something closer to the generate-and-verify loop the serious tools use.
- AI code looks right; that's not the same as being right.
- A test turns “is it correct?” into a button you can press.
- The best tools press that button many times and keep only what passes.
- Your money, auth, and data flows are where a test pays for itself.
→If you're not sure where you stand
Most vibe-coded apps we see have zero tests and a few flows that absolutely cannot be wrong, usually the exact flows nobody verified. That's not a failure of the founder; it's a gap nobody told them to mind. Finding those flows, and saying plainly which ones are one bad input away from breaking, is most of what a real audit does.
If you want to know which parts of your app would survive a test and which would fall over, get an audit. We'll read the code, find the flows that aren't verified, and tell you exactly where being “probably fine” is about to cost you a customer.