# When not to vibe code: cases where the risk outweighs the speed

> When vibe coding is a bad idea: personal data, payments, login, software that must last, or code nobody reviews. Warning signs, alternatives and an example.

*Tags: ai, vibe-coding, risk, ux-for-ai*

---


> [!info] Quick Definition
> **Avoid vibe coding** when the cost of an error is high, when the software must last and change, or when nobody can review what the AI wrote. In those cases the speed of the prototype is paid for later in security, maintenance or user trust.


## What does "risk" mean in code?

When code fails, the damage depends on three things: who it affects, what data it touches and how long it stays in use. A personal script that fails annoys one person. A payments app that fails affects customers, finances and reputation. So the useful question is not "can I vibe code this?" but "what happens if this goes wrong, and to whom?"

Simon Willison, who defines vibe coding as building software with an LLM without reviewing the code it writes, frames it the same way: projects should be low stakes, and you should think about how much harm the code could cause if it has bugs or security vulnerabilities, especially if other people will use it ([Willison, March 2025](https://simonwillison.net/2025/Mar/19/vibe-coding/)). His personal rule is not to commit code to his repository that he could not explain to someone else.

There is also a measured reason for caution. A Veracode study published in July 2025 tested more than 100 language models on 80 coding tasks: the generated code introduced vulnerabilities in 45% of cases ([Veracode, July 2025](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)). These are controlled tasks, not a measurement of all production code, but they are enough not to trust code just because it runs.

## Which signals say it is a bad idea?

| Signal | Why it matters | What to do instead |
|---|---|---|
| Personal or health data is involved | An error exposes real people | Design the flow and request a privacy review |
| Payments or third-party money are involved | A miscalculated charge does not fix itself | Use a proven payments provider |
| It calls a usage-billed API | A loop or a leaked key produces a large bill | Set a spending limit with the provider before testing |
| There is login or permissions | A bug lets people see other people's data | Use an existing authentication service |
| It will be used for years | The code becomes hard to change | Write a spec and review each change |
| Others depend on it and nobody can review it | Nobody catches the errors or knows what the code does | Get a human review before publishing |

If even one of these signals appears, the prototype can stay vibe coded, but the version other people use cannot. The money signal is easy to forget: Willison mentions people who ran up thousands of dollars in charges by vibe coding against usage-billed APIs without setting a billing limit.

## When is vibe coding fine?

It works when errors are cheap and paid for by whoever builds the thing. Andrej Karpathy, who coined the term in February 2025, already described it as "not too bad for throwaway weekend projects", in the quote Willison includes. Typical cases:

- **Prototypes to test an idea** with users in a moderated session, using fake data.
- **Personal tools**, such as a script that renames files or a dashboard only you see.
- **Learning.** Willison encourages beginners to try it, because building a project is the best way to learn, and recommends starting in sandboxed environments that limit what the code can access.
- **Exploring interactions**: an animation, a flow or a component that is later rebuilt with review.

The line is set not by the tool but by where the code ends up. If the prototype is going to receive real data or outside users, it changes category. The difference between the two ways of working is covered in [[vibe-coding-vs-ai-assisted-engineering|vibe coding vs. AI-assisted engineering]].

## What to check before opening it to the public?

If a vibe-coded project is going to be used by other people, the minimum security review (permissions, secrets, input validation and dependencies) is in [[vibe-coding-security-basics|security basics for vibe coding]]. Addy Osmani sums it up in one line in his guide *Beyond Vibe Coding*: vibe coding is fun until you start leaking database credentials in the client ([Osmani, Beyond Vibe Coding](https://beyond.addy.ie/)).

Beyond security, two questions belong to this decision. First: can someone on the team read and change this code six months from now? If not, the project depends on asking the AI for everything again. Second: what happens if it goes down for a day? If the answer is "a customer cannot work", it is no longer a prototype. Willison suggests something simple at this point: if other people will use it, ask someone more experienced for a "vibe check" first.

## Example

Illustrative example: a designer vibe codes an internal tool so her team can log feedback from usability tests. For one afternoon, it works. Eight months later, three teams use it, it stores participants' names and emails, and it calls a usage-billed AI API to summarize each session. One day it stops saving data and nobody knows why, because nobody read the code. Running it through the signals table turns up four: personal data, a usage-billed API, long-term use and people who depend on it. The designer freezes new features, sets a spending limit with the API provider and asks a developer to review data access and document how it works before going further.

## How do you apply it tomorrow?

1. Run your next project through the signals table before you start. Write yes or no for each one and keep the answers in the README or the project page.
2. If at least one signal says yes, split the parts. For example, the screen can be vibe coded; the payments module cannot.
3. If the project calls a usage-billed API, set a spending limit before the first test.
4. Before publishing, ask an engineer to check where the keys live and what happens when a user logs in with an account that is not theirs.
5. Put a review date on the calendar. If the prototype is still in use on that date, treat it as a product and review it as one.

Deciding not to vibe code is also a design decision: it sets clear limits for the team and avoids surprises at launch. If you are new to the topic, start with [[what-is-vibe-coding|what is vibe coding]].

## Common mistakes

- Deciding something is "just a prototype" when it already has real data.
- Assuming the AI would not introduce a security flaw because the code "looks right".
- Testing against a usage-billed API with no spending limit.
- Treating a working demo as a security test.
- Letting a prototype become a product without anyone deciding it.
- Using vibe coding to replace a proven service, such as payments or authentication.

## Sources

- Veracode, "AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks" (July 30, 2025): [https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)
- Addy Osmani, "Beyond Vibe Coding" (online guide): [https://beyond.addy.ie/](https://beyond.addy.ie/)
- Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)" (March 19, 2025): [https://simonwillison.net/2025/Mar/19/vibe-coding/](https://simonwillison.net/2025/Mar/19/vibe-coding/)


---

Source: https://www.fernandoux.com/en/wiki/ai/when-not-to-vibe-code/