Is vibe coding bad? For a throwaway experiment, it can be a useful way to get an idea onto a screen. The risk grows when you start trusting code you haven’t checked, especially if other people’s data, money, or work depends on it.
A page can look finished while its save button loses information. That’s the gap I’d pay attention to before arguing about whether the method counts as “real coding.”
You can use AI to write code and still take responsibility for how that code behaves. The difficult part is knowing when an experiment needs more than another prompt.
For a small practice exercise, try Diffective, a free debugging game. You inspect a coding agent’s report and find the claim its evidence doesn’t support.
What people mean by vibe coding
People use the term for different things, which makes the argument confusing. Someone may mean asking an assistant for a small function and reviewing every line. Someone else may mean accepting whole changes without reading them.
Simon Willison makes that distinction in his explanation of the original term. His narrower definition describes building with a language model while leaving the generated code unreviewed.
He separates that from AI-assisted work where the developer understands and checks the result. Read his explanation.
I’ll use the narrower meaning here. The concern is accepting software you can’t meaningfully evaluate. Asking an AI tool for help doesn’t automatically put you in that position.
When vibe coding is a reasonable experiment
It makes sense to try it when the project is small, the inputs are disposable, and a failure is easy to undo.
Think of a color-palette experiment using invented data, a layout mockup, or a small puzzle running in an isolated test environment. You can judge whether the idea is interesting before investing in a complete product.
Keep the experiment away from real customer records, payment systems, production credentials, and your only copy of important files. “It’s just a prototype” doesn’t protect those things if you connect them to it.
You can also use the experience to learn. Pick one small change, ask what each part does, and check the explanation against the actual result. The learning comes from that follow-through, rather than the number of files generated.
Is vibe coding bad for a real project?
The trouble starts when visible progress becomes the only test of success. A button appears, a warning disappears, or a chatbot reports “done,” and it’s tempting to move on.
GitHub documents that its agents can produce code that appears valid but behaves incorrectly, along with review suggestions that may miss or misidentify problems. It recommends careful review and testing. GitHub’s agent limitations.
That’s a useful limit to remember when any assistant sounds certain.
The demo only covers the easiest path
A feature can work with one example and fail with another. A form accepting a tidy test entry tells you little about a blank field, a lost connection, or a person pressing Submit twice.
Here’s a made-up example. You ask for a reading list that remembers saved books. A book appears when you press Save, so the demo looks successful. Refresh the page and the book disappears. The screen updated, but the information wasn’t stored.
The next useful test is obvious once the requirement is written clearly. Add a book, refresh, and confirm it is still there. “The Save button works” is too vague to catch the mistake.
A fix removes the symptom
An error disappearing doesn’t always mean the underlying problem was fixed. A program could hide an error message while continuing to fail in the background.
Check both the intended success and the expected failure. If a file import should reject an unsupported file, try one in a test environment and confirm that the original data stays intact.
Read the output too. A message saying an import finished isn’t the same as a count showing which records were actually imported.
The project grows faster than you can explain it
Every new feature can introduce another dependency or assumption. Eventually, a request to change one screen may touch files you didn’t know existed.
That’s a good point to stop adding features. Ask for a map of the parts involved, check it against the project, and reduce the next change to something you can review.
If you can’t describe what the change does or how to reverse it, another large rewrite is unlikely to make the situation easier to understand.
“Done” becomes a substitute for evidence
A completion report is useful when it points to something you can inspect. It becomes misleading when “tested” means a test was written but never run, or a successful build is presented as proof of the whole user journey.
Ask for the exact check, its actual result, and anything left untested. A clear admission that a check couldn’t run is more useful than a confident sentence that hides the gap.
A practical checkpoint before you trust the result
Use a small, repeatable review process. These steps are a starting point for an ordinary prototype, not a complete security audit or a guarantee of release readiness.
- Write one observable requirement. For the reading list, saved books must still appear after refreshing the page. Define what should happen with a duplicate too.
- Keep a recoverable copy. Save the known working version before the next change. Use version control or a separate backup you know how to restore.
- Make one bounded change. Keep unrelated redesigns and new features out of the same repair so you can tell what caused a regression.
- Inspect the actual result. Read the changed code where you can. Run the user journey, rather than stopping when the assistant says it is complete.
- Try a failure case. Use safe test data to check an empty input, a canceled action, or another relevant boundary. Confirm existing information survives.
- Check the report against the evidence. Separate code written, checks run, checks passed, and checks not run. Don’t let those become one “done” label.
- Get help where the stakes exceed your skill. Have a qualified person review sensitive areas before connecting real users, accounts, payments, or private data.
Version control helps you recover an earlier state. It won’t tell you whether the new state is correct. You’ll need both recovery and verification as the project becomes more important.
If you also need to establish where a piece of code came from, how to tell if code is AI generated explains which evidence helps and why detector scores need caution.
A prompt that asks for a checkable review
Give the reviewer a specific job and ask for evidence. You can use this with a coding assistant, but you still need to inspect the response and run the relevant checks.
Review this change against the requirement below. Do not edit files yet. Explain which changed lines implement the requirement, which assumptions could be wrong, and one realistic input or action that could break it. Separate checks you actually ran from checks you are only proposing. If you can’t verify a claim, say what evidence is missing. Requirement: [write the behavior you expect].
That prompt won’t make the assistant infallible. It does give you a more useful review to question than “Looks good.” There are more fill-in templates on the Free AI Prompts page, including prompts for examining claims and challenging a plan.
When the agent says a change is finished, Agent Receipt can compare that message with your test output and diff. Use its labels to identify claims that need checking, then review the code and its behavior before merging or launching.
Turn that review habit into a debugging game
I built Diffective around a small part of this process. It presents an AI coding agent’s task, three claims about the finished work, and evidence from code changes or terminal output.
Your job is to identify the claim that isn’t supported, point to the evidence, and name the trick. It’s a free browser game with a guided tutorial and short cases. You don’t need an account.
The aim is to make checking a confident report feel like solving a puzzle. It won’t review your own app or certify that an AI-built product is safe to launch.
So, is vibe coding bad? It depends on what you’re trusting it with and how you check the work. Try the small experiment. Enjoy getting an idea working. Before anyone relies on it, make sure you can explain what it does, show that it works, and recover when it doesn’t.
Practice spotting an unsupported claim in Diffective, then bring that habit back to the next change you review.
