Vibe coding: what to check before going to production
AI writes code that works, not necessarily code that protects. What we find when auditing a vibe-coded app, the nine checks to run before production, and five tests any business owner can do without being a developer.
Table of contents
Your tool built with Claude or Lovable works. Your team uses it, your customers are in it, maybe their documents too. The question is no longer "does it work?" but "what happens the day it does not?". Here is what we actually find when we audit an app born from vibe coding, and the list of what to check before handing it to users.
What is vibe coding, and why is it a problem in production?
Vibe coding means describing what you want to an AI in plain language and letting it write the code without reviewing it line by line. Andrej Karpathy coined the term in February 2025, and Collins Dictionary made it its 2025 word of the year. For a prototype, it is the fastest method there is. For an application that stores real data, this is where trouble starts: nobody reviewed what protects it.
This is not a case against AI. The same holes existed in code hand written by beginners. The difference is volume: in a few evenings you produce a whole application, and as much surface to protect.
What are the real risks of an AI-built app?
Two public data points give the order of magnitude.
of coding tasks given to AI models produced a known security flaw (from the OWASP Top 10)
Veracode, GenAI Code Security Report, July 2025
Veracode had more than 100 AI models write code for 80 standard tasks. The models picked the insecure option in nearly one case out of two, and newer models did no better than older ones on this point. The full report is online. It is a benchmark, not a measurement of real applications, but the trend is clear: AI writes code that works, not necessarily code that protects.
out of 1,645 showcase apps built with Lovable let anyone read or change their data
Analysis published in 2025, filed as CVE-2025-48757
In 2025, a researcher went through the apps showcased by Lovable. About one in ten exposed its database (emails, addresses, sometimes access keys) because of missing access rules. The flaw has an official number, CVE-2025-48757. Lovable disputes the classification: according to the company, protecting data remains each app creator's responsibility. That is exactly the point. The tool generates, you stay responsible.
What we find when auditing an app born from vibe coding
A recent case, anonymized. A small business owner built, with AI, the management software for their business, to replace an off-the-shelf product they paid for every year. The tool is complete: customer records, generated documents, tracking for a certification. Their team uses it. They asked us to make it reliable. Here is what the first hour of reading the code showed.
Full database backups stored in the code
To play it safe, the AI had exported the database to files, stored in the code repository. All customer data, including social security numbers, sat where the code travels: on GitHub, with everyone who had access to it.
Only one computer could connect to the server
Server access relied on a key stored on the owner's laptop, and nowhere else. Loss, theft or failure of that laptop: nobody could work on the application anymore.
A former contractor still had the keys
Someone who had helped at the start still had access to the hosting and the code repository. Nothing malicious, simply nobody had thought of removing it.
An outdated marketing site, on the same hosting
The company's public site ran on WordPress, waiting for a security update released the day before. A compromised marketing site on the same hosting is a way in to everything else.
“Security before usability: first we close the doors, then we improve the screens.”
None of these points showed on screen. The application worked perfectly. That is what makes the topic tricky: everything is fine until the day nothing is. Since the data was sensitive, a data processing agreement (GDPR) was signed before anyone touched it, then a test environment was set up so no change would ever be tried on real data again.
What should you check before going to production?
Nine points, from most serious to least urgent. They apply to a SaaS sold to customers as much as to an internal tool that runs your business.
If you also plan to sell the tool to other companies, add payments, per-organization accounts and the legal basics: we describe the seven building blocks in turning your Claude project into a real SaaS.
How can you test it yourself, without being a developer?
You will not be able to check everything alone, but five simple tests reveal the most common problems.
The two accounts test
Create two accounts for two different customers. With the first, open a record and copy the page address. Paste it into the second account's browser. If the record shows, your customers can see each other's data.
The private window test
Log out, open a private browsing window and paste the address of an internal page. It must send you to the login page, not display its content.
The code search test
In your GitHub repository, search for "password", "secret", "key" and ".sql". Every result containing a real value is a leak to fix, and the key involved must be changed, not just deleted.
The restore test
Ask to get the database back as it was yesterday, on a test environment. If nobody can do it in under an hour, you do not have a backup, you have a hope.
The lost laptop test
Imagine your computer disappears tonight. List what you could no longer do: ship a fix, access the server, renew the domain. Every line of that list is an access to share.
When should a developer review it?
As soon as one of these is true: the tool stores personal or sensitive data, people outside the company log in, money flows through it, or your business stops when it stops. At that point, a few hours of review cost far less than a data breach you have to report.
A good review does not start by rewriting everything. It starts by closing the doors (secrets, access, backups), sets up a test environment, then takes the tool where it is. The work you did with AI has value: it holds your business rules, tested by your team.
We explain how we combine AI and human review in developers and AI, verified by a human. If your tool is meant to replace off-the-shelf software, also read replacing your business software with an AI-built tool. And for an honest comparison with going on alone: Figue vs doing it yourself with AI.
FAQ
Frequently asked questions
What business owners ask us before putting an AI-built tool into production.
Is an app built with Lovable or Claude secure?
Not by default. The generated code works, but AI often forgets what you do not ask for: checking permissions on the server, keeping passwords out of the code, backing up the database off the server. In 2025, about one in ten of the analyzed Lovable showcase apps left its data open to anyone.
What is vibe coding?
Vibe coding means describing what you want to an AI in plain language and letting it write the code without reviewing it line by line. Andrej Karpathy popularized the term in February 2025, and Collins Dictionary named it the 2025 word of the year.
What should you check first before launching an AI-coded app?
Three things first: no secrets or database exports in the code, permissions checked on the server for every request, and automatic off-server backups with a tested restore. Then shared access, a test environment, error tracking and GDPR.
Do you need to rewrite a vibe-coded app to secure it?
No, in the vast majority of cases. You first close the holes (secrets, permissions, access, backups), set up a test environment, then evolve what exists. Rewriting loses the business rules you refined while testing.
How much does a security audit of an AI-coded app cost?
A first review of the critical points takes an experienced developer a few hours; fixing what it finds takes a few days to a few weeks depending on the state of the code. At Figue, it is usually the first request of a monthly subscription, with no separate quote.
