Vibe Code Rescue: The Complete SOP
Turn AI-Written Mess into Maintainable Software

90% of vibe code is recoverable — if you follow this SOP. What would take 8 weeks to rewrite can be stabilized in 3 weeks by following these steps. This piece includes a real NT$45,000 case study, the 7-step Vibe Code Rescue SOP, actual before/after code examples, and how to tell when you should rewrite instead of rescue.

Why you might need a Vibe Code Rescue

If any of these is you, this was written for you:

• You finished an MVP with Claude Code / Cursor / Copilot, but you know in your gut it'll blow up in six months
• You inherited a service an ex-colleague built with AI, and your first words opening the repo were "what is this"
• You're a startup CTO and the team shipped so fast with AI that technical debt is now a mountain
• You're a PM and your engineer says "the AI code can't be maintained" — and you can't tell if that's true or an excuse

What you'll get here isn't philosophy — it's an actionable Vibe Code Rescue SOP.

What is Vibe Coding? Why does it become a disaster that needs rescuing?

Vibe Coding is a term coined by Andrej Karpathy in 2025, meaning:

"Writing code purely on vibes — not reading the details, not reviewing what the AI generated, not verifying the logic, just shipping as long as it 'seems to run.'"

The problem isn't using AI. It's these three things:

01 No one reads what the AI generated

The most extreme case I've seen: a startup engineer wrote an 800-line controller with Cursor and never read it once. Three months later a production bug blew up, and he opened the file and said "when did I write this?" The answer: he never did. The AI wrote it. He just pasted it.

02 No record of "why"

AI doesn't document design decisions. You use useReducer instead of useState today, with zero record of why three months later. The next person rewrites it as useState, a boundary condition breaks, and only then do you remember "oh right, it was to handle an async race condition." But it's too late.

03 No safety net of tests

The biggest problem with vibe code isn't that it's poorly written — it's that there are no tests protecting it. You change one thing and have no idea what it breaks. Maintenance cost explodes five months in.

Can your vibe code be rescued? 3 diagnostics

Not all vibe code should be rescued. Here are the 3 diagnostics I run before taking on a Vibe Code Rescue:

01 Look at the last 30 git commits

git log --oneline -30

Judge the quality of the commit messages:

02 Ask three questions

• How long has this project been in development? < 2 months: rescue is viable / 2-6 months: more effort needed / > 6 months: a rewrite is usually cheaper
• Is anyone still changing it? Yes: freeze for 1 week before rescuing / No: go straight into the rescue flow
• Is it live? Live + has users: rescue carefully, no downtime / Live + no users: refactor boldly / Not live: just refactor

03 Run a full build from scratch

rm -rf node_modules
npm install
npm run build
npm run test  # if there are any tests

If all four lines pass, congratulations — rescue odds are 80%+. If any line gets stuck, fix "it runs" first.

The complete 7-step Vibe Code Rescue SOP

This is a methodology built over 5 years, having rescued 3+ projects (the ones I can talk about publicly):

SOP 01 Build a safety net (don't touch code, preserve evidence first)

# 1. Create a rescue branch
git checkout -b rescue/initial-state
# 2. Tag and freeze the whole repo
git tag rescue-baseline-$(date +%Y%m%d)
# 3. Run a full build + screenshot every screen
# 4. Back up environment variables
cp .env .env.backup
# 5. Hit every API with Postman / cURL, save responses as JSON

SOP 02 Understand what the AI wrote (the most painful but most important step)

Start tracing from main.ts / index.js / App.tsx, reading line by line. As you read, do 3 things: add // TODO where you don't understand, // DUPLICATED for repeated logic, and // BOUNDARY for suspicious edge cases. Read the whole repo in 3 days — this step saves you 50% of the time downstream.

SOP 03 Add tests for boundary conditions

You don't need 100% coverage — only test "the places that break." Wrap every spot you marked BOUNDARY in SOP 02 with a test. The goal: capture all the cases "the AI didn't think of." 3-5 days of work.

SOP 04 Extract magic numbers and magic strings

// BEFORE (vibe code)
if (order.total > 1000) { shippingFee = 0; }

// AFTER (refactored)
const FREE_SHIPPING_THRESHOLD = 1000;
if (order.total > FREE_SHIPPING_THRESHOLD) { shippingFee = 0; }

Benefits: change the rule in one place, anyone can read the code, and tests can inject mock values.

SOP 05 Split oversized functions (anything >50 lines)

AI loves writing 200-line functions. Split an 80-line checkoutOrder into independent, testable helpers like getOrderOrThrow, calculateFees, sendConfirmationEmail, and updateInventory. Each becomes independently testable, and bug-fix speed goes 3×.

SOP 06 Write a README + ADRs

README for whoever inherits it in 6 months: quick start, main features, tech stack. ADR (Architecture Decision Record) documents "why this decision" — context, decision, reasoning, cost, alternatives considered. Write one per major decision, so when someone asks "why" three months later, you don't have to dredge your memory.

SOP 07 Set up CI/CD + monitoring

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

Use Sentry / LogRocket / DataDog for monitoring; alert when error rate > 1%. CI + monitoring = the rescue won't quietly rot again.

A real case: the NT$45,000 Vibe Code Rescue

An e-commerce startup ("Company A," anonymized) started shipping with AI in late 2025 — a 2-person team built an MVP in a week with Cursor + Claude and launched in 3 months. By month 4: the backend engineer quit, production bugs hit 2-3 times a week, every new feature broke two others. The remaining engineer asked me: "Can it be saved?"

Diagnosis: git log was all fix, update, final — no spec'd commits, but at least there was git history. Conclusion: 60% rescue odds, 3 weeks of work.

Quote: 3 weeks (90 hours), NT$45,000 deposit + NT$45,000 on delivery. Deliverables: 50% boundary-condition tests, README + 8 ADRs, CI/CD, monitoring, 30 days free support. The owner found it cheap (vs. a rewrite estimated at 8 weeks, ~NT$300K) and wired the deposit that day.

Results after 3 weeks:

What the owner said 30 days later: "If I'd hired you to do this the moment we launched, I'd have saved 6 months of flailing."

The 5 traps in a Vibe Code Rescue

• Trap 1: wanting to "rewrite while you're at it." Rescue ≠ rewrite. Every "while I'm at it" rewrite = 5 more bugs, 3 more days, a client who thinks you're stalling. Change the least, make it stable.
• Trap 2: not scoping "what's NOT rescued." Write "this rescue covers only modules X/Y/Z, others billed separately" — or the client will say "rescue this one too while you're here."
• Trap 3: sneaking in your own preferences. Match the client's existing code style. Even if the AI code is ugly, write it "just as ugly but protected by tests."
• Trap 4: not budgeting "education time." If you don't teach the client, the project reverts to vibe code in 6 months. Include 2-3 one-on-one teaching sessions.
• Trap 5: no post-rescue warranty. Include 30 days of free support (one 1-on-1 per week). The client feels safe, and you save yourself trouble.

When to rewrite, not rescue?

Honestly, not all vibe code should be rescued. I recommend rewriting in these 5 cases:

1. No git history (only a final.zip)
2. It won't even run (environment won't install, build fails)
3. The core architecture is wrong (picked a totally unsuitable framework)
4. Serious security issues (hardcoded API keys all over the repo)
5. The business logic itself is wrong (still wrong after rescuing)

Long-term maintenance after a rescue

1. Write 1 new test per week (50+ after a year)
2. Write 1 ADR per month (record major decisions)
3. Refactor 1 old file per quarter (stop it rotting again)
4. All AI-written code must be reviewed before merge (most important!)
5. Onboard new hires with the post-rescue README + ADRs (productive in 30 days)

Vibe Code Rescue FAQ

Further reading — Engineers in the AI Era series

• What Is Vibe Coding? A Full Breakdown + How 5 Types of People Should Use It
• AI Gives You Code, Not Software — A 14-Point Checklist
• 12 Cursor Tips — From Knowing It to Being Good at It
• 5 Ways Engineers Monetize Their Skills
• The Complete Guide for Engineers in the AI Era (Pillar)