After the AI build: what happens when the vibe-coded app meets reality

AI-assisted development is real and I’m glad it exists. Companies that could never afford custom software are building it. Teams are shipping in weeks what used to take quarters. That part of the story is genuinely good.

This post is about the second chapter, because I’m starting to see it walk through our door.

A company spends a year building with AI tools. Something launches. Customers use it. Then the cracks: it can’t handle the load, nobody can explain how the pieces connect, a security review turns up things that make everyone quiet, and the person who “built” it can’t fix it because they never really understood what the AI wrote. The app exists, but the engineering underneath it doesn’t.

I think this market comes online in a big way over the next year. Not because AI tools are bad, but because building software was never the hard part. The hard part is architecture, security, and operations, and those don’t come free with the code.

A tool on a bad system amplifies the bad system

One of our team members has a line I use constantly: you put a tool on a bad system and it amplifies the bad system. AI made the tooling spectacular. It did nothing for the system.

If your processes were unclear before you automated them, you now have unclear processes running at machine speed. If your data was messy, you’re now generating mess faster than any human ever could. We see this most in companies outside the software business, manufacturers, distributors, services firms, who can suddenly afford to build and are building on top of operations that were never mapped. The signal phrase is always some version of: “we keep putting new tools in place and nothing is improving.”

The fix isn’t a better tool. It’s somebody mapping the system first, deciding what should exist, and then pointing the tools at the right targets.

If you’ve already built

No shame in it. You moved fast and you have something running, which beats the company that’s still scheduling meetings about it. But three questions are worth a straight answer right now.

Can anyone on your team explain the architecture without the AI’s help? If your app went down at 2am, who fixes it and how long does it take? And has anyone qualified looked at it from a security standpoint, not a vibe check, an actual review?

If those answers are shaky, you don’t necessarily have an emergency. You have a window. The right move inside that window is an honest assessment by someone who’s taken systems from prototype to production before: what’s solid, what’s fragile, what needs to be rebuilt properly, and what’s fine as-is. Sometimes the answer is genuinely “less than you feared.” We’ve done these reviews and sent people away with a short punch list.

If you’re about to build

Spend a week on the system before you spend a dollar on the tools. Map the process you’re automating. Decide what the data needs to look like. Get one experienced technical voice in the room when you make the foundational choices, because those are the ones that are expensive to reverse.

AI development gives you speed. Speed in the wrong direction just gets you lost faster. Direction is the part that still requires someone who’s been there.

I’ve lived this one personally, by the way — I destroyed a working POC with a single lazy prompt. And if you want a quick read on where your organization stands before you build, the AI readiness assessment takes two minutes.