Vibe-coded to production. Nine plays for finishing the last 20%.

Garry Tan's rule for the production wall is to lower the bar, not raise it. The instinct at the last 20 percent is to keep polishing in private until everything is perfect, which is the surest way to never finish. Tan's counter is to cut scope and ship the jankiest thing that still provides real value, then let users tell you whether the rough edges even matter. If somebody uses a janky product anyway, that speaks volumes about how badly they need the problem solved.

The point is not to ship garbage. It is to stop treating the unfinished 20 percent as a private failure and start treating it as a public test. Launching early is generally good as long as there is some minimum value the product actually provides, and most of the polish you were agonizing over turns out not to be the thing standing between you and a paying user.

Paul Graham's most-quoted essay is the antidote to the weekend-build fantasy that the app should finish itself. The lesson founders skip is that startups do not take off on their own. You recruit the first users by hand and do the work that does not scale to delight them. Applied to a stuck vibe-coded MVP, that means the finishing work is not a background job you can prompt your way out of.

It is manual: onboarding early users one conversation at a time, watching them hit the broken edge, fixing it live. Airbnb did not scale by automating early. The founders went out and did obviously unscalable things to get the flywheel turning. The same hands-on grind tells you which parts of the last 20 percent users actually care about, so you spend your finishing effort on the integration that matters instead of gold-plating the one nobody touches.

Simon Willison draws the cleanest line in the debate, and it dissolves most of the confusion about why the last 20 percent is so hard. Vibe coding, in his framing, is a non-technical way to prototype: you describe what you want and accept the output without reading it. Agentic engineering is the separate, professional discipline of building production-ready software with AI, where you still own the architecture and the review. The trap is using the first mode to do the second mode's job.

A prototype that works in a demo and a system real users depend on are different problems, and the tools that feel magical for the first feel reckless for the second. Naming which one you are doing is the unlock. The production parts of your app, the ones that touch money, identity, and other people's data, need the engineering posture even if the rest stays vibe-coded.

Willison's second warning is the one most weekend builders never hear until it is too late: security is where vibe-coded apps fail, and the failure is structural, not a missed checkbox. He describes the lethal trifecta, the combination of untrusted input, access to private data, and the ability to take action on the outside world. An app with all three and no guardrails is a prompt-injection waiting to happen. The deeper risk is cultural.

The industry is normalizing unsafe AI development practices, shipping apps that handle real user data with security treated as a step you get to later. For a founder, the takeaway is to move the security question to the front. Before you worry about polish, ask whether your app exposes the trifecta, because that is the part of the last 20 percent that does not just embarrass you, it can sink you.

George built Wrestle AI, an AI wrestling coach that analyzes match footage, to around 17,000 dollars a month, and he is a useful case study because he did not pretend AI could do everything. He used a vibe coding platform and ChatGPT to build most of the app in about a month, leaning on public APIs to move fast. Then, for payment integration, he hired a developer to do that specific part. That is the ship-versus-hire decision made in the wild.

He did not rebuild the whole app and he did not white-knuckle the riskiest integration himself. He vibe-coded the 80 percent that was forgiving and bought a few hours of real engineering for the part where a bug means lost revenue or a broken subscription. Hiring narrowly, just for payments or auth or the one compliance-sensitive feature, is almost always cheaper than the rebuild you do after that part silently breaks in production.

The a16z panel makes a distinction that tells you which posture to take at the wall. Vibe coding is the less formal mode, focused on the output and moving fast. Classic, enterprise-style coding involves more choices and pays attention to implementation details. Their read is that even enterprise users will vibe-code for the right tasks, which means the answer is not vibe coding good, enterprise coding bad.

It is matching the mode to the stakes. The reason the last 20 percent stalls is usually that a founder built the whole thing in output-first mode and then tried to harden it without ever switching gears. The fix is to decide, feature by feature, which game you are playing. Validation and internal tools can stay loose.

The parts real customers depend on get the implementation-detail attention that the enterprise mode is built for.

Steven Sinofsky, who ran Windows at Microsoft, offers the most grounding frame for managing your own expectations. He separates vibe writing, which he sees as a relatively mature use of AI with real autonomy, from vibe coding, which he says is still constrained. There is a significant gap between what the concept promises and what the tools actually execute, which produces errors and demands careful human oversight. In plain terms, the tool that looked like it nearly finished your app in the demo will, on the parts that matter, give you a lot of errors and sometimes just not do the thing you asked at all.

That is not a sign you prompted wrong. It is the current state of the medium. The founders who finish are the ones who plan for that gap, verifying every output that touches the core experience rather than trusting the happy-path demo and discovering the holes in production.

The Y Combinator founder survey is the on-the-record version of the meme that AI is not very good at debugging, and debugging is most of the job. The survey found founders writing less code and spending more time thinking and reviewing, with human taste becoming more important, not less. AI generates code well, but debugging remains the hard part, sometimes coming down to giving very explicit instructions or just rolling the dice. The skills that still decide who ships, especially past the initial zero-to-one phase, are taste, debugging, and system thinking.

This reframes the last 20 percent. It is not a tooling problem you solve by switching to a better model. It is the exact zone where the human skills the tools do not replace become the whole game, so the most valuable thing you can build is your own ability to read the AI's output critically and fix what it got wrong.

Y Combinator's Startup School compresses the hard-won tactical advice into one habit that saves stuck projects. When the AI goes down a rabbit hole, the worst move is to keep prompting fixes on top of fixes. Each failed attempt accumulates bad code, and you end up in the doom spiral builders describe where nothing runs and you cannot tell which patch broke what. The discipline is to use version control religiously and avoid multiple bug-fix attempts without resetting.

Commit every time something works, so that the moment a fix makes things worse you reset to the last good state and start clean with a sharper prompt. This single habit, cheap resets backed by frequent commits, is the difference between a vibe-coded project that gets finished and one that collapses under its own accumulated mess in the final stretch.