Vibe coding means building software by describing what you want to an AI and accepting the code it writes, often without reading it closely. It is a fast way to get a prototype working, and a risky way to ship something real: independent research has found that a large share of AI-generated code contains security flaws. The fix is not to stop using AI, but to review what goes out. This guide explains where the term came from, the specific risks that matter for a small web app, and a security checklist to run before a vibe-coded app goes live.
What "vibe coding" means
The phrase comes from a post by Andrej Karpathy, an OpenAI co-founder, in February 2025. As quoted by Merriam-Webster, he described "a new kind of coding" where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." In the same post, as reproduced by Simon Willison, Karpathy added that it was "not too bad for throwaway weekend projects."
The term spread quickly. Merriam-Webster lists it as slang meaning "writing computer code in a somewhat careless fashion, with AI assistance," and Collins named vibe coding its Word of the Year 2025, defining it as "the use of artificial intelligence prompted by natural language to write computer code."
Vibe coding is not the same as coding with AI
The most useful distinction comes from developer Simon Willison, who argues that "Vibe coding is not the same thing as writing code with the help of LLMs!" His definition is narrow: vibe coding is "building software with an LLM without reviewing the code it writes." His own rule for production work is simple: "I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else."
That gives you a practical line. Prompting an AI to build your app is fine. Shipping code nobody has read is where the risk starts. You do not have to understand every line yourself, but someone, or some tool, has to check the parts that touch users' data and money.
Why vibe-coded apps have security problems
The concern is backed by research rather than anecdote. Three findings are worth knowing.
AI models often pick the insecure option
Veracode's 2025 GenAI Code Security Report, published on 30 July 2025, tested over 100 large language models on coding tasks in Java, Python, C# and JavaScript. It found that "45% of code samples failed security tests and introduced OWASP Top 10 security vulnerabilities into the code." Failure rates by language were 72% for Java, 45% for C#, 43% for JavaScript and 38% for Python. For cross-site scripting, the models "failed to defend against it in 86% of relevant code samples."
The code usually works. That is the problem: it passes the "does it run?" check that vibe coding relies on, and fails the "is it safe?" check nobody ran.
AI invents packages that do not exist
A study accepted at the 2025 USENIX Security Symposium generated 576,000 code samples and found that, on average, at least 5.2% of the packages suggested by commercial models and 21.7% of those suggested by open-source models were hallucinated, meaning the package did not exist. The researchers counted 205,474 unique made-up package names. An attacker who registers one of those names can get their code installed by anyone who runs the AI's install command without checking.
Secrets end up in code
When an AI is asked to "connect to Stripe" or "add the database," the quickest working answer often puts a key straight into a file. If that file is pushed to a public repository or shipped to the browser, the key is public. GitHub's push protection, which is enabled by default for user accounts pushing to public repositories, blocks many known secret formats before they land, but it only covers GitHub and only the patterns it recognises.
The vibe coding security checklist
Run this before a vibe-coded app gets real users. Each item is something AI-generated code commonly gets wrong, and each can be checked without being a security specialist.
| # | Check | What "good" looks like |
|---|---|---|
| 1 | Secrets | No API keys, tokens or passwords in the code or the repository; all in environment variables on the server |
| 2 | Browser bundle | Only public, non-secret values are exposed to the browser |
| 3 | Database access | Row-level rules so each user can only read and change their own rows |
| 4 | Authorisation on every endpoint | Every API route checks who is calling, not just whether they are logged in |
| 5 | Input handling | User input is validated on the server and escaped before it is shown |
| 6 | Dependencies | Every package exists, is the one you meant, and is actively maintained |
| 7 | Rate limits | Login, sign-up and paid API calls have limits per user or IP |
| 8 | Payments | Prices and order status come from the payment provider's webhook, not from the browser |
| 9 | Error messages | Users see a friendly message; stack traces and queries stay in the logs |
| 10 | Review | Someone can explain what the auth, data and payment code does |
The sections below expand the items that cause the most damage when missed.
1 and 2: secrets and the browser bundle
Search the project for anything that looks like a key, and check the repository's history, not just the current files, since a deleted key is still in old commits. In a Next.js app, the official docs explain that variables are server-only by default, and any variable starting with NEXT_PUBLIC_ is inlined into the JavaScript sent to the browser, so a secret with that prefix is public. Our guides on API keys security and Next.js environment variables cover where each value belongs and what to do after a leak.
3: database access rules
Many vibe-coded apps use a hosted database the browser can talk to directly. That is safe only if the database enforces per-user rules. Supabase's documentation is explicit: "Enable RLS on every table in an exposed schema," and once Row Level Security is on, no data is accessible through the API with a publishable key until you create policies. It also says: "Never use a secret key in the browser or expose it to customers." Open your database dashboard and check every table, not only the ones you remember asking the AI to create.
4 and 5: authorisation and input
Ask the AI, or check yourself, for each route: what stops user A from reading or changing user B's data by changing an ID in the request? That class of bug, broken access control, is A01, the first entry, in the 2025 edition of the OWASP Top 10, and it is exactly the kind of thing that works perfectly in a demo with one user. Pair it with server-side validation of every form and query parameter; the cross-site scripting figure above shows why escaping output cannot be left to chance.
6: dependencies
Before running any install command an AI gives you, look each package up on its registry. Check that it exists, that the name is spelled exactly as the well-known package is, and that it has a real history. Remove packages the app does not use. Fewer dependencies means fewer things to verify.
7 and 8: abuse and payments
Anything that costs you money per call, such as AI completions, SMS or email, needs a limit, or one script can run up your bill overnight. Rate limiting explained shows the common patterns. For payments, never trust a price or a "paid" flag sent from the browser; confirm with the provider on the server.
10: review
This is Simon Willison's rule applied to a small team. You do not need to review every line of styling. You do need someone to be able to explain the code that handles sign-in, data access and payments. If no one can, ask the AI to explain it line by line, then check the explanation against the code. Our pre-launch checklist for AI-generated code covers the non-security items, such as backups and error tracking, that belong in the same pass.
How to vibe code more safely from the start
- Prompt for security explicitly. Ask for server-side validation, per-user database rules and environment variables in the first prompt, not as a fix later.
- Generate code you own. Code you can read, diff and put under version control can be reviewed. Code locked inside a hosted builder is harder to audit.
- Keep changes small. Ask for one feature at a time and review each change, rather than regenerating the whole app.
- Keep prototypes and products separate. A weekend prototype can stay vibe-coded. When it gets real users, it gets the checklist.
Frequently asked questions
Who coined the term vibe coding?
Andrej Karpathy, in a post on X in February 2025, according to Merriam-Webster.
Is vibe coding bad?
Not for prototypes and personal tools; Karpathy himself described it as fine for throwaway weekend projects. It becomes a problem when unreviewed code handles other people's data or money.
How common are security flaws in AI-generated code?
In Veracode's 2025 tests across over 100 models, 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Results vary by language and task, so treat it as a reason to review, not a precise prediction for your app.
What is the single most important check for a vibe-coded app?
Access control: make sure each user can only reach their own data, both in your API routes and in your database rules. Broken access control is the top risk in the OWASP Top 10 2025, and it is the hardest flaw to notice when testing alone with one account.
Can AI review its own code for security?
It can help, especially when asked about a specific risk such as "can one user read another user's records here?" It is not a substitute for checking the answer against the code and running real tests with two different accounts.
Sources
- Vibe coding (Merriam-Webster, Slang & Trending)
- Not all AI-assisted programming is vibe coding (but vibe coding rocks), Simon Willison
- Collins Word of the Year 2025 (Collins Language Blog)
- 2025 GenAI Code Security Report (Veracode)
- We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (arXiv)
- About push protection (GitHub Docs)
- Row Level Security (Supabase Docs)
- How to use environment variables in Next.js (Next.js Docs)
- OWASP Top 10:2025 (OWASP)
