Your AI-built app works. That's not the same as ready.

You described what you wanted, and an AI tool built it. It has screens, it signs people in, it saves data. A year ago that would have taken a team months. Now you are about to put real users, real data or real money into it, and something feels less certain. This post is about that gap: what vibe coding does well, where the evidence says it stops, and how to tell which side of the line your app is on.

What vibe coding is good at

Andrej Karpathy named it in February 2025: you "fully give in to the vibes" and "forget that the code even exists." In the same post he said it was "not too bad for throwaway weekend projects" (Simon Willison has a good write-up). Collins Dictionary made it its word of the year.

It earned that. It is the fastest way yet to test whether people want something, and the clearest way to show a developer what you mean. Jason Lemkin of SaaStr built several production apps this way and summed it up as "vibe coding works, but not the way it's marketed." A working prototype is the best specification you will ever write. Keep it.

Where the evidence says it falls short

The tools are good at code that runs. They are much less reliable at code that is safe.

• Security. Veracode tested more than 100 AI models on 80 coding tasks and found security flaws from the OWASP Top 10 in 45% of cases (July 2025). Its 2026 follow-up found the security pass rate stuck at 56%, while the code compiled almost every time. Its summary: models are "getting smarter but not safer."
• Apps already live. Escape scanned about 1,400 vibe-coded apps and found more than 2,000 highly critical vulnerabilities, over 400 exposed secrets and 175 cases of exposed personal data.
• Trust. In the Stack Overflow 2025 survey, 46% of developers said they distrust AI's accuracy, and 66% named the same top frustration: answers that are "almost right, but not quite."
• Speed. In a controlled study by METR, experienced developers using early-2025 tools were 19% slower, while believing they were about 20% faster. A 2026 update suggests newer tools help a little, on evidence METR itself calls weak.
• Upkeep. GitClear's analysis of 211 million changed lines found that in 2024, for the first time, copy-pasted code outnumbered code that was tidied and reused. That is the code someone has to maintain later.

What it looks like when it goes wrong

• Open databases. A researcher checked 1,645 apps built with Lovable and found 170 whose data could be read or changed without signing in, including names, emails and payment records. They could mark an account as paid without paying (CVE-2025-48757, 2025).
• Keys in the browser. In February 2026, Wiz found that Moltbook, whose founder had posted "I didn't write a single line of code", exposed 1.5 million API tokens and private messages through a key left in the web page.
• Sign-in that wasn't. Wiz also found that apps built on Base44 let anyone create a verified account in a private app (July 2025). The platform fixed it within a day, but every app on it was exposed until then.
• Deleted production data. In July 2025 a Replit agent deleted SaaStr's production database during a code freeze. In April 2026 a coding agent at PocketOS wiped the database and its backups, because the backups sat on the same volume.

None of these needed a clever attacker. Each one was a default nobody checked.

The six places AI-built apps break

1. Who can see what. Many AI tools build on Supabase, whose own docs say to enable row-level security on every exposed table; without it, anyone can read and write the table. The app looks fine from the inside, which is why this is missed.
2. Secret keys. The same docs say "never use a secret key in the browser." AI tools put keys wherever the code works first.
3. Payments. Stripe's documentation says to verify every webhook signature, expect the same event more than once, and expect retries for up to three days, in any order. A demo never sees any of that. Real customers do.
4. Production and backups. A test database, a live database, and a backup you have actually restored from. The incidents above happened where those were the same thing.
5. Knowing when it breaks. One founder on Hacker News broke their ad tracking: "No alert, nothing in the logs." Without monitoring, your customers are the alert.
6. The last 30%. Addy Osmani calls it the 70% problem: AI gets you most of the way fast, and the rest becomes "whack-a-mole with code you don't fully understand." Fix one thing, and something fixed last week breaks.

If your app handles health records, children's data or payments, add the rules your industry sets. Those are not in any prompt.

Signs you have reached the limit

• Each fix breaks something that used to work.
• You are spending more on credits than on progress.
• You can't say who is able to read your customers' data.
• Keys or passwords appear anywhere in the app's code.
• You have never restored a backup.
• Real users, real data or real money arrive next month.

What to do next

Don't throw the prototype away. It shows what you want more clearly than any document. What it needs is a senior engineer to read what was built, sort what to keep from what to rebuild, and fix the parts that matter before customers find them.

That is what our App Review does: a free assessment of your app, ending in a written report, a prioritised fix list and a quote to take it further, based on scope. More on how we help with AI-built apps.