In short: vibe coding is excellent for validating an idea and far from sufficient for running a product. An AI-generated prototype demonstrates that a user flow is possible. A product in production must also be secure, tested, observable, maintainable and able to withstand cases nobody anticipated. The gap between the two is closed with an audit, a sorting of what is kept and what is rewritten, then a few weeks of targeted consolidation.
More and more founders arrive with an application that already works, built over a few evenings with Lovable, Bolt, v0, Cursor or Claude Code. That is very good news: the idea is concrete, testable, and often already shown to users. The question then becomes: what needs to be done before plugging real customers and real payments into it?
What vibe coding is
The term describes a way of developing where you describe what you want in natural language, and an AI model writes the code. You judge the result on screen rather than by reading the code, and you iterate through successive instructions.
Two families of tools coexist:
- Application generators (Lovable, Bolt, v0, Replit): designed for non-developers, they produce a complete application and host it.
- Coding assistants (Cursor, Claude Code, GitHub Copilot): designed for developers, they work inside an existing codebase.
The latter are now used daily by professional teams, ours included. The difference lies not in the tool, but in who reviews, understands and takes responsibility for the code produced.
What vibe coding does very well
- Validating an idea in a few days instead of a few weeks.
- Showing rather than explaining. A clickable prototype beats any specification for aligning a team or convincing an investor.
- Building low-stakes internal tools: dashboards, scripts, small utilities.
- Exploring several directions for design or user flows before committing.
For all these situations, it is considerable progress, and it would be absurd to go without it.
Where generated prototypes break
The same weaknesses come up in almost every generated application we are asked to take over.
Security
This is the most serious and least visible problem. API keys exposed in the browser code, a database accessible without access control rules, no permission checks on the server side: the application works perfectly in a demo, and any slightly curious user can read other people's data.
The data model
Models generate a schema that answers the request of the moment. Ten iterations later, you end up with redundant tables, inconsistent relationships and no migration strategy. It is the most expensive part to fix once real data exists.
Error cases
The happy path works. What happens if the payment fails halfway through, if the network drops, if two people edit the same data, if a field is empty? Generally, nothing has been planned.
The absence of tests and monitoring
Without automated tests, every new instruction given to the AI can break an existing feature without anyone noticing. Without logging or alerts, you learn about outages from your customers.
Code consistency
Three different ways of doing the same thing, dead code, unnecessary dependencies. The application works, but every change becomes slower and riskier, for a human and for an AI alike.
Usage costs
Unoptimised queries, calls to AI models with no limit or cache: the bill stays invisible with ten users and becomes a problem with a thousand.
The checklist before going to production
| Area | What to check |
|---|---|
| Security | No secrets on the browser side, permission checks on the server side, database access rules, rate limiting |
| Data | Schema reviewed, versioned migrations, tested automatic backups |
| Authentication | Session management, password reset, roles and permissions |
| Payment | Verified webhooks, handling of failures and refunds |
| Quality | Tests on critical flows, continuous integration, code review |
| Operations | Logging, error tracking, alerts, separate test and production environments |
| Compliance | GDPR, legal notices, consent, data location |
| Performance | Load times, optimised queries, control of infrastructure costs |
If you cannot answer these points with certainty, the application is not ready to receive customer data.
Take over or rewrite?
This is the question everyone asks, and the answer is almost never "throw everything away".
Generally worth keeping: the interface and the user flows, which have been validated with users; the product knowledge accumulated; often the stack itself, because these tools generate standard technologies such as React, TypeScript and PostgreSQL databases.
Generally worth redoing: the data model, authentication and permissions, everything that touches payment, and the project structure.
The right approach unfolds in three stages:
- A technical audit of one to two weeks, which produces a prioritised list of risks. See our technical audit offering.
- A targeted consolidation of the foundations: security, data, tests on critical flows, setting up operations.
- A return to the roadmap, with a method that prevents the debt from building up again.
On a reasonably sized prototype, consolidation generally takes between three and eight weeks. That is markedly less than a development from scratch, because the hardest part, knowing what to build, is already done.
Keep using AI, but differently
Going to production doesn't mean abandoning AI. It means putting a framework around it:
- Every change goes through a code review done by someone who understands what they are reading.
- Automated tests act as a safeguard: the AI can propose, the tests verify that it hasn't broken anything.
- The project's conventions are written down and given to the AI tools, so that the generated code stays consistent.
- Tasks are small and well defined, rather than a vague instruction applied to the whole application.
- Architecture decisions remain human.
Used this way, AI genuinely speeds up an experienced team. Used without a framework, it mostly speeds up the accumulation of technical debt.
Frequently asked questions
Can you put an application built with Lovable or Bolt into production?
Yes, provided you have it audited and consolidated first. The points to address as a priority are data security, database access rules, payment and adding tests on critical flows.
Do you have to rewrite everything after a vibe-coded prototype?
Rarely. The interface and the validated user flows are most often kept. It is the data model, authentication and code structure that generally need to be redone.
How much does it cost to take over an AI-generated prototype?
It depends on the size of the application. Expect one to two weeks of audit, then three to eight weeks of consolidation for a reasonably sized prototype, which is a budget markedly lower than a full development.
Will vibe coding replace developers?
It changes their work more than it eliminates it. Writing code becomes less expensive; deciding what to build, guaranteeing security, designing the architecture and taking responsibility for going to production remain human responsibilities.
What are the risks of an unaudited AI-generated application?
The main ones are leaks of user data, exposure of API keys, data loss for lack of backups, and an application that becomes impossible to evolve.
👉 Have a prototype and want to know what it's worth? Discover our vibe coding support and our project takeover offering, or book a call.