Is vibe coding bad?

The verdict, stated plainly

Vibe coding — describing software in natural language and accepting the AI's output without reading it — is not a moral question. It is a review question. The defining trait of vibe coding is not that AI wrote the code; professional teams use AI constantly. It is that nobody read it. Every credible 2026 answer converges on the same split: fine where being wrong is cheap (a prototype you will delete, a script that renames your files, a demo for one investor), dangerous the moment real users, real data, or a second developer arrive — and nobody decided to stop vibing.

The criticism clusters in three places, and Reddit's collective verdict — “no, but” — matches the data. Security: the code works on the happy path while ownership checks, secrets handling, and input validation are quietly wrong. Maintainability: the whack-a-mole effect, where fixing one thing silently breaks another because nobody holds the system in their head. Design consistency: every generation makes independent micro-decisions about spacing, color, and type, so the UI drifts even when the code works. None of these show up in the demo. All of them show up in production.

One boundary matters for honesty: as Simon Willison has argued since the term went viral, not all AI-assisted programming is vibe coding. A senior engineer prompting Claude Code and reviewing every diff is doing AI-assisted engineering. The phrase escaped its cage in 2026 and now gets pinned on every prompt-driven workflow — which is exactly how teams talk themselves into vibe-coding things that should never be vibe-coded.

The 2026 evidence — every major measurement in one table

Eight independent measurements, mostly vendor or academic but mutually consistent. Verified against the 2026 sources; re-check before quoting — several vendors update these annually.

Read the pattern, not any single number: the models got dramatically better at working code (95%+ syntax correctness) while security pass rates stayed near the floor. Pretty code can still be unsafe code — and the failure classes (missing security headers, SSRF, XSS, broken access control, exposed secrets) are the boring, known, scannable ones.

Where vibe coding is genuinely good

The honest case for the practice, from the practitioners who defend it without hype:

• Throwaway prototypes you will delete in a week — reading every diff is a waste of your life; the whole point of throwaway code is that it is throwaway.
• Personal and single-user tools — a workout tracker, a file-renaming script, a dashboard only you look at; the worst-case bug is mild annoyance.
• Idea validation — a working demo in an afternoon instead of two weeks, shown to ten potential customers before an engineering budget exists.
• Spikes and spikes only — answering “is this even worth building?” before committing real hours.

The trap is the 70% wall: AI gets you most of the way to a working thing fast, then every new feature starts breaking two old ones. Nearly everyone who builds this way hits it. The validation work survives the kill — user flows, edge cases, the data model — but the code usually should not. Keeping the prototype alive as the product is the single most expensive decision in the workflow.

The incident ledger — what “bad” looks like in practice

Five documented 2025-2026 incidents, none caused by clever attackers — all caused by codebases nobody could read or audit. Cited from the vendors' own disclosures and contemporaneous reporting.

The scariest class does not make headlines: silent business-logic failure. A transfer endpoint that accepts a negative amount. A retry that double-sends a receipt. Customer A seeing customer B's records because one ownership check was assumed rather than written. A crash announces itself; these do not — they ship looking finished.

The real bottleneck: verification, not generation

The sharpest 2026 framing of the debate: the model is no longer the constraint — you are. Models now produce more plausible code than any human can carefully review, so the limiting factor stopped being “can the AI write it” and became “can a competent human verify it fast enough.” The evidence agrees from both ends: evaluated frontier models find only a subset of the issues human reviewers identify (SWE-PRBench), AI PRs queue ~4.6x longer because trust is low, and “more AI” mandates produced larger PRs and more defects as review coverage fell behind.

Which is why the mature 2026 answer to “is vibe coding bad” is procedural, not moral: treat AI-generated code as an untrusted contribution — the same control set you would apply to any external contributor you did not personally vet. The fix is structural, not behavioral. Prompting for secure practices helps; it does not remove the need to verify, because the models optimize for “working” long before they optimize for “defensible.”

Ship vibe-coded apps without the bad parts

Seven gates cover the measured failure classes. The full 15-check version lives in our vibe coding security checklist.

1. SAST on every commit, not just release cuts — the CSRF/SSRF/XSS/log-injection findings are exactly what scanners catch.
2. Secrets scanning pre-commit — the cheapest category to catch, and the one AI doubles the rate of.
3. Dependency + SBOM checks — models recommend hallucinated or typosquatted packages; attackers register the names preemptively (slopsquatting).
4. Human review gate for auth, authorization, crypto, and any path touching untrusted input — the categories where plausible-but-wrong is hardest to automate.
5. Tests before the feature — AI-authored tests pass while exercising only the happy path; the edge cases you have not thought of are the ones that page you.
6. Small verifiable patches over “regenerate the whole billing layer” — a patch has a defined before and after an agent can verify; a vibe has neither.
7. Read the diff before it ships — if you cannot explain the change to a colleague, it is not ready; that single rule subsumes most of this list.