Is Vibe Coding Bad? Where It Works and Where It Goes Wrong

You can vibe code something useful, and this guide shows where the line is. Is vibe coding bad? Not by itself. It works well for small, low-stakes projects and for testing an idea cheaply. It goes wrong when an app handles money or private data and no one looked at what the AI built.

You will hear 2 loud answers to this question: "it's the future" and "it's a mess." We think both skip the useful part. Here is a plain-English middle path for founders and builders.

What did vibe coding mean when it started?

In a post on X shown as 11:17 PM on 2 February 2025 (read 8 October 2026), Andrej Karpathy described giving in to the "vibes" and forgetting the code exists: he accepts every change, does not read the changes, and pastes in error messages with no comment, which he says usually fixes it. He called that approach "not too bad for throwaway weekend projects," and we read that as a relaxed way to build something for fun, not a plan for running a business. Merriam-Webster defines vibe coding as using an artificial intelligence system to generate computer code, and says the term was apparently introduced in that post (read 8 October 2026).

Is vibe coding bad for every project?

No. The honest answer depends on 2 things: what happens if the app is wrong, and whether anyone checks it.

If a mistake costs you an annoyed afternoon, the risk is small. If a mistake means a customer is charged twice, a visitor sees someone else's information, or a promise on your page is false, the risk is real. The same prompt and the same tool can produce a harmless toy or a liability. The stakes decide.

That is also why we don't treat "vibe coded" as an insult. A hand-built app that nobody tested can be just as bad. What changes with AI is the speed: you can ship something that looks finished before you have checked whether it is.

Where does vibe coding work well?

The vibe coding pros and cons mostly come down to the cost of being wrong. It works best when that cost is low or the cost of waiting is high. Here are 4 places we think it earns its keep:

1. Throwaway and personal tools. A scheduler for your own household, a one-off calculator, a page for an event that ends on Sunday. If it breaks, you shrug.
2. Testing an idea before you spend real money. A rough working version you can put in front of 5 people teaches you more than a plan does.
3. People who do not write code. A founder or builder with an idea can now get to something that runs, which is often enough to learn from.
4. Pages and small apps with simple jobs. One clear purpose, a few screens, no sensitive data.

Our guide to building a small first app covers how to keep it that small.

What are the real vibe coding risks?

Here are 5 vibe coding risks to look for. Each one is a skipped step, not a failure of the tool.

• Nobody reads what changed. Accepting every change unread, as Karpathy described, is fine for a toy. For a real app, a change you never looked at can quietly break something else.
• The app grows past anyone's understanding. Karpathy said the code can grow beyond his usual comprehension. When you cannot say what the app does, you cannot say whether it is safe or right.
• It looks finished before it is. AI makes it fast to build something that looks complete but isn't. A tidy page can hide a button that goes nowhere or a form that fails.
• The stakes outgrow the checking. An app that began as a weekend experiment starts collecting emails, then payments, and the care never catches up.
• Nobody asked what a customer sees. The builder knows what they meant. A visitor only has the page.

For the security side, our guide on vibe coding security owns the details, so we won't repeat them here.

What does a good and a bad version look like?

Hypothetical example: a weekend hobbyist builds a pet-sitting scheduler for friends and neighbors. Same idea, 2 ways to do it.

Version A, the careless one. The hobbyist asks for the whole app in a single message, accepts everything, and shares the link in a neighborhood group that evening. The headline says "Revolutionize your pet care journey." The page says bookings are free, but the booking step shows a fee. Choosing a second pet clears the dates already picked. Nobody has tried booking a sitter from start to finish, so the first neighbor to try gives up and sends a text instead.

Version B, the same tool, more care. The hobbyist writes down the one job first: "A neighbor picks a day and a sitter, and the sitter gets an email." They ask for one change at a time and look at each one. They book a test visit on a phone and on a laptop, rewrite the headline to say what the page is for, make the fee clear before the "Book now" step, try booking 2 pets in one visit, and then share the link. Nothing about the tool changed. The difference is that someone checked.

Both apps were vibe coded. Only one was cared for.

What separates a good vibe-coded app from slop?

We use "slop" for work that looks generated instead of made, and our guide on what AI slop is owns the full definition. For this question, 4 habits separate the 2 outcomes:

1. Someone decided what it is for. One job, in one sentence, before building.
2. Someone looked at the changes. Not every line of code, but the app after each change.
3. The checking matches the stakes. A toy gets a quick test. An app with payments or private data gets a real review.
4. Someone used it like a customer. Start to finish, on a phone, without the builder's inside knowledge.

None of these needs you to read code. Our guide to vibe coding best practices turns the first 2 into daily habits, and AI slop examples shows what the missing ones look like on a page.

How can you check your app the way a customer would?

Open your own link on your phone and try to do the one thing the app is for. That alone catches a lot. For a more thorough read, we built the audit around the same idea.

It is an AI audit scored against a fixed rubric. It clicks through your public pages the way a customer would, and may submit your forms once with clearly labeled test details. It reads the rendered page plus desktop and mobile screenshots, and runs an AI generator fingerprint check for the marks AI builders tend to leave behind.

Every app gets scored on the same six things, and the report gives a score out of 100 with fixes ranked by what to do first. Each dimension lists what works and what reads as slop. In the same made-up example, the headline that could describe any pet service is the kind of thing a "Slop tells" field is for. The fee that shows up after a promise of free bookings would be a finding under Conversion and The Ask, which looks at whether the price is shown before the ask. The cleared dates would be a finding under Flow and Usability. For Version B, "What works" could credit a headline that says who the page is for.

The audit works on public pages only, so it cannot see anything behind a login. It is not a security review or a full accessibility audit.

When should you bring in a developer?

When you can no longer explain what the app does, when the same bug keeps coming back, or when fixing one thing keeps breaking another. Those are signs the project has outgrown prompt-and-hope. If the app holds payments or private data, our vibe coding security guide covers when to call a real reviewer.

So, should you vibe code?

If you are a founder or builder with an idea and no developer, yes, with care. Use it for the first version, keep the first version small, and match your checking to the stakes. If the app is a toy, relax. If it takes money or holds private data, slow down and get a real review.

Vibe coding is a way to build quickly. It is not a way to skip looking. The builders who do well with it are the ones who look.