From Vibe Coding to Production: The Most Dangerous Gap in AI

Last week I was in a meeting with an IT company that has been active for 35 years. They had a client with a system that looked like Teletext. One retired developer could maintain it. Nobody else.

That same week I spoke with a startup founder who proudly showed his new platform. Fully built with Claude Code and Lovable. Not a single line written himself. "It works great," he said.

Two extremes. The same common thread: nobody understands what's under the hood.

The new reality

Andrej Karpathy, co-founder of OpenAI, coined the term "vibe coding" in early 2025: fully going with the vibe, forgetting the code exists, and just describing what you want. It became word of the year. And it changed everything.

Although vibe coding has been a thing for a while, I now suddenly see it every week in my discovery calls.

Clients coming in with working prototypes. Built in a weekend. With tools like Cursor, Lovable, v0, Windsurf or Claude Code. They have something that runs, looks good, and they're excited about.

Nothing feels better than building something yourself and showing it to others. (Although my girlfriend doesn't always share my enthusiasm, especially when it doesn't quite work yet..)

Back to those discovery calls with potential clients, because that's when I say: "Nice. But this can't go to production."

Why not?

The numbers are hard by now. An analysis by CodeRabbit of 470 open-source projects on GitHub showed that AI-written code contains 1.7 times more major bugs than human code. Security issues? 2.74 times more frequent. At Lovable, one of the most popular vibe coding platforms, 170 out of 1,645 built applications had a security vulnerability that made personal data accessible to everyone.

And we haven't even talked about the real incidents yet.

In February this year, Moltbook was hacked: a social platform fully built via vibe coding. 1.5 million authentication tokens and 35,000 email addresses were exposed on the internet. The founder had never looked at the infrastructure code. The AI had used permissive settings during development, and those went to production.

Even worse: SaaStr founder Jason Lemkin had a Replit AI agent build a production app. The agent started lying about unit tests, ignored code freezes and eventually deleted the entire production database. Months of data, gone.

The prototype paradox

Here's the paradox. Vibe coding is phenomenal for prototypes. You can build a working 3D game in four minutes (Ethan Mollick did it live). You can launch a complete SaaS in a weekend. The barrier to creating something has never been lower.

But a prototype is not a product.

Research shows that 60 to 80 percent of vibe-coded projects need to be rewritten before they can go to production. Not minor adjustments: fundamental rewrites. Security, error handling, scalability, monitoring, logging, data integrity. Everything you don't see as a user, but that determines whether your system still runs tomorrow.

Ethan Mollick, professor at Wharton and one of the sharpest AI thinkers, put it well: the skill of the future is not writing code yourself. It's knowing what good looks like, and being able to explain it clearly enough so an AI can deliver it. Management becomes the AI superpower. But that requires knowing what you don't know.

What I see in practice

At NinA AI we notice this shift daily. More and more clients don't come with a question, but with a prototype. "Can you take this to production?" That's a fundamentally different conversation than two years ago.

Four weeks ago I discussed with my team how we can turn this into a structural service. Security checks on AI-generated code. Not as a nice-to-have, but as a standard step. The result: a professional report with concrete recommendations.

A stamp that it's safe. Because that's what's missing. Not the building—anyone can do that now. But the validating, securing and making scalable. The difference between a demo and a business-critical system. I'm thrilled to have a team around me that can do that!

The five things vibe coding misses

After dozens of these conversations I keep seeing the same five gaps:

1. 1.Security. AI models generate code that works, not code that's secure. Hardcoded API keys, open database access, missing input validation. These aren't edge cases—they're the default.
2. 2.Error handling. What happens when an API call fails? When a user enters unexpected data? When your database fills up? Vibe-coded apps rarely have an answer.
3. 3.Scalability. It works for 1 user. But for 2? Or 10? Or maybe 1,000? The architecture choices an AI makes during prototyping are almost never suitable for scale.
4. 4.Monitoring and logging. When something goes wrong in production, how do you know? Vibe-coded apps have no observability. No alerts. No audit trail.
5. 5.Data integrity. The most dangerous: what if your AI agent silently overwrites data? Or duplicates it? Or deletes it? Without logging you only notice when it's too late.

What you can (and should) do with it

I'm absolutely not against vibe coding. On the contrary. It's one of the most powerful developments of recent years. But you need to know where the boundary is.

Use it for prototypes and proof of concepts. To quickly validate whether an idea works. To convince stakeholders with something tangible instead of a PowerPoint. To test in a weekend what used to take months.

But treat the result as a sketch, not a blueprint. Have a professional review the code before it goes to production. Set up a separate test environment. Implement monitoring. And build the error handling that the AI forgot.

At one of our clients they came with a working AI platform that supports their consultants and can eventually be used by customers. Built in Python, FastAPI, React. Good stack. But fully on localhost, without multi-tenancy, without access rights, without separation of customer data. The step from "it works on my laptop" to "we can offer this to clients" took six to eight weeks of professional development work. That's not a failure of vibe coding. That's exactly how it should work: build fast, then make it professional.

The new role: from builder to inspector

The market is shifting. Two years ago the question was: "Can you build this for us?" Now I increasingly hear: "We've built something, can you take it to production?"

That requires a different skillset. Not just building, but also evaluating. Not just creating, but also validating. The value is no longer in writing code. It's in knowing whether code is good enough.

Or as Mollick puts it: the people who will make it are those who know what good looks like, and can explain it clearly enough.

That applies to developers. But also to you as an entrepreneur. The question is not whether you'll use AI to build software. The question is whether you know when the result is good enough for your customers.

And if you're not sure? Then that's exactly the moment to bring in a professional.

Until next time!