← GUIDES

Is vibe coding bad? An honest answer from someone who ships with it

By Leon Mallett · Updated 8 October 2026 · 4 min read

Short answer: no. But unreviewed vibe coding is, and the difference only shows up when something goes wrong.

I built Vibe Leagues, the site you're reading, almost entirely with an AI coding agent. It's a real web app: accounts, a database, a public API, security headers, a deploy pipeline. In the last few weeks alone the project hit four mistakes, some written by the agent and some by me, that would have hurt real people. None of them reached the live site. Here's what they were, and what caught each one, because the catching is the whole answer to the question.

1. The database change that would have deleted every reaction

I asked for one new column on the post table. The migration tool generated something much bigger: create a new table, copy every row across, drop the old table, rename the new one.

That's a normal pattern in SQLite. On Cloudflare's D1 it's a trap. The script switched foreign keys off first, but D1 ignores that, so dropping post would have cascaded and deleted every reaction and every moderation flag on the site. The copy step would also have failed outright, because it read a column that didn't exist yet.

What caught it: reading the generated SQL before running it against production, then testing it on a throwaway copy with fake data in it. One post, one reaction and one flag went in; one, one and one came out. The fix was a one-line ALTER TABLE … ADD COLUMN.

The lesson: generated migrations are code, and they're the code most likely to destroy data. Read every one.

2. "Node 24" became Node 4.9.1

The first production build failed within seconds. I'd set the build's Node version to 24. The build system resolved that to Node 4.9.1, a release from 2018, whose package manager couldn't even install the project.

What caught it: the build log, read line by line rather than skimmed. It said exactly what it had installed.

The lesson: pin exact versions (24.16.0, not 24) anywhere a machine has to interpret them.

3. A deploy that silently never happened

A security fix merged cleanly. Every test passed. Nothing deployed. Cloudflare never started a build for that commit: no error, no failed build, just nothing.

What caught it: checking the live site after every merge instead of assuming. The fix wasn't there, so I went looking, and found that the commit had no build check at all, where every previous one had.

The lesson: "merged" isn't "live". Check the thing you shipped, on the real site.

4. Sign-in that worked perfectly and was still unsafe

The first version of sign-in did exactly what it was asked: email, password, a session. It also allowed unlimited password guesses. It let anyone test invite codes for free just by loading a page. And it answered faster for email addresses that didn't exist, which quietly revealed who had an account.

None of that is a bug a test would catch, because nothing was broken. It took a deliberate review with a security question in mind: what could someone do here that I wouldn't want?

The lesson: an AI writes what you ask for. Ask the questions it won't ask itself.

So is vibe coding bad?

Every one of those mistakes would have happened to a human developer too. Migration footguns, version traps and silent pipelines aren't AI problems. What vibe coding changes is the speed: you can produce a month of code in a day, which means you can produce a month of unreviewed risk in a day.

So the answer isn't "don't". It's to put a few cheap habits around the speed:

  • Read anything that touches data or money before it runs. Migrations above all.
  • Prove your tests can fail. Break the code on purpose and check the test catches it. A test that can't fail is decoration.
  • Write your rules down where the agent reads them. Vibe Leagues has a file of invariants the agent loads every session: "reactions are positive-only", "no open sign-up". It stops whole classes of mistake.
  • Make the agent ask before anything irreversible: deploys, production database changes, deleting things.
  • Check the live site after every change.

None of that slows you down much, and it's the difference between vibe coding and gambling.

When it really is bad

Vibe coding is a bad idea if you ship code you haven't read into anything that handles money, health data, or other people's private information, and you have no tests and no way to check the result. That's not a tooling problem. It's shipping blind, and it was a bad idea before AI too.


This is the kind of story Vibe Leagues exists for: what actually happened, including the bits that nearly went wrong. If you're building with AI, the failures are the most useful thing you can share. Request an invite and tell yours.