On this page
Is vibe coding bad? Not by itself. Vibe coding can put a working prototype in front of people within days. For a demo, an internal tool or a test of demand, that speed is often the right call. It turns bad when a vibe-coded app meets real users, real data and real money without anyone reading the code underneath.
This guide explains what vibe coding is and what breaks when AI code ships. It also covers which vibe coding apps are fine to build this way and the checks that catch problems while they are cheap to fix. If your app is already live with customers, a vibe code audit tells you which of these problems you have and which to fix first.
What is vibe coding?
Vibe coding is building software by describing what you want to an AI tool and accepting the code it produces without reading it closely. Andrej Karpathy named it in a post on X on February 2, 2025. He described taking the AI's changes without reviewing the diffs and pasting error messages back until things worked. He said it suited throwaway weekend projects because the code grew beyond his own understanding.
The term now covers two kinds of tools. Prompt-to-app builders such as Lovable, Bolt and Replit generate a whole application from a description, often including the database. Coding agents inside an editor, such as Cursor, write and change code across a project on request. Either can be used carefully by an engineer who reviews every change. It becomes vibe coding when the person steering the tool judges the result by whether it runs, not by what the code does.
That distinction matters more than the tool. AI-assisted engineering, where someone who understands the system reads and tests each change, is ordinary professional work. Vibe coding skips that step, and the skipped step is where most of the risk lives.
So, is vibe coding bad?
Vibe coding is a speed tool with a bill that arrives later. The code usually works on the screens you tested. The trouble sits in what you did not test. Who can read which data? What happens with unexpected input? How does the code behave when someone else has to change it? The research points the same way, and it adds a second problem: people feel safer than they are.
- A Stanford study published at ACM CCS 2023 found that participants with an AI coding assistant wrote significantly less secure code than those without one. They were also more likely to believe their code was secure.
- A study led by NYU researchers and presented at the IEEE Symposium on Security and Privacy 2022 generated 1,689 programs with GitHub Copilot. Across 89 security-relevant scenarios, about 40% of them were vulnerable.
- A randomized study by METR, published in July 2025, found that experienced open-source developers took 19% longer on real tasks when AI tools were allowed. Afterwards, they believed AI had made them about 20% faster.
These studies used earlier models, and METR has since published newer measurements, so treat the exact numbers as dated. The pattern is the useful part: confident users, unchecked output and a gap between how finished the app feels and how finished it is. That gap is what you are managing, whatever tool you use.
What breaks when a vibe-coded app ships
The failures below are the ones we check first in a vibe-coded app, because public research and incident reports keep finding them. Most of them are invisible in a demo.
Access control that is missing or only in the interface
Broken access control is first on the OWASP Top 10:2025, OWASP's list of the most serious web application security risks. In AI-built apps it usually means the database answers anyone who asks. Supabase's documentation says a table in an exposed schema without row-level security is readable and writable by any role with a grant on it. Firebase warns that open rules let anyone who guesses your project ID read, change or delete your data. A third version hides the admin button from normal users but never checks their role on the server. Our vibe coding security update tracks the 2026 incidents where exactly this went wrong.
The fix starts with row-level security on every table and a policy that ties each row to its owner. In Supabase that looks like this:
alter table invoices enable row level security;
create policy "owners read their invoices"
on invoices for select
using ((select auth.uid()) = owner_id);Secret keys in the browser
Coding tools often place an API key wherever the code needs it, including the front end. Any key in the browser bundle is public. Supabase's guidance is direct: never use a secret key in the browser or expose it to customers, because secret keys can bypass row-level security. The same goes for payment, email and AI provider keys. GitHub's push protection blocks pushes that contain recognized secrets before they reach the repository, which catches part of the problem early.
Packages that do not exist, or should not be trusted
AI tools sometimes suggest dependencies that were never published. A study accepted for USENIX Security 2025 generated 576,000 code samples with 16 language models. Average hallucinated-package rates were at least 5.2% for commercial models and 21.7% for open-source ones. An attacker can register one of those invented names and wait for someone to install it. OWASP now lists software supply chain failures third in its 2025 Top 10.
Data the app cannot trust
Validation often lives only in the form, so anything that calls the API directly can write bad data. Schema changes happen through prompts instead of migrations, so nobody can say what production looks like. Backups may exist, but a restore has never been tested. None of this shows up until the day you need it.
Code nobody can maintain
Vibe-coded projects tend to grow by copy and paste: the same logic in four places, no tests, and fixes that break something two screens away. Each new prompt adds code on top instead of changing what is there. Before deciding what to keep, it pays to know how to measure technical debt so the conversation is about evidence rather than taste.
AI features with open doors
If your app calls a language model, it inherits a second set of risks. The OWASP Top 10 for LLM Applications 2025 puts prompt injection first, and also lists sensitive information disclosure, system prompt leakage, excessive agency and unbounded consumption. The last one is the expensive surprise: a public endpoint that anyone can call in a loop, billed to your account.
Which vibe coding apps are fine to build
The question is not whether to use AI tools. It is which apps can live with unreviewed code and which cannot. The line comes down to data, money and how many customers share one system.
| Kind of app | Vibe code it? | What to watch |
|---|---|---|
| Prototype for user interviews | Yes | Use fake data and throw it away once you have learned what you needed |
| Clickable demo for investors | Yes | Present it as a demo, and do not describe it as the production system |
| Landing page or marketing site | Yes | Forms that collect emails still need spam protection and a privacy notice |
| Internal tool with no sensitive data | Yes, with care | Limit access to your team and keep keys on the server |
| MVP that stores personal data or takes payments | Only with review before launch | Access control, keys, server-side checks and backups |
| B2B app where several customers share one database | Only with review before launch | One customer must never see another customer's records |
| Health, finance or children's data | No, not without engineering ownership | Regulatory duties apply on top of the security basics |
For example, a solo founder testing a scheduling idea might vibe code the whole first version and run ten user interviews on it. They would learn more in a week than a month of planning would teach. The same founder should not then invite paying clinics onto that build without someone reading the data rules first.
Signs your vibe-coded app needs a human review
If any of these are true, the app has outgrown unreviewed code:
- You cannot say where permissions are enforced: in the database, in the API or only in the interface.
- A key labelled secret or
service_role, or a payment or AI provider key, appears anywhere in your front-end code. - Each fix the tool makes breaks something else, and the loop of prompting and retrying is getting longer.
- Only the builder tool can deploy the app, and nobody has a copy of the code in your own repository.
- A business customer has sent a security questionnaire, or you are about to take payments.
- Customer data is already in the system and nobody outside the tool has looked at the access rules.
For a quick self-assessment, the Vibe coding risk check for AI-built apps walks through these questions one by one. If customers are affected right now, go straight to Software project rescue and crisis response.
How to catch problems early
You do not need to stop using AI tools to ship safely. You need a few habits that cost minutes now and save weeks later.
- Keep the code in Git from day one, in a repository your company owns, so every change can be seen and undone.
- Separate test and production data so experiments never touch real customers.
- Turn on row-level security or owner-based rules before the first real user. Then run the outsider test: sign in as one user and request another user's record by its ID. Try again with no session at all. Both requests should fail.
- Keep secrets on the server, and rotate any key that has ever been in the browser bundle or pasted into a prompt.
- Check every package the tool adds: that it exists, who maintains it and whether the name is spelled exactly right.
- Ask the tool to write tests for login, permissions and payments, and read those tests yourself. They describe what the app promises to do.
- Set spending limits on your AI provider and cloud accounts, and put rate limits on any endpoint that calls a model.
- Back up the database and test a restore before you need one.
- Get a code security audit before real customer data arrives, or before a raise, whichever comes first.
How we fix vibe-coded apps
A rewrite is rarely the first move. Thanos Gkanas, our Head of Engineering, leads this work, and it follows our Audit, Build and Ship steps. The Audit maps the data and who can reach it, because that is where the serious risk usually sits. The Build closes the access control gaps, moves secrets to the server and adds tests around the money and permission paths.
Only after that do we decide, area by area, what to keep, what to refactor and what to rebuild. Plenty of AI-written code is fine once it has tests and a clear structure. The Ship step deploys the fixes, rotates any exposed keys and hands over written notes on what changed and why. Your team, or your next AI session, then starts from a codebase someone understands.
Frequently asked questions
What is vibe coding?
Vibe coding is building software by describing what you want to an AI tool and accepting the code it writes without reading or fully understanding it. Andrej Karpathy named it in February 2025. The term now covers prompt-to-app builders and coding agents used by people who judge the result by whether it runs, not by the code.
Is a vibe-coded app safe to put in front of customers?
Not until someone has checked it. The most common gaps are missing access control, secret keys in the browser and permission checks that exist only in the interface. An app can look finished and still let one customer read another's data. Have the data rules, keys and server-side checks reviewed before real customer data arrives.
Which kinds of apps are fine to vibe code?
Prototypes for user interviews, clickable demos, landing pages, internal tools without sensitive data and one-off scripts are fine to vibe code. The risk rises when an app stores personal data, takes payments, serves several business customers from one database or works in a regulated field. Those vibe coding apps need engineering review before launch.
How do you vibe code more safely?
Keep the project in Git from day one, separate test and production data, and turn on database access rules before adding real users. Keep secret keys on the server, check every package the tool adds and ask the tool to write tests for login, permissions and payments. Then have an engineer read the parts that touch data.
Can a vibe-coded app scale?
Sometimes, but rarely without changes. AI tools tend to produce code that works for a few users and a small dataset. Expect queries without indexes, business logic running in the browser and the same code repeated in several places. Scaling usually means adding indexes and caching, moving rules to the server and refactoring the busiest parts, not starting over.
Sources and update history
- Andrej Karpathy: post introducing vibe coding on X (February 2, 2025)
- Perry, Srivastava, Kumar and Boneh: Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023)
- Pearce, Ahmad, Tan, Dolan-Gavitt and Karri: Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (IEEE S&P 2022)
- METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 10, 2025)
- Spracklen et al.: We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
- OWASP Top 10:2025
- OWASP Top 10 for LLM Applications 2025
- Supabase Docs: Row Level Security
- Firebase Docs: Avoid insecure rules
- GitHub Docs: About push protection
Update history
- First published.
