I build with AI every day. I describe what I want in plain language, and working code appears in minutes. It is genuinely one of the most important shifts in how software gets made in twenty years — and I say that as someone who has shipped software the slow way for most of those twenty years. It is also where most AI projects quietly die. Because a thing that runs on your laptop and a thing a business can depend on are separated by work the demo never shows you.

"Vibe coding" — steering a model through a build in natural language instead of typing every line — is real, and I use it without apology. The mistake isn't using it. The mistake is believing the prototype it produces is the product.

The 80/20 inversion

On a normal software estimate, the visible feature is most of the work and the plumbing is the rest. Vibe coding inverts that. The visible demo is maybe 20% of the real effort and 80% of the perceived effort. The remaining 80% — architecture, tests, deployment, monitoring, ownership — is invisible in the demo and is precisely what separates a toy from a system.

This is why so many executives feel misled. They watched a working app get built in an hour and reasonably concluded the project was nearly done. It wasn't. They saw the deck of the bridge. They didn't see that there was nothing underneath it yet.

A bridge from a vibe-coded demo to a production system. The deck is built from five planks: architecture, tests, deploy, monitoring with rollback, and ownership. Below is the gap of work the demo skips. crossing from prototype to production the work the demo skips Vibe-coded demo Production system Architecture Tests Deploy / CI Monitor + rollback Ownership
The bridge. Vibe coding builds the two platforms — the idea and a working demo. Delivery is the deck between them. Leave out a plank and people fall through it at the worst possible moment.

What actually separates a demo from a system

The gap isn't about code quality in the abstract. It's about a set of very concrete conditions the real world imposes and a demo doesn't.

A demo

  • Runs once, when you press play
  • On clean input you chose
  • On your machine
  • No accounts, no permissions
  • Fails silently or crashes
  • Only its author can fix it

A production system

  • Runs continuously, unattended
  • On messy, hostile real input
  • On infrastructure others depend on
  • Knows who's allowed to do what
  • Fails safely, logs, and alerts
  • Owned by a team that can change it

The five planks

  • Architecture. Where state lives, how data flows, what breaks at ten times the load. Vibe coding optimises for "works now," not "works at scale" — that's your job to impose.
  • Tests. The safety net that lets you — or a model — change the code later without silently breaking what already worked. Without tests, every improvement is a gamble.
  • Deployment / CI. A repeatable, reversible way to ship. "I copied the files onto the server" is not a deployment strategy; it's a future incident.
  • Monitoring & rollback. You should find out something is wrong before your customer does — and be able to undo it in minutes, not rebuild it overnight.
  • Ownership. A named human or team accountable for this system next quarter. Software without an owner rots, and AI-generated software rots faster because nobody fully read it.
The rollback test

I ask one question of any "finished" AI prototype: if this breaks at 2am, can someone who didn't build it understand it, find the problem, and roll it back safely? If the answer is no, it isn't a production system — it's a demo wearing a production costume.

Vibe coding got us to a working prototype in an afternoon. The other 80% is why your team can still rely on it next year.

How to use vibe coding well

None of this is an argument against AI-assisted building. It's an argument for using it deliberately. The right move is to let vibe coding do what it's extraordinary at — exploring fast, proving an idea is worth doing, and learning what the real requirements are — and then to consciously cross the bridge for the parts that have to be durable.

Concretely: prototype freely, but don't ship the prototype. Harvest what it taught you, decide which parts the business will actually depend on, and rebuild those with architecture, tests, and an owner. The prototype's job was to earn the right to build the real thing. Once it's done that, let it go.

Have a prototype that needs to become real?

I take AI-assisted prototypes the rest of the way — architecture, delivery, and an owner your team can rely on. See Custom AI Applications and Software Project Design, or book a call.