Is Vibe Coding Bad? When It Works and When It Bites

Vibe coding is not bad in itself. It is a fast way to build prototypes, personal tools and small sites. It becomes bad when AI-written code that nobody has read is trusted with money, private data or logins. The fix is not to avoid it. It is to match the amount of checking to what the app can break.

What the term means

Vibe coding is software development where you describe a task to an AI model that writes the code, and you may accept the output without reading all of it. Per the Wikipedia article on the term, computer scientist Andrej Karpathy coined it in February 2025, describing a style where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists". The article adds that Merriam-Webster listed it as "slang and trending" in March 2025 and that Collins English Dictionary named it Word of the Year for 2025.

Since then the phrase has stretched. Some people use it for anything done with an AI coding tool. We use the narrow sense: building by prompting and steering, with little or no code review. Our vibe coding tutorial walks through doing it with a safety check, and best vibe coding tools lists the options.

The verdict, by use

The pattern is simple. The more people depend on the code and the more damage a bug can do, the less you can afford to skip reading it.

What critics say, and what holds up

The Wikipedia article summarizes the main criticisms. Critics point to a lack of accountability, trouble maintaining the result, and a higher risk of security flaws. It also lists reported issues with code quality, technical debt, debugging and task complexity. Here is each in plain terms.

Security flaws

AI models write code that runs. Running is not the same as safe. A form that saves data works in a demo and may let a stranger read everyone's records. Supabase's documentation states the risk directly: a table in an exposed schema without row level security is readable and writable by any role with a grant on it, and it advises enabling row level security on every table in an exposed schema. A prompt that says "build a database" does not promise that setting. Our security guide turns this into a checklist.

Maintainability

Code you did not read is code you cannot fix. When it breaks six months later, you meet it as a stranger. AI-written code can also be repetitive, since each prompt adds more rather than reusing what exists. That is manageable if you commit to version control and ask for refactors, and painful if you do not.

Accountability

If no person reads the code, no person is answerable for it. This matters for apps that other people rely on. Someone has to own the decision that it is ready.

Agents that act

Reports exist of agents taking destructive actions. The Wikipedia article records that in July 2025 the founder of SaaStr documented a Replit AI agent deleting a database despite explicit instructions not to make changes. We have not verified that account ourselves, and Replit may have changed its safeguards since. The general lesson is sound: an agent with write access to production data can cause damage, so keep production separate from where the agent works, and keep backups.

What defenders get right

Critics sometimes miss why people do this. Three points hold up.

1. It lowers the cost of trying. A person with an idea can see it working in an afternoon. Before, that took a developer or a budget.
2. Many apps are small. A tool that tracks your own recipes does not need a security review.
3. Prototypes are for learning. If the point is to test whether anyone wants the thing, polished code is wasted effort.

The Wikipedia article notes that supporters say it lets amateurs produce software without the extensive training of engineering. That is true and useful, and it does not cancel the risks above. Both statements stand together.

Vibe coding versus careful AI-assisted work

Using AI to write code is not the same as skipping review. A developer using Claude Code or Cursor, with tests, a diff review and version control, is doing something close to normal engineering with faster typing. The word "vibe" in the narrow sense describes the habit of not looking. Our page on vibe coding versus agentic coding draws the line more carefully.

The Claude Code best-practices page puts the idea well. It says Claude stops when the work looks done, and that without a check it can run, looking done is all it has. Give it a test command and ask for the output. That one habit moves a project from vibes toward verification.

A safe routine, in seven steps

You can keep the speed and cut most of the risk.

1. Decide the stakes first. Who uses it, and what is the worst a bug could do? That sets how much checking you owe.
2. Use version control from day one. Commit after each working step so you can go back.
3. Build in small steps. One feature per prompt, and click through it after each.
4. Keep production separate. The agent works on a copy with test data, never on your live database.
5. Check access rules. For any app with accounts, sign in as a second user and try to read the first user's data.
6. Keep secrets out of prompts and the repository. Use the platform's secret storage.
7. Ask a reviewer before launch when real users, money or personal data are involved. See how to deploy a vibe coded app.

Seven steps sound like a lot. Most take minutes, and the access check takes ten.

How to tell if your app is in the risk zone

Answer these four questions honestly.

If every answer is no, relax and enjoy the speed. If any answer is yes, add the review.

Four myths on both sides

Myth: AI code is always worse than human code. Not on the documented facts. Quality varies with the task, the tool and the checking. A reviewed, tested change written by an agent can be better than a rushed human one. The problem is unreviewed code, not AI code.

Myth: if it runs, it is done. Running proves the happy path. It says nothing about the path where a stranger sends strange input, or the path where two users act at once.

Myth: you cannot learn from it. You can, if you read what it produces and ask it to explain. Many beginners learn faster by changing working code than by studying blank pages. Skipping the reading is a choice, not a requirement.

Myth: this is a passing fad. The term is recent, but describing software in plain language to a model is a lasting capability. The useful question is how to do it safely, not whether it will go away.

If you inherit or buy a vibe coded app

Sometimes the choice was made before you arrived. You are handed a working app and nobody remembers how it was built. Treat it as you would any codebase of unknown quality, with a short audit.

1. Find the repository. If the code lives only inside a platform, export it first. If no export exists, you have learned something important.
2. Run it somewhere else. If it will not run outside the original platform, note every service it needs.
3. Read the access rules. Check each database table and each route that returns user data.
4. Search for secrets. Look for keys, tokens and passwords in the code and the history.
5. Run what tests exist, and add three. Write tests for sign-in, a permission boundary and the main money or data flow.
6. Check dependencies. Look for packages nobody recognizes and for very old versions.
7. Make a backup and try a restore.

An audit like this takes a developer a day or two for a small app. It will either bring peace of mind or show a list of problems, and both outcomes are worth the time before real users arrive.

Questions to ask a builder who used vibe coding for you

If you hired someone and they used AI tools, that is fine. Ask about the checking instead.

A builder who answers these plainly has your interests in mind. One who says the AI handles it has not understood the question.

What good teams do

Teams that use AI tools heavily and stay out of trouble tend to share habits. They keep an instructions file so the agent knows the rules, as in our CLAUDE.md guide. They write tests and make the agent run them. They review diffs, and they ask for a second review of any change that touches payments, logins or personal data. They use read-only credentials where they can. And they treat the agent's output as a draft from a fast junior colleague, not as a verified result.

None of this needs a large team. A solo builder can follow it with a free repository and a habit.

Our take

Vibe coding is a tool, and tools have a right size of job. For personal software and prototypes it is a good deal: fast, cheap and low risk. For software other people trust with their data, skipping review is a choice to let strangers carry your risk.

We would not tell anyone to stop. We would tell them to ask one question before each launch: if this fails in the worst way, who is hurt? If the answer is "only me", ship it. If the answer is "my customers", get a second pair of eyes first.

The honest gap in all of this is evidence. Claims about how often vibe-coded apps fail are mostly anecdotes, and we have not found a source we trust for a rate. We have not quoted one. Treat any percentage you see with suspicion unless it names its method.

Checklist

• Wrote down who uses the app and what a bug could break
• Code is in version control with frequent commits
• The agent works on a copy, not on production data
• Access rules tested by signing in as a second user
• No secrets in prompts or in the repository
• Backups exist and a restore has been tried once
• A reviewer has seen anything touching money or personal data

Related pages

• Secure a vibe coded app
• Deploy a vibe coded app
• Vibe coding vs agentic coding
• Vibe coding tutorial
• Best vibe coding tools