Vibe coding is great — until launch day. Here's the gap.

I want to say this plainly, because most of what gets written about AI coding tools lands on one of two extremes: either they're a toy that "real developers" shouldn't take seriously, or they're about to replace engineers outright. Neither is what I actually see. What I see is the best thing to happen to small operators in a decade — and a gap in it that nobody's naming honestly. Vibe coding security is that gap, and it's worth talking about without either cheerleading or dunking.

Here's what vibe coding actually did: it took the part of building software that used to require hiring someone, waiting weeks, and paying five figures, and compressed it into an afternoon and a conversation. You describe the app you want in plain English, and Cursor or Claude or Lovable or Bolt hands you something that works, that looks good, that you can click through and show a friend the same day. That's not a small thing. That's an entire class of business owner — the plumber who wants online booking, the boutique that wants a loyalty app, the consultant who wants a client portal — getting access to custom software that used to be priced out of reach. I'm not being diplomatic when I say I think this is genuinely great. I use these tools constantly.

But "great" and "finished" are different claims, and the gap between them is exactly the part that doesn't show up in a demo.

What vibe coding actually optimizes for

These tools are trained on an implicit contract: build what the person in front of me is asking for, as fast and as well as possible. That's the fun half of shipping software — the part where you're deciding what the app does, how it looks, what the user sees and clicks. AI is spectacular at that half. It always was going to be, because that's the half you can describe in a sentence and see the result of in a screenshot.

The other half of shipping software was never fun, and it was never something you described — it's the stuff that only shows up when something goes wrong or someone tries to abuse it. Who's allowed to call this endpoint. Whether one customer can see another customer's data. What happens when a hundred people hit the same page at once instead of one. Whether the backups actually restore. None of that is in the prompt, because none of that occurred to anyone to put in the prompt — it's not part of "what the app does," it's part of "what the app survives." Vibe coding closed the first gap completely. It left the second one exactly where it's always been.

Why "it's just a small app" doesn't exempt you

I hear a version of this a lot: "it's not a big deal, it's just a booking form" or "it's just an internal tool, nobody's attacking that." Scale isn't really the variable that matters here — exposure is. The moment an app takes a signup, stores a customer's information, or sits on the open internet at all, it's a target for the same automated scanning that hits everything else on the internet, regardless of how small your business is. I've written before about the specific shape this takes: no server-side check on who's allowed to do what, no row-level security so any logged-in user can technically reach any other user's row, secrets sitting in code the browser can read, and API responses handing back more than the screen displays. I go through all of that in the security holes AI coding tools leave in every app, and the pattern repeats because the tools aren't broken — they're doing exactly what they were asked to do, and nobody asked for the other half.

Same story on the operational side. No rate limits and no caching means the first real spike of traffic — a post that takes off, a bot that finds your signup form — turns into either a bill you didn't budget for or a crash at the worst possible moment. I walked through that one in what happens the first time your AI-built app gets real traffic. Different symptom, same root cause: the tool built what you asked for, and you didn't know to ask for the part that only matters under load or under attack.

This isn't a knock on vibe coding

I want to be careful here, because it would be easy to read this as "don't use these tools" or "hire an agency instead," and that's not the take. The take is narrower and, I think, more useful: vibe coding solved the expensive half of building software and left the cheap-to-fix-but-easy-to-miss half exactly where it was. That's not a flaw in the tools any more than a table saw having no guard rail is a flaw in the saw — it's a reason to know what the tool doesn't do before you rely on it for something that matters. The honest position on vibe coding security isn't "avoid AI-built apps." It's "know which thirteen things your AI tool never touched, and go check them before a stranger does."

The bridge, not the knock

That's the whole reason the Launch-Ready Audit exists. It's not an argument against building with AI — it's the other half of the process, run once, before launch: all 13 production layers checked — frontend, APIs, data isolation, auth, hosting, rate limits, caching, backups, recovery, and more — with a scorecard, the specific gaps with evidence, and a fix list ranked by what actually bites first. Two of those checks are non-negotiable: if any user can reach another user's data, or if there's no server-side check on who's allowed to do what, the app doesn't ship until that's closed, no matter how good everything else looks.

Your Turn: if you built something with Cursor, Claude, Lovable, or Bolt and you're about to put real customers on it, ask yourself honestly whether you ever discussed the load-bearing half with the tool at all — auth, data isolation, rate limits, recovery. If the answer is "I just described what I wanted it to do," that's not a failure on your part. It's just proof the gap is still there, waiting to be checked before it gets found for you.

See how the Launch-Ready Audit works →

— Kyle Tysvaer, Founder, Insightful Eye Marketing