Is vibe coding bad? The case against, the case for, and a verdict by use

Is vibe coding bad?

The honest answer depends on what is being built and who gets hurt if it is wrong. Vibe coding means describing software to an AI and accepting much of the code it writes without reading it. If you want the definition in full, read what vibe coding is. This page weighs the arguments.

The person who named it was careful. Andrej Karpathy wrote in his February 2025 post that it was “not too bad for throwaway weekend projects, but still quite amusing” (original post). The word then spread to cover far more than that. Most of the heat in the debate comes from people arguing about different things under one name.

What is the case against vibe coding?

The criticisms are specific, and several are documented. These are the strongest, with the evidence for each.

1. Security holes you cannot see. If you do not read the code, you will not notice a secret key in front-end code or a database anyone can read. In May 2025, security vulnerabilities were reported in sites built with Lovable, and in February 2026 a researcher demonstrated a flaw in the Orchids vibe coding platform to the BBC, as summarised in Wikipedia's article. Supabase states that its secret key bypasses row-level security and must never be in a browser, which is exactly the kind of rule an unread project breaks (Supabase docs).
2. Agents can do damage. In July 2025 the founder of SaaStr documented a Replit agent deleting a database despite instructions not to change anything (same Wikipedia summary). An agent with write access to live data is a different risk from a chatbot that only suggests code.
3. Code that gets harder to change. GitClear's analysis of 211 million changed lines of code from 2020 to 2024 found refactoring falling from 25 percent of changed lines in 2021 to under 10 percent in 2024, and duplicated code rising about fourfold. That covers AI-assisted coding in general, not only the vibe kind, but it points at the same drift. In May 2026 two engineers behind the Pi coding tool told the Wall Street Journal they feared a coming “vibe slop” crisis of buggy software and outages (also in Wikipedia's account).
4. Debugging without understanding. When the tool cannot fix a bug and you cannot read the code, you are stuck. Karpathy himself wrote that when the models failed to fix a bug he would work around it or ask for random changes until it went away.
5. You may not be as fast as you feel. A 2025 randomized trial by METR on experienced developers working in familiar open-source projects found they took 19 percent longer with AI tools, while believing they were faster (METR). The tools it tested were early 2025 models, so read it as a caution about trusting your own sense of speed, not as a ruling on current tools.

Simon Willison, who is enthusiastic about AI-assisted programming, draws the line the same way critics do: he will not commit code to production that he cannot explain to someone else (his post).

What is the case for vibe coding?

Defenders do not claim it is safe for everything. They say it does something valuable that nothing else has done at this scale.

• It lets non-programmers make software for themselves. New York Times journalist Kevin Roose, not a professional developer, built several small apps this way and called the results “software for one,” while noting they were limited and error-prone (summary on Wikipedia). Many useful tools were never worth a developer's paid time and exist now.
• It lowers the barrier to learning. Willison wrote that vibe coding shaves the initial learning curve to nearly flat and that some newcomers will get bitten by the programming bug and become proficient developers. He also called it the best way for experienced developers to build intuition about what these models can and cannot do.
• It makes prototypes cheap. Testing an idea with a working demo, rather than a slide, changes what you can learn in a week. A prototype that gets thrown away costs little even if its code is poor.
• It is already in professional use. Y Combinator said in March 2025 that a quarter of its Winter 2025 startups had codebases that were 95 percent AI-generated (also in the Wikipedia article). That is a claim about the share of generated code, not about whether it was unreviewed, so it says less about vibe coding than it appears to.

The honest summary: the benefits are real for small, low-risk work, and the harms are real for large, high-risk work. The two sides mostly describe different projects.

What makes vibe coding go wrong?

Look at the incidents and complaints above and a pattern appears. Vibe coding goes wrong when four things coincide.

None of those is “the AI wrote it.” They are all about exposure. That is why the useful question is not “is vibe coding bad?” but “what would a mistake cost here, and would I see it?” The vibe coding security guide goes through the specific checks.

How do you make vibe coding less risky?

You do not have to stop. You have to put review back where the risk is. Each step below costs little.

1. Pick low-stakes projects first. No payments, no private data, a small audience you know.
2. Write the expected answers before you prompt. Tests with known results are your review when you do not read code.
3. Keep versions. Commit to Git, or use the tool's history, before every larger change, so a bad step costs minutes.
4. Ask for an explanation. “Explain every file in plain English and flag the three riskiest parts.” Then check those parts.
5. Check secrets and access separately. Ask where each key lives, and test with a second account that one user cannot see another's data.
6. Never give an agent your live data. Use a copy or a test project.
7. Get a human review before real users or real money. Pay someone who reads code to look at the parts that handle payments and accounts.

Review this project for problems. Do not change code; report only.
1. List every secret or API key, where it is stored, and whether it is visible in the browser.
2. For each database table, say who can read and who can write, and which rule enforces it.
3. List the three parts most likely to be wrong and how I could test each.
Use file names and line numbers.

More habits are in vibe coding best practices, and reusable wording is in vibe coding prompts.

Is vibe coding the future?

Nobody knows, and anyone who says so with certainty is selling something. What can be said is narrower. Writing most code through AI tools looks durable: the tools are in wide use, and the major vendors keep building them. Whether people will keep skipping the review is a separate question, and the answer probably varies by what is at stake.

The pattern so far is that the casual end grows, with more people building personal tools, and the professional end absorbs the tools but keeps the checks: tests, review and agents with limited permissions. What agentic coding is describes that professional end, and vibe coding vs traditional coding compares the ways of working. A reasonable bet is not that vibe coding replaces engineering, but that more people get a way to make small software, and that the dividing line is how much the result matters.

If you want to test the method yourself on something harmless, browse ideas on the board and pick a small one; each has a ready build prompt. If you have an idea you would never build, you can post it for someone who will.