You can't run a business on code you can't read

A story made the rounds: a non-technical founder built an entire product with AI, no code they could read, and got far enough to put it in front of a real, security-conscious customer — and then got hacked. The pile-on was predictable: see, vibe coding doesn't work. That's the wrong lesson, and it's a comforting one because it lets everyone who writes their own code off the hook.

The actual lesson is narrower and more useful. AI made it possible to ship something before you understand it. Those used to happen at roughly the same time — you couldn't produce working software without grasping how it worked. That coupling is gone. You can now have a running product and no mental model of what it does. The breach wasn't caused by AI writing the code. It was caused by nobody being able to answer "what happens when an attacker does X" — because nobody had ever held the whole thing in their head.

Shipping is not understanding

A demo proves the happy path works. Running a business means owning the unhappy paths: the auth edge cases, the data that shouldn't be exposed, the input nobody sanitized, the third-party call that fails at the worst moment. None of that shows up in a demo. All of it shows up in production, usually when a customer or an attacker goes looking.

This isn't a non-technical-founder problem. Engineers ship code they don't fully understand too — inherited services, a teammate's module, an AI-generated chunk they skimmed and approved. The question that matters isn't "did a human type it." It's "does anyone understand what this actually does, including the parts that don't render on screen."

The fix isn't 'learn to code.' It's recover the spec.

You don't have to read every line to be safe. You have to be able to answer questions about behavior: what are the actors, what can each one trigger, what does the system do in response, where does data go, what happens when something fails. That's a specification — and the thing about AI-built products is that the spec was never written. The code exists; the understanding never did.

So you reconstruct it from what's actually there:

• Derive behavior from structure, not vibes. Work from the real flows the product supports — who does what, what each action triggers, what the system does back — instead of the founder's memory of what they asked for.
• Surface the unhappy paths. The value isn't documenting the happy path you already demo. It's making the failure modes, the auth gaps, and the data exposures explicit so someone can actually look at them.
• Make it reviewable. A spec a security-minded customer can read is the difference between "trust me, it works" and "here's exactly what it does, including the edges." One of those closes deals with serious buyers. The other gets you breached.

What the AI-build skeptics get right and wrong

Right: you can't run a real business on a black box. A product you can't reason about will eventually surprise you, and the surprises scale with your success — bigger customers, more data, more attack surface.

Wrong: the answer isn't to throw out AI building and write everything by hand. The answer is to close the gap AI opened — between shipping and understanding — by recovering the spec from the product you already have. Build fast. Then make sure someone can read what you built before you bet a customer's data on it.