It almost always goes the same way. Someone spends a few evenings building something with Lovable, Bolt, Cursor or plain ChatGPT. It works. The demo runs, the first customer is enthusiastic, and then comes the sentence that changes everything: “Can we go live with this next month?”
At that moment the question shifts from “does it work?” to “will it hold?”. Those are two very different questions.
What “it works” actually means
A prototype proves one thing: that the happy path works. One user, doing exactly what you expect, with clean input, at a quiet moment, with nobody trying to break anything.
Production is everything else. A hundred users at once. Someone pasting an emoji into a phone number field. A payment that fails halfway through. A bot that finds your form and hits it ten thousand times an hour. An employee who clicks the wrong button and wants you to undo it.
None of that is a failing of the AI that wrote your code. It simply isn’t what you asked for. You asked for something that works, and that is what you got.
The numbers are no longer vague
Until recently this was mostly developer intuition. It isn’t anymore.
Veracode tested over a hundred language models on security-sensitive coding tasks. In 45 percent of cases the generated code contained a vulnerability from the OWASP Top 10, the standard list of most common security flaws. For cross-site scripting it rose to 86 percent. More telling than the number itself: between 2025 and early 2026 it did not improve, even as the same models got measurably better at every other coding benchmark.
Security firm Escape.tech scanned fourteen hundred applications built on vibe-coding platforms. They found over two thousand critical vulnerabilities, more than four hundred leaked passwords and keys, and a hundred and seventy-five cases of personal data sitting in the open: medical records, financial details, credentials.
At a Fortune 50 company, Apiiro measured what happens when you scale this up. Developers working with AI assistance shipped three to four times as much code. Monthly security findings went from around a thousand to more than ten thousand. The most serious category, paths that let someone grant themselves more access than they should have, grew by 322 percent.
That last figure is the interesting one. This isn’t about sloppy typos. It’s about structure, about decisions on how the system fits together, and those don’t get fixed with a quick patch.
Why this happens, and why it makes sense
A language model writing code optimises for code that runs. Not for code that holds up when someone means it harm. It has no picture of your threat model, doesn’t know your GDPR obligations, and can’t tell which of your data is sensitive.
There’s a wrinkle on top of that which surprises most people. Roughly one in five times, AI-generated code refers to a software package that doesn’t exist. The model invents a plausible name. Attackers have started exploiting this: they register those invented names in advance, with malicious code inside, and wait for someone to install them. There’s a word for it now: slopsquatting.
And the built-in code review those platforms offer? In practice it regularly misses the serious problems, like SQL injection, while dutifully reporting that your indentation is inconsistent.
What sits between demo and production
When we take over a vibe-coded project, this is roughly the list we work through. Not exciting, but it is the difference between a demo and a business asset.
- Secrets and keys. API keys sit in the source code remarkably often, and not rarely in a public repository too.
- Access and permissions. Who may see what, who may change what, and is that enforced on the server or merely hidden in the interface?
- Input validation. Everything arriving from outside is suspect until proven otherwise.
- Dependencies. Does every package actually exist, does it come from who you think, and is anyone maintaining it?
- Errors and logging. What happens when something breaks, and can you reconstruct afterwards what went wrong?
- Backups and recovery. Not whether a backup exists, but whether you have ever restored one.
- Deployment. A manual step nobody can describe precisely is an outage waiting to happen.
The good news: this is bounded work. Usually weeks, not months. And we almost never throw the prototype away. The functionality is often fine. The foundation underneath isn’t.
Not less AI, but supervision over it
Please don’t read this as an argument to stop building with AI. That speed is real, and going back would be daft.
What matters is that speed without supervision hands you something that looks finished and isn’t. That’s why we put AI-Sitters on it: senior developers who direct, review and refine AI-generated code with the discipline production software demands. The AI does the typing. A human who has seen this before decides whether it ships.
It costs you no pace. It does decide whether you end up with something that impresses in a demo, or something your customers can rely on.
Sound familiar?
Do you have something running that works, but you’re not quite ready to let real customers near it? A forty-five minute conversation is usually enough to establish what’s needed. We look it over, tell you honestly what we see, and if it’s already in good shape you’ll hear that too.
Book a free 45-minute call, or email contact@3bird.nl.
