Is Vibe Coding Bad? When It Works (And When It Doesn't)

The phrase "vibe coding" started as a joke and became a workflow. Ask an AI to build something, squint at the output, describe what feels wrong, repeat. It's fast, it's fun, and for a certain class of work it's genuinely productive. But the question "is vibe coding bad" doesn't have a yes-or-no answer. It has a where answer. Vibe coding is fine for some things and quietly catastrophic for others, and the line runs straight through the middle of anything you plan to ship as a real product.

What Is Vibe Coding (And Why Developers Keep Arguing About It)

Vibe coding is letting an AI generate code without detailed specs, then iterating on feel. You don't write an architecture document. You write a prompt, look at the result, and nudge it toward what you want.

It exploded because Claude and GPT made it feel frictionless. The term itself was coined by Andrej Karpathy, who described it as giving in to the vibes and forgetting the code even exists. Prompt engineering replaced the architecture doc for a lot of people.

The appeal is real. Fast feedback loops. Discovery-driven development where you learn what you want by seeing it. A much lower barrier for solo builders who never had a team to lean on. None of that is fake. The problem is what happens after the vibe becomes a codebase.

The Real Problem: Instructions Become Obsolete Instantly

Here's the uncomfortable part. The moment an AI generates code from your prompt, that prompt becomes a historical artifact. It's not documentation. It's a fingerprint of a decision you can no longer see.

The code becomes the only source of truth for what the system does. But code doesn't explain why a decision was made. It doesn't tell you that the refund path assumes webhooks arrive in order, or that a particular query only works because a row-level security policy is written a certain way.

For a solo weekend project, that's survivable. For a SaaS with billing, auth, and webhooks, it's a slow-motion disaster. The answer isn't to stop using agents. It's to give them a contract that survives iteration — which is exactly why BoiledPlate ships an AGENTS.md file that documents one way to do data access and secrets, so the agent can't quietly invent a fourth.

Where Vibe Coding Fails Hard

The failures cluster around anything with state.

• Billing. Stripe webhook idempotency breaks the instant you regenerate the handler on a vibe. Refund logic drifts. Your checkout success page starts touching billing state it should never touch.
• Auth and RLS. Row-level security needs deliberate schema design, not experimentation. Vibe-coded policies leak data.
• Multi-tenant data. One wrong policy and customer A sees customer B's records, or you orphan rows nobody can reach.
• Email flows. Transactional email needs idempotency keys so a retried webhook doesn't send the same receipt twice. Vibes ignore this.
• Deployment and config. Environment variables and secrets scatter across a dozen generated files with no single owner.
• Consent. EU withdrawal law, GDPR, cookie consent — vibes get these wrong immediately, and the mistake is a legal one, not a compilation error.

Why Vibe Coding Works for Toys, Fails for Products

The difference is invariants. A product has things that must always be true: billing state is consistent, tenant data is isolated, audit trails exist. Vibe coding treats code as disposable. Products treat code as fragile and in need of guards.

Personal projects reward speed because a bug costs you five minutes. SaaS punishes surprise refactoring because a bug costs you a customer, a chargeback, or a regulator's attention. The dichotomy people reach for — "vibe coding versus six-month waterfall" — is false. The real choice is between intentional architecture and expensive bugs.

The Imposter Syndrome Trap

Vibe coding sells a comforting lie: you don't need to understand the full stack. The AI has you covered.

The reality is the opposite. You need to understand it more, because the AI won't catch your domain errors. It doesn't know your business rules. An agent vibe-coding a SaaS won't independently invent Stripe's signature verification or reason correctly about Supabase's RLS model — those are specific, non-obvious contracts.

This is where explicit conventions break the cycle. An agent handed clear constraints stops guessing. Without them, it pattern-matches against every bad tutorial it has ever seen and adds its own fourth way of doing things.

Vibe Coding vs. Deterministic Patches

There's a better model than "regenerate the module until it feels right." Deterministic patches: code changes that are repeatable, reversible, and documented.

Patches read like instructions. They're auditable. They don't drift, because they describe a specific transformation rather than a mood. Adding a new Stripe product should be a discrete, verifiable patch — not "regenerate the whole billing layer while I describe the vibe I want."

Agents actually prefer this. A patch has a defined before and after they can verify. A vibe has neither. BoiledPlate's setup interview reshapes the codebase to your answers with deterministic patches precisely so nothing depends on the agent's mood on a given afternoon.

The Uncomfortable Truth: Speed vs. Rigor Isn't Binary

You do not choose between vibe coding and endless architecture reviews. You choose between documented iteration and undocumented chaos.

Fast shipping with RLS and webhook idempotency intact is entirely possible — if you have a contract. The contract is what lets speed and rigor coexist. Automate the plumbing, but make the automation verifiable.

Small Projects vs. Shipping SaaS: When Vibe Coding Works

Vibe coding is genuinely fine for:

• CLI tools, scripts, internal utilities
• Throwaway prototypes you build to learn something
• Solo exploration with no external dependencies

Vibe coding breaks for:

• Anything with state — databases, webhooks, billing
• Code that other developers will inherit
• Code an agent needs to update safely six months later
• Anything involving customer data or payment flows

If your project is on the first list, stop reading and go vibe. If it's on the second, keep going.

Why AI Agents Amplify Vibe Coding's Failures

Agents follow patterns. Vibe code has no pattern to follow — it's a pile of one-off decisions with no through-line. So the agent invents one, and now you have two conventions where you wanted one.

Agents also can't ask about implicit decisions. They don't know that a webhook must be idempotent unless something tells them. They won't invent signature verification, correct RLS policies, or refund idempotency on their own. The fix is a standard, not more vibes.

Building SaaS Without Vibe Coding: The Plumbing-First Approach

Flip the order. Start with service provisioning, not code generation.

Establish RLS, Stripe webhooks, and email transactionality before the business logic. Let the agent wire services deterministically instead of guessing at configs. Then document the decisions so future changes don't quietly break assumptions. As BoiledPlate's team puts it, the stack picks itself — the plumbing is the actual project. Building that plumbing first is what makes the fun part safe.

What Shipping a Real Product Teaches You About Vibe Coding

Real bugs teach faster than any argument. From actually shipping:

• A JSON-LD hydration crash that returned 200 on the server and 500 in the browser, traceable to source order and canonical URL config.
• Refund logic that only works if webhooks arrive in order — see why some webhook failures must throw and some never can.
• A German withdrawal waiver that has to be encoded into the pay button, or you carry regulatory risk.
• Peer dependency conflicts that surface six months later, long after the vibe that caused them.

The lesson is consistent: plumbing mistakes are expensive, and vibes don't catch them.

The Honest Take: When to Use Vibe Coding, When Not To

Vibe coding is a delivery mechanism, not a philosophy. Use it for rapid discovery, throwaway code, and learning. Don't use it for anything you'll ship, anything with state, or anything others will touch. The better alternative for real work is structured iteration with documented conventions.

How to Ship Fast Without Vibes

Speed doesn't have to come from abandoning structure. It can come from automation:

• Provision services in one session — the agent interviews you, then wires Stripe products and webhooks, a Supabase database with RLS, and Google sign-in.
• Customize with deterministic patches instead of regenerating.
• Keep an agent-readable contract so updates happen safely half a year later.

That's the whole bet: everything a paid product needs on day one, wired once and documented, so the fast part stays fast.

The Real Cost: Technical Debt vs. Upfront Investment

Vibe coding is fast in month one and exponentially slower after, as undocumented decisions pile up. A structured approach is slower in week one and then linear — the cost of change stays flat because the assumptions are written down.

You will have bugs either way. The only question is whether they're discoverable or hidden. Vibe coding hides them behind confident-looking code. A contract like AGENTS.md drags them into the open where you can actually fix them.

So — is vibe coding bad? No. It's a tool. It's bad the same way a chainsaw is bad in a nursery. Use it where the stakes are low and the state is disposable. Everywhere else, give your agent a contract and let the plumbing be automatic and verifiable.