Why Vibe To Production Coding Is the Easy Part

A few months ago, a client walked me through a prototype their team had built and I was genuinely impressed with how they’d gone from idea to working demo in a matter of days. The concept was sharp, and the business case basically made itself. I left that meeting thinking they’d be live within the month!

When I checked in three months later, the prototype was still sitting on a server, unshipped. When I asked what had happened, what I heard wasn’t a story about a technical problem; it was about a team that had looked more closely at what they’d built and didn’t love what they found. Bitter pills swallowed as tokens hard-coded into the codebase with no access controls worth the name. Architecture that would buckle under any real load and a cost model that looked reasonable for a handful of users and frightening at a few hundred. It was like a digital optical illusion where the closer they looked, the more they found, and at some point the momentum just stopped.

I’ve thought about that conversation a lot since, because it keeps repeating. Not always with the same details, but with the same shape where a prototype that impressed everyone in the room, and a production system that never quite arrived.

Behind The Work The Demo Doesn’t Show

What the client found when they looked closely is what we find almost every time. Security is usually the first uncomfortable discovery where tokens hard-coded into the codebase, minimal access controls, and nothing resembling an audit trail. In a prototype, these decisions are very much invisible because there’s no real user data at risk here. On the other hand, in a production system handling anything sensitive, which most business systems do, they’re not something you can defer casually.

Scalability tends to come next in the conversation, where the assumptions that made the prototype fast to build- single-instance design, no queuing, no thought given to concurrent requests- are the same assumptions that make it fragile at scale. A system that works smoothly for one user in a demo can fail ungracefully for two hundred real ones, and rearchitecting under load is a different proposition entirely from building clean at the start.

Cost is the one that consistently catches teams off guard, in which a naively designed AI system can be cheap to develop and expensive to run, because LLM pricing is token-based and architectures that pass everything into the model regardless of relevance accumulate costs quickly at scale.

Then there’s testing, observability, and what happens when something goes wrong. Prototypes have none of this because they don’t need it. Production systems need all of it, because the question you would be asking yourself is whether the team will be able to diagnose and fix it when something does go wrong.

Ask Yourself Before Shipping

I’ve started using a simple test when I’m trying to get an honest read on whether something is production-ready. I don’t ask whether version one works; I ask whether version two will be cheap to build.

Sure, it sounds like an odd question to ask before you’ve even shipped, but it’s the one that cuts through. Vibe-coded systems tend to pass the first test just fine, version one ships, users like it, and for a few weeks everything feels great. Then someone asks for a new feature, and that’s when the architecture starts to reveal what it’s made of. Hidden dependencies turn up, and abstractions that worked for the original problem don’t bend to fit the new one. Developers who weren’t there at the beginning don’t want to touch the code, and the ones who were there are honestly nervous about changing it too. What felt like a shortcut turns out to have been a loan taken out against future delivery capacity, and the interest compounds fast.

The fix isn’t retrospective; you can’t bolt good architecture onto a system that was built without it, any more than you can add structural steel to a building that’s already standing. It has to be there from the start in abstractions that fit the problem, a CI/CD pipeline that makes change safe, test coverage that gives developers confidence rather than dread, and enough observability that a production incident becomes a solvable problem rather than a crisis. None of this is glamorous work, and most of it is invisible to everyone outside the engineering team, but it’s what separates a system that can grow from one that slowly becomes unmaintainable.

Version two being cheap to build is the real bar, and it’s the honest answer to whether the first version was built well, or just built really, really fast.

What Happened To The Team From The Beginning?

That team I mentioned earlier? You will be relieved to know that they shipped; yes, it took a few months longer than anyone wanted, and there were some uncomfortable conversations along the way about what they’d built versus what they’d thought they’d built. But what came out the other side was something the team felt good about and something they could extend without dreading it.

The shorter version of this is that the prototype wasn’t a mistake. It was the right place to start; it proved the concept, created alignment across the business, and surfaced requirements that no amount of upfront planning would have found. The mistake was treating it as closer to finished than it was, the way you might mistake a stage set for a real building because it looks right from the front.

A prototype is evidence that something is worth building properly. Being able to make real progress with AI-assisted development right now is when you can understand that and stop seeing the speed of the demo being aligned with the readiness of the system.