The Demo Is Not the Destination: What AI Building Tools Actually Hand You

I want to start with something I genuinely believe. We are living through the single best moment in history to be a person with an idea and no engineering degree. If you can describe what you want in plain English, a model will hand you something that runs. That is wild. That is beautiful. I am not here to throw cold water on it.

In early 2025, Andrej Karpathy gave this whole movement a name. He called it vibe coding, describing a style where you lean into the flow and almost forget that the code even exists. And it caught fire fast. By the spring of that year, roughly a quarter of the startups in a single Y Combinator batch reported that more than 95 percent of their codebase was generated by AI (source). The floor that used to keep regular people out of software building has dropped through the basement.

So here is my love letter and my warning, all in one post.

The floor dropped. The ceiling did not move.

The thing AI building tools are spectacular at is getting you to a demo. You prompt, it scaffolds, you get a screen that looks like the thing in your head. That feeling is intoxicating, and you should chase it. Build the proof of concept. Show your spouse. Show your future customers. Validate the idea before you spend a dollar.

But a demo and a company are two different animals, and the distance between them is exactly where most first time founders get hurt.

Addy Osmani, who leads developer experience at Google Chrome, put language to this better than anyone. He calls it the seventy percent problem. AI can rapidly produce something like 70 percent of a working application, the scaffolding and the obvious patterns. The trouble lives in the final 30 percent. The edge cases. The integration with real systems. The security. The part where it has to work when a stranger who is not you, on a phone you have never seen, on a network you do not control, hammers on it at two in the morning.

Osmani has a phrase for what you are actually holding after a great vibe coding session. He calls it house of cards code. It looks like a building. It is held together with duct tape behind the scenes.

Most things do not fail because they were built badly

Now, I do not want you to read all that and think the lesson is "AI bad, hire engineers." That is lazy and it is wrong.

My business partner and COAK cofounder Mike Rispoli wrote a piece a while back called On Building Bad Ideas, and there is a line in it I quote constantly. He reminds us that most software does not fail because it was poorly built. It fails because it set out to solve a problem that was not big enough.

Sit with that for a second, because it reframes the whole AI conversation. If your idea is wrong, AI just lets you build the wrong thing faster and cheaper. That is actually a feature. Use these tools to find out you are wrong before you raise money, before you quit your job, before you ask anyone to bet on you. The proof of concept is the cheapest market research you will ever run.

The danger is not building the demo. The danger is mistaking the demo for the destination.

Where this is going

The next time someone tells you they built their whole product over a weekend and they do not need a developer, believe the first half. They probably did build something real. Then ask them the second half of the questions. What happens when you have a thousand users. What happens when a customer's data leaks. What happens when you want to add the feature that actually makes you money and the model keeps breaking the three features that already worked.

That second half is the 30 percent. It is where defensible, scalable, and secure live. And it is the subject of the rest of this series.

For now, go build your bad idea. Find out fast if it is a good one. Just know that the moment it becomes real, the rules change, and the cousin in your corner will be the first to tell you so.