I vibe-coded into a corner — here's the climb out

I vibe-coded a feature into a corner I couldn't see the edges of. This is the field note on how it happened, what it cost, and the cheap habit that climbed me out — and now keeps me out.

How it started: no brief, just vibes

It was a Friday and I wanted to move fast. So I skipped the brief and just talked to the agent. "Add a referral system." It built something. "No, make referrals give a discount." It adjusted. "Actually, let the discount stack with promotions." It adjusted again. No spec, no criteria, just me steering by feel, change after change.

This is vibe coding — building from a vague feeling rather than a specification. For a throwaway prototype it's genuinely fine. I wasn't building a throwaway.

Where it drifted

By change six, the feature had quietly become incoherent. The discount stacking I'd asked for conflicted with a refund rule from weeks earlier. Referral credits could, in one path, exceed the order total. None of it was obviously broken — every individual change looked reasonable when the agent made it. That's the trap. The drift is invisible step to step, and only visible once you're deep in it.

Stuart Leo

Vibe coding fails quietly. Each change looks fine. The incoherence only shows up once you're too deep to see the edges.

The spec-driven crowd has the cleanest name for this: agents produce plausible code that drifts from intent when there's no spec holding the line. That was exactly my Friday.

The cost of plausible-but-wrong

The expensive part wasn't the bad code. It was that I trusted it, because it ran and looked right. I shipped it to staging before the referral-credit hole turned up in testing. Unwinding six layers of vibe-driven change cost me more than writing the thing properly would have in the first place. Plausible-but-wrong is the most expensive output an agent produces, because it passes the glance test.

Rebuilding from a brief

The climb out was boring and fast. I stopped, deleted the feature, and wrote a short brief first — what a referral does, what it explicitly does not do, and a handful of acceptance criteria I could actually run:

- A referral gives the referrer a fixed credit, once, on the referee's first paid order.
- Credit never exceeds the order total.
- Referral credit does NOT stack with promotional discounts.
- Test suite covers all three rules and passes.

With that in front of it, the agent built the feature once, cleanly, and verified it against the criteria itself. The whole rebuild took less time than the vibe-coded version had taken to debug.

The line I won't cross again

I still vibe-code — for spikes, throwaways, exploring an idea. But the line is bright now: the moment it's something I intend to keep, it gets a brief with criteria I can run, first. The brief takes five minutes. The corner took an afternoon.

Vibe coding is fine until it isn't — a brief with runnable criteria is the cheapest insurance you'll buy.

Start here: learn to write acceptance criteria your agent can check, see C² vs spec-driven development, or read the method.