“It worked locally” has a new relative: “it worked in the demo.” A product described a week ago and stood up in minutes, with its first users already on board — then the first real load arrives and it slows to a crawl, the first curious user sees someone else’s invoice, the first schema change blows up in a migration. The person who built it is surprised: the code was working.

It was. But what vibe coding lowered was the cost of production; not the cost of being wrong. That cost is deferred, not erased — and deferred cost charges interest.

What vibe coding genuinely makes cheaper

Let’s not strawman it. Shipping a first version has never been cheaper: a CRUD screen, a REST endpoint, a form validation — describe it, watch it work. For a prototype, a throwaway, an internal tool, a learning project, it’s a brilliant accelerator.

There’s exactly one thing it doesn’t make cheaper: the price of being wrong about the data model, the security boundary, and the failure mode. If those three are wrong in production, the bill comes not at build time but much later — usually at 2 a.m.

The bill shows up in production, not at build time

Four patterns I see again and again in systems shipped with vibe coding. None of them are the “code won’t compile” kind; they all live in the gap between intent and reality.

1. A data model that can’t migrate. A NOT NULL column added to a populated table, with no DEFAULT. Fine on an empty table, a failure on the production one. Deeper still: a schema with the wrong relationships makes a trivial feature impossible six months later. Fixing the data model afterward isn’t a refactor — it’s a data-migration risk, done at the most expensive moment, with real data.

2. Security that never accounted for adversarial input. Object IDs that pass the identity check but not the ownership check (IDOR), user input reaching a query, secrets hardcoded into the source. The “standard” solution the agent produced doesn’t assume the input could be hostile — because the question it was asked was “make this work,” not “make this withstand an attack.”

3. An access pattern that ignores scale. A query inside a loop (N+1), SELECT *, an unpaginated list, a synchronous call where it should be async. Invisible on a ten-row table; it wrecks your p95 at a hundred thousand.

4. A system you can’t observe or roll back. No logs, no metrics, no rollback plan. When it breaks, you can’t see why — which is exactly what you’ll need most in a vibe-coded system.

The common denominator: the tool is most dangerous where it looks safest. It writes common patterns solidly; it produces a “standard” solution without seeing the problem’s unique dimension. A standard solution is the answer to a problem you didn’t ask.

What sets output quality: not typing speed, but review

Picture the same agent in three different hands. The difference isn’t who has it type faster; it’s the quality of the question asked and the review performed.

  • Little to no knowledge. Can’t frame the question, can’t read the output critically. The “standard solution” ships to production as-is, together with the four patterns above. Can’t yet feel the difference between “it works” and “it works correctly.”
  • Low-to-mid knowledge. Frames some questions right, catches part of the output. The ceiling is at the system’s boundaries: where it breaks under load, whether this abstraction is right, what change the data model tolerates. Result: good pieces, a fragile whole.
  • Senior + systems architecture. The agent is a multiplier, not a substitute. Have it plan → approve → write step by step → review like a junior’s code → don’t merge a line you can’t defend. The concrete form of that discipline is its own post: My AI-Assisted Engineering Workflow. In these hands, speed rises and quality holds — because the reasoning stays in a human.

This is a budget statement, not an ideology: a senior is the cheapest insurance against deferred cost. Building the right data model up front is an afternoon; fixing the wrong one on a live system is a quarter. “We’ll fix it once we make money” is absurd for this reason — the product that makes money is also the one that ties your hands, the one whose migration is riskiest. A senior is cheaper before, not after.

When is vibe coding the right answer?

Like any recommendation, this one has an expiry — and I won’t make a recommendation without stating its limit.

Vibe coding is the right tool for: a prototype, a throwaway demo, a hobby, an internal tool with no real data or users, learning. There, the cost of being wrong is low, so deferring it is rational.

The equation flips the moment one of three things comes to the table: real users, real data, real money (or a real uptime commitment). Past that threshold, deferred cost starts charging its interest, and you need someone holding the wheel.

Producing with AI agents is possible, and genuinely fast. But the agent changed who writes the code, not who’s responsible for it. Vibe coding made production cheaper, not being wrong — and that cost looks at whose hands shipped it to production.