AI code looks done until you actually run it. A builder on r/nocode said it better than any postmortem I have read. Every AI build "looks flyable until you actually click anything."
Plans have the same bug. They read well until something tries to enforce them.
Another builder counted his year in public. Twelve agents built in nine months. Five shipped. Four broke almost right away. His diagnosis was one line. "Real users found the weird edge cases I never tried." A third described the feeling underneath it, going in circles with no plan across five projects at once, "more dangerous because I feel productive."
You already treat generated code with suspicion. You run it, you test it, you gate the deploy. The plan gets none of that. It gets a read-through, a nod, and a build. Which means the wrong thing ships with excellent uptime.
Strategy is the new code. Generating the old kind got cheap, which moved the scarce work upstream, into deciding what to build, for whom, and what a user walks through on the way to value. That work sets the ceiling on everything the build produces. The time you used to spend typing belongs there now, and it deserves the same rigor typing got.
Why do plans that read well still ship the wrong thing?
Because review reads documents one at a time, and the failures live between them.
A spec says the project dies if cost crosses a line, and nothing anywhere captures cost. A metrics doc names a north star no event ever emits. A flow map has a failure state with no instrumentation on it, so when a real user hits it, the system goes quiet instead of loud. Each document is internally fine. The seam between them is where the plan stops being enforceable.
Reading checks whether the sentences are true. Enforcement checks whether anything happens when one of them is violated. A plan can pass the first test completely and fail the second one everywhere, and a read-through will never tell you, because a read-through is running the plan in your head, where every number is capturable and every gate fires.
That is what vibe-coded means when you apply it to planning. Generated fast, plausible everywhere, verified nowhere.
What does skipping the audit actually cost?
Three entries from my own ledger, spent so you can skip them.
The product that could not report on itself. I shipped the first version of Templatiz with zero instrumentation. Not thin instrumentation. Zero. When growth stalled I could not answer the most basic question about it, did anyone activate, because no event existed to look at. The rebuild plan carries a metrics document with eight logged events precisely because the first version could not testify at its own trial.
The tool nobody would have installed. I built a content eval gate this month. Repo, landing page, the works. Then I scrapped it, because the demand question got asked after the build instead of before. An audit that requires demand evidence before a spec exists would have killed it in an afternoon, at a cost of one afternoon. Instead the kill came after the build, at the cost of the build.
The gate that blocked its author. Before launching my own PM plugin, I ran its ship gate against it, walking the product as a first-time user. Verdict, block. The install command in my own README was a placeholder, and the product was shipping two whole phases the README never mentioned. The tool caught its maker doing exactly the thing it exists to catch. I fixed what it flagged and kept the finding, because it is the most honest demo the product will ever have.
How do you audit a plan like code?
Cross-artifact and adversarial. The audit needs more than one document, because the seams are where documents disagree, so the minimum kit is four thin files. Discovery, who has the pain and what evidence says so. Spec, scope, explicit non-scope, and the criteria that kill the project. Flow, every state the user can land in, including the ugly ones. Metrics, the activation event and the numbers that will exist at launch.
Flow earns a special word before the checklist, because it is the file builders skip most and the one that predicts the twelve-agents story above. Every one of those broken agents broke on a path nobody walked. Writing the flow is walking every path before a user does, the happy one and the ugly ones, and it is what gives the ship gate something to walk again at the end, against the real build.
Then you hunt ten seams.
- A claim in one document that contradicts another.
- A term used as if it were defined, defined nowhere.
- A gate that depends on its own output to pass.
- A success criterion with no metric behind it.
- A metric no criterion ever reads.
- A flow state whose failure path has no instrumentation.
- An assumption no milestone ever tests.
- A milestone that kills no assumption.
- Non-scope quietly leaking back in downstream.
- An autonomy rule with no gate enforcing it.
You can run this by hand today. Paste the list and your four documents into whatever assistant you build with, and ask it to find every seam, citing file and section for each one, arguing against the plan rather than for it. One pass takes an afternoon.
Here is the calibration from running it for real. The rebuild plan for Templatiz had been through my own read and an outside review, and the review found six real issues. The cross-artifact audit found thirteen. It matched four of the reviewer's six, half-matched a fifth, and missed the sixth entirely, the most conceptual conflict in the plan. It also surfaced eight seams the review never touched, and every one of the eight was an enforcement gap. The headline catch was a kill criterion no number could trigger. The plan swore the project would die within two weeks if cost crossed a threshold, and nothing in the entire system captured cost.
Fourteen fixes went in before a line of code got written.
The division of labor matters as much as the score. The audit beat the human on seams and lost on philosophy. It missed the one conflict that required actually understanding what the product is for. So the audit does not replace your judgment. It clears the mechanical failures off your desk so your judgment is the only thing left to apply.
How does the audit run when you forget to run it?
The checklist above is free and it works this afternoon. Its failure mode is the same one that produced the pain in the first place. You have to remember to run it, at the right moment, on every project, and remembering process is precisely the muscle that vibe-speed building atrophies.
That is the job I built Vibe Code PM for. It is a Claude Code plugin that holds the whole sequence, discovery before spec, spec before flow, flow before metrics, the audit after metrics, a ship gate before launch. It reads where your project is and offers the next step unprompted, once. Decline a step and it logs the decision and never offers it again for that project. Everything it writes is plain markdown in a folder you own, versioned with your code.
It is in early access at vibecodepm.com, and the waitlist is the door. Run the checklist by hand first. If you find yourself wanting it present every session instead of only the sessions you remember, that is the product.
FAQ
Can I run the audit without buying anything? Yes. The ten seams above plus your own documents plus any capable assistant is the whole method. The plugin's version adds sequence, memory, and the unprompted offer, and none of that is required to get value from the checklist today.
My plan is one doc, or lives in my head. Can I still audit it? No, and that is a finding in itself. A one-document plan has no seams to check because nothing can contradict anything. Write the four thin files first. An hour of writing buys you an auditable plan, and the audit is where the leverage lives.
Does this replace human review? No. In the head-to-head, the audit missed the most conceptual issue while a person caught it. The audit owns the seams, the enforceability, the cross-file contradictions. You own the question of whether the product should exist at all.
What actually happened to the eight seams the review missed? All eight got fixed before build, along with the rest. The fixes were small, an event added here, a threshold pinned there. That is the point. Seams are cheap to close on paper and expensive to discover in production.
You already gate your deploys. Strategy is the new code. Gate it the same way, and all that build speed starts pointing at the right target.