Vibe-coding production is shipping LLM-generated code to paying customers without code review, evals, or a fallback path. It is the moment a useful practice — prompt-accept-iterate — crosses out of its envelope and starts producing operational risk the founder is not equipped to absorb. The discourse around vibe coding has been generous about the upside and vague about the line. This piece names six triggers that should stop the loop, and a two-week handoff playbook a founder can hand to a senior reviewer when any one of them fires. The argument is not “stop vibe-coding.” It is “stop vibe-coding production” — keep the loop, change the audience.
For when Cursor and Claude Code are enough and when they are not, see the DIY-with-AI manifesto, part of the broader idea-to-product manifesto for non-engineers. It pairs with vibe-coding explained: what it is, who it works for, which names the practice, and why most DIY AI MVPs ship a demo, not a product, which names the most common DIY failure mode.
Table of Contents
What “vibe-coding production” means, precisely
“Vibe-coding production” is a specific act. It is taking code produced by a prompt-accept-iterate loop — Cursor’s chat panel, Claude Code in a terminal, Aider in a project directory, Replit Agent in a hosted environment — and putting that code in front of paying customers without three things:
- Code review by a human who reads the diff and understands the architecture.
- Evals — a test harness that measures AI-feature accuracy against a labeled dataset before deploy and continuously after.
- A fallback path — a deterministic or human-in-the-loop response when the model fails, plus a kill switch.
The phrase needs to be precise because the alternatives are loose. “Be careful” is not a stop signal. “Hire someone eventually” is not a stop signal. Either you have review, evals, and a fallback, or you are vibe-coding production.
The Stack Overflow Developer Survey 2025 reported 76% of developers use AI coding tools regularly, while trust in accuracy fell from 43% to 35% year-over-year. That gap — universal use, falling trust — is the operational reality this piece sits in.
The next six sections name the structural triggers that move a project out of vibe-coding’s envelope. Any one firing is sufficient grounds to stop the loop and hand off.
Trigger 1: Paying customers
The moment a paying customer touches the artifact, the cost-of-bug curve changes shape. A bug in a prototype costs a conversation. A bug in production costs a refund, a churn event, a public complaint, and — if the bug touched a payment, an account, or a piece of customer data — a regulatory exposure the founder did not budget for.
Paying-customer code requires three properties vibe-coded code rarely has by default: idempotent writes (so a retried request does not double-charge), correct error boundaries (so a model failure shows a graceful message rather than a stack trace), and structured logging (so an incident can be reconstructed after the fact). A senior reviewer adds these in 2-3 days. A founder vibe-coding alone tends to discover them one outage at a time.
The trigger is binary: first paying customer, hand off review.
Trigger 2: Regulated data
The codebase touches healthcare records (HIPAA), EU resident personal data (GDPR), payment card data (PCI-DSS), student records (FERPA), financial transactions (SOC 2 Type II expected by enterprise buyers), or biometric data (BIPA, state-level laws). Each regime is a strict-liability surface. None of them care that the code was AI-generated. All of them require demonstrable controls — access logs, encryption at rest, data-retention policies, breach-notification procedures.
Vibe-coded code rarely has these by default because the prompt loop optimizes for “the feature works,” not “the data subject has a right of access we can satisfy in 30 days.” The NIST AI Risk Management Framework (NIST AI RMF 1.0) names the categories — govern, map, measure, manage — that auditors look for. None of them are emergent from a vibe-coding loop.
The trigger fires before the first piece of regulated data enters the system. If you can foresee that regulated data will enter the system in the next 60 days, hand off now.
Trigger 3: Multi-step agent workflows
Single-step LLM calls (classify this email, summarize this document) have a contained error surface — the model is right or wrong, and the founder can read the answer. Multi-step agentic workflows (the agent reads three documents, calls four tools, makes a decision, writes a record, sends an email) have a compounding error surface. If each step is 95% reliable, the four-step chain is 81% reliable — and a vibe-coded agent rarely measures step-level reliability at all.
Compounding-error surfaces require evals at every step, retries with idempotency keys, structured observability so a failed run can be traced, and a fallback to a human reviewer for low-confidence runs. None of these emerge from the prompt-accept-iterate loop. They emerge from a deliberate engineering practice that vibe coding deprioritizes.
The trigger fires when the agent’s decision affects a downstream system the founder cannot easily roll back — a sent email, a scheduled meeting, a created invoice, a published post.
Trigger 4: SLA promises
A founder signs a contract with an enterprise pilot that names a service-level commitment — 99.5% uptime, 2-second median latency, 90% answer-accuracy on a specified eval set. The SLA is the moment vibe-coded code becomes structurally insufficient. Uptime requires deploy hygiene (blue/green, canary, rollback). Latency requires profiling and a path to optimization. Accuracy requires a maintained eval suite and a regression process.
A vibe-coding founder can hit a 99.5% number on a Tuesday by accident. A vibe-coding founder cannot commit to 99.5% across a quarter, because the practice has no mechanism to detect, report, and remediate the drift that will eventually appear. Senior engineers exist partly to operationalize SLA commitments — to convert a promise into a system that delivers the promise.
The trigger fires when the first contractual SLA is on the table. Hand off before signing.
Trigger 5: IP at stake
The codebase is about to enter diligence — a seed round, a Series A, an acquisition conversation, a licensing deal. Diligence teams ask three things about an AI-generated codebase: who owns it, what training data leaked, and whether the company can demonstrate human authorship sufficient to claim copyright.
The US Copyright Office’s 2025 guidance named human authorship as a threshold requirement; the line between AI-generated and human-edited code is contested. Vibe-coded code is unusually exposed because the human author is the one not reading the diff. A senior reviewer reading every line, with comments preserved in git history, creates the authorship trail diligence teams look for.
The trigger fires the moment a diligence conversation is on the calendar — not when it happens. Run the handoff in the four weeks before.
Trigger 6: On-call burden
The founder is the only on-call engineer. A customer pages them at 2 a.m. because the model is hallucinating account balances. The founder cannot debug what they did not read, cannot triage what they did not instrument, and cannot sleep without ignoring incidents.
On-call burden is the trigger most founders notice last because it shows up as exhaustion, not as an event. The honest signal is page count: more than two production pages a week, more than 30 minutes of incident-driven work per page, and the practice has crossed out of its envelope.
The trigger fires the second time the same bug pages the founder.
What good handoff looks like — a 2-week playbook
A senior reviewer, two weeks, six artifacts. The cheapest version of a healthy handoff. Not a rewrite. Not a multi-month engineering partnership. A defined intervention that ends with the codebase ready to absorb the next 90 days of production load.
Week 1, Days 1-2 — Codebase audit. The reviewer reads the repository end to end, names the surfaces (auth, payments, model calls, data writes, third-party integrations), and produces a one-page architecture diagram and a severity-ranked risk register. No code is written.
Week 1, Days 3-5 — Targeted code review. The reviewer rewrites the three highest-severity surfaces — usually error boundaries, idempotency on writes, secrets handling, structured logging. The rest of the codebase stays intact. The founder pairs with the reviewer 30 minutes a day so the practice transfers.
Week 2, Days 6-7 — Eval harness. The reviewer builds a labeled eval dataset of 50-200 representative inputs, scores the current AI feature against it, and stands up a CI step that runs evals on every deploy. The eval replaces “the demo looked good” as the regression signal.
Week 2, Days 8-9 — Fallback path and kill switch. The reviewer adds a feature flag, a deterministic fallback (cached response, human review queue, graceful holding message), and a one-click kill switch. This is the artifact that lets the founder sleep.
Week 2, Day 10 — Runbook and on-call rotation. A 10-page runbook: how to deploy, how to roll back, the top 8 incident shapes and recovery procedures, the eval workflow, named contacts for each external dependency. The founder joins an on-call rotation with the reviewer for the next 30 days.
Cost. Two weeks of senior-engineer time — roughly $15,000-$25,000 for a contract reviewer at 2026 market rates, or 10-15% of an existing senior engineer’s quarter. Compared with a single regulated-data incident, a botched diligence cycle, or a quarter of founder on-call exhaustion, the math is straightforward.
The six artifacts at end of week 2: an architecture diagram, a risk register, hardened high-severity surfaces, an eval harness in CI, a fallback path with a kill switch, and a runbook. The codebase did not change shape. It became reviewable.
The middle path: harden in place, do not rebuild yet
The most common mistake at handoff is asking the reviewer to “rebuild it properly.” The codebase feels untrustworthy; a rebuild feels like a fresh start. It is almost always wrong.
A rebuild costs 8-16 weeks at senior-engineer rates, discards accumulated product knowledge, and produces a codebase differently broken because the second build is rarely better than the first when requirements are still shifting. The handoff playbook above produces roughly 80% of the safety a rebuild would, at 10% of the cost, with the founder still owning the product.
The honest framing: vibe-coded code is not bad code. It is unreviewed code. A senior reviewer can convert unreviewed into reviewed in two weeks. The founder keeps the loop, keeps the artifact, and gains the audience — paying customers, regulated buyers, diligence teams — the loop alone could not serve.
Rebuild later if and when the codebase outgrows its architecture. Almost no codebase needs to be rebuilt at the handoff moment. Most need to be reviewed.
Frequently Asked Questions
What is vibe-coding production, in one sentence? Vibe-coding production is shipping LLM-generated code to paying customers without code review, evals, or a fallback path. The phrase is intentionally narrow — it names the unsafe act, not the practice of vibe coding itself.
Is this article saying founders should stop vibe coding? No. Vibe coding is excellent for internal tools, prototypes, marketing sites, and validation artifacts — the six profiles it fits. This piece argues for stopping in one specific context: production code in front of paying customers, regulated data, agentic workflows, SLA contracts, IP-sensitive moments, or sustained on-call load.
How fast can the six triggers fire? Faster than founders expect. Trigger 1 fires the day Stripe is wired up. Trigger 2 fires the day an enterprise pilot signs and shares sample data. Trigger 4 fires the day an enterprise procurement team sends a security questionnaire. Treat triggers as foreseeable, not surprising.
What if I cannot afford a senior reviewer? Three honest options. Slow down — cap customer base, data sensitivity, and SLA scope until you can afford review. Trade equity — some senior engineers exchange two weeks of handoff work for advisor equity at seed. Or buy a productized handoff service that sells the 2-week playbook as a fixed-scope engagement. The option that does not work is hoping nothing breaks.
Can the senior reviewer just be Claude Code with a “code review” prompt? No. Model-generated review surfaces some bugs but cannot produce the architecture diagram, eval dataset, runbook, or on-call rotation. The artifacts that make a codebase reviewable are organizational, not generative.
Does the handoff playbook work for no-code AI builders like Lovable or Replit? Partially. The eval harness, fallback path, kill switch, and runbook translate. Code review is constrained by what the platform exposes — Lovable’s hidden internals limit what a reviewer can read. Founders on hidden-code platforms should plan to graduate the artifact off the platform before triggers that require deep review fire.
What if I am the senior engineer — do the triggers still apply? Yes. A senior engineer who is also the founder can self-review, but should still produce the six artifacts (architecture diagram, risk register, hardened surfaces, eval harness, fallback, runbook) before any trigger fires. The artifacts are how the codebase survives the founder’s vacation.
What is the right time to add evals? Before trigger 1 fires. An eval harness costs roughly one engineer-day if a labeled dataset of 50-100 examples exists; five days if the dataset has to be assembled. Build it in the week before the first paying customer, not after. See the AI agency quality system for the operational pattern in a partner-led engagement.
How does this fit the broader DIY-with-AI argument? The DIY-with-AI manifesto names where DIY is enough; this piece names where DIY ends. Together they form the operating frame: vibe-code where the envelope allows, hand off when the triggers fire.
Closing
The honest version of “stop vibe-coding” is not “do not vibe-code.” It is “stop vibe-coding the production codebase the first time any of the six triggers fire.” The loop is fine. The audience is the variable. Cursor and Claude Code and the model behind them have made the prompt-accept-iterate loop genuinely useful for a defined set of jobs. Putting that loop’s output in front of paying customers without review, evals, or a fallback is a different job that the loop does not do.
Founders who hand off well keep the speed advantage that brought them here and gain the operational discipline that lets them survive their first quarter of production load. Founders who refuse the handoff almost always meet one of the six triggers under conditions worse than choosing.
If you are inside the envelope, keep vibe-coding. If a trigger has fired or is about to fire, the next two weeks are the cheapest you will ever spend on this codebase.
Dirk Jan van Veen, PhD
