Back to Blog
vibe codingengineering debtvibecoderoperations

The Vibe Coding Hangover: What Nobody Warns You About

Shipping a vibe-coded app in 3 days is the easy part. Operationalizing the 95% of AI-generated code without burning out, hitting compliance walls, or shipping a security disaster — that is the hangover.

··7 min read

The Vibe Coding Hangover: What Nobody Warns You About

TL;DR

  • Shipping a vibe-coded app in 3 days is the easy part. Operationalizing it without burning out is the hangover most builders do not see coming.
  • The four hangover symptoms: engineering debt compounds faster than you ship, security gaps you cannot spot without expertise, operational fragility when traffic arrives, and compliance walls you did not know existed.
  • Andrew Ng's public critique of the "vibe coding" framing is partially correct on this exact point. The fix is acknowledging it and building the operational discipline that the 3-day-shipping framing skips.

The "I built a SaaS in 3 hours with Cursor" tweets are accurate — Pieter Levels' Cursor-built flight sim took "I'd say 3 hours" per his X post @levelsio status/1893385114496766155. What those tweets do not capture is what happens in week 4, week 8, and month 6 when the 95% AI-generated code meets actual production usage. This cluster sits inside our vibecoder distribution playbook and is the honest counter-balance to the optimistic framing of most build-in-public content.

What the hangover actually looks like

Three patterns show up in vibe-coded apps that hit traction:

Pattern 1 — Engineering debt compounds faster than you ship. The 3-day MVP that produced 100 paying users now produces bug reports faster than you can fix them. AI-generated code that worked for the demo path breaks for edge cases the original prompts did not consider. By week 6 you are spending more time on bug fixes than on new features.

Pattern 2 — Security gaps you cannot spot. Most vibe-coded apps ship with one or more of: improperly secured database access, exposed API keys in client code, IDOR vulnerabilities, missing rate limiting, or auth flows that work for the happy path but fail under attack. The founder does not see them because the AI did not flag them and the founder does not have the security background to audit.

Pattern 3 — Operational fragility under load. The app works for 100 users. At 1,000 users the database queries start timing out, the inference costs spiral, the rate limits from upstream providers fire. The original code was not designed for scale because the prompts did not specify scale requirements.

Pattern 4 — Compliance walls you did not see. GDPR-related obligations (data deletion, consent flows), payment compliance (PCI for stored payment info), accessibility (WCAG), industry-specific (HIPAA for health-adjacent, SOC 2 for B2B sales). The 3-day MVP shipped without any of this; the first enterprise inbound asks for SOC 2 and you discover you are 6 months away.

The hangover is real. The framing of "vibe coding solved building" is not wrong — building got faster — but the full lifecycle of running a software business in production has not gotten faster at the same rate.

The Andrew Ng critique, taken seriously

Andrew Ng and Simon Willison have both publicly pushed back on the "vibe coding" framing. Their concern, paraphrased: the word "vibe" understates the engineering judgment still required for production software. The 3-hour build looks magical; the 3-month operationalization is invisible in the framing.

This critique is partially correct. The full response is not to defend vibe coding as flawless but to acknowledge two things:

  • The build acceleration is real. What used to take 3 weeks takes 3 days. That is genuinely a 7-10x improvement in the build phase.
  • The operational phase did not get the same acceleration. Production hardening, security review, scaling for traffic, compliance work — all still require engineering judgment that vibe coding tools do not yet supply.

The honest 2026 framing: vibe coding accelerated the build but did not eliminate engineering. The founder still has to do the engineering work, just shifted to the operational phase instead of the build phase. Founders who do not absorb this shift run into the hangover and either burn out or ship-and-pray (which often becomes ship-and-rebuild).

The four moves that prevent the hangover

Concrete operational discipline that vibe-coded apps need from day 1, not week 12:

Move 1 — Security audit before user 100. Most security issues are catchable with a 4-hour audit by someone with a security background. Pay $500-2000 for a freelance security review the week before launch. Catch the IDOR, the exposed keys, the missing rate limits. This is cheaper than the post-breach fix.

Move 2 — Cost-per-user instrumentation from day 1. Track AI inference cost per active user from the first user. Without this instrumentation you discover at user 500 that your unit economics are upside-down. With it, you adjust pricing or caching as the data emerges. Anthropic prompt caching (~90% savings on repeated requests) is the highest-leverage cost control.

Move 3 — A "rebuild list" that you maintain in parallel. Document the AI-generated code patterns that you know are fragile and that you intend to rewrite manually. Examples: auth middleware (security-sensitive), payment integration (compliance-sensitive), data export flows (deletion / privacy). Schedule rewrites against revenue milestones (rewrite auth at $5K MRR, payment at $10K MRR, etc.).

Move 4 — Compliance triggers documented before launch. What changes when you have your first European user? Your first healthcare customer? Your first enterprise contract? Document the triggers so when they fire, you know what to do instead of panicking. The compliance work itself is usually 2-6 weeks; not knowing it is coming costs more than the work.

The honest cost of the hangover

For founders who ignore these moves, the typical outcome:

  • Weeks 1-8: Smooth sailing. Customers happy. Founder confident.
  • Weeks 9-16: Bug fixes start consuming more time than new features. First serious customer complaint about reliability. Cost per user higher than expected.
  • Weeks 17-26: First security or compliance incident, or first major rebuild required. 4-8 weeks of work that the founder did not plan for.
  • Month 7+: Either the founder has absorbed the operational discipline and the business stabilizes, or the founder burns out or pivots.

The 4 moves above compress months 9-26 into a manageable, planned workstream instead of a series of emergencies.

What does not work

  • Asking AI to "audit my code for security issues." Current AI tools do not reliably catch the security issues that matter (logic flaws, auth bypasses, IDOR). Pay a human security reviewer.
  • Hiring an offshore agency to "fix the AI code." Usually produces another layer of code that the founder cannot maintain. Worse than the original.
  • Pretending the hangover is not coming. The most expensive mistake. The hangover happens to ~90% of vibe-coded apps that hit traction; pretending you will be the exception is rarely correct.
  • Rewriting the entire app manually before getting more customers. Premature optimization. The right balance is rebuilding the load-bearing 20% (auth, payments, data flow) while accepting the rest stays AI-generated until evidence justifies rewriting.

Sibling clusters

FAQ

Is the hangover unavoidable? For the 4 moves done well, it is largely avoidable. For founders who skip all 4, it is essentially universal. The hangover is structural — it happens because building accelerated faster than operating did — so the only question is whether you absorb the operational work pre-emptively or under emergency conditions.

Should I just stop using AI tools to avoid the hangover? No. The build acceleration is real and abandoning it costs more than the hangover work. The right move is using AI tools for what they are good at (initial build, prototyping, scaffolding) and human engineering for what they are not yet good at (security review, scaling, compliance).

How much does the security audit cost? $500-2000 for a 4-hour freelance review from someone with a security background. $5000-15000 for a more thorough penetration test from an established firm. For pre-launch vibe-coded apps, the $500-2000 tier is the right starting point — it catches the obvious issues without consuming runway.

What if I do not have engineering background to evaluate AI code? Two paths. One: pair with someone who does, either as a co-founder or a fractional CTO. Two: invest aggressively in your own engineering education — the 4-move list above is partly a roadmap for what to learn. The honest version: founding a software business without any engineering literacy is hard regardless of AI tools, and the hangover hits harder for non-technical founders specifically.

Is Andrew Ng right that vibe coding is overhyped? Partially. The build acceleration is real and worth the hype. The "engineering is solved" implication that some early framings carried is overhyped — engineering is just shifted, not solved. Posts that take a strong pro-vibe-coding stance should acknowledge the Ng critique at least once because operators who have seen the hangover read the unalloyed version as naive.

Building is no longer the bottleneck. Visibility is. buildinpublic.so is narrative infrastructure that runs inside your building workflow — Dev Cards captures the rebuild commits as content (operations is itself a marketing story), Loudy drafts the honest weekly retros that include the hangover progress, and Vibe Journal tracks the operational debt against the production-readiness milestones.