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 Andrej Karpathy coined on X in February 2025. His actual words:
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — original tweet
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
<code>git log --oneline -30</code>Judge the quality of the commit messages:
| Commit message pattern | Rescue odds | Meaning |
|---|---|---|
feat(auth): add OTP login — clear spec | 90% | Writer has discipline, just used AI to go faster |
fix, update, quick fix | 60% | Messy but still salvageable |
final, final2, final_real | 30% | Already given up, needs a full rewrite |
| Everything is “Initial commit” | 10% | Didn’t even use git — rewrite it |
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
<code>rm -rf node_modules
npm install
npm run build
npm run test # if there are any tests</code>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)
<code># 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</code>Why this matters:
during the rescue you will break something. With a baseline, you’ll know what you broke.
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
<code>// BEFORE (vibe code)
if (order.total > 1000) { shippingFee = 0; }
// AFTER (refactored)
const FREE_SHIPPING_THRESHOLD = 1000;
if (order.total > FREE_SHIPPING_THRESHOLD) { shippingFee = 0; }</code>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
<code># .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with: { node-version: '22' }
- run: npm ci
- run: npm run lint
- run: npm run test
- run: npm run build</code>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:
| Metric | Before | After |
|---|---|---|
| Bug frequency | 2-3 / week | 1-2 / month (-80%) |
| Feature delivery | 2 weeks each | 3 days each (+5x) |
| Engineer onboarding | 3 months | 1 week |
| Team morale | anxious | ”finally able to do real work” |
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:
- No git history (only a final.zip)
- It won’t even run (environment won’t install, build fails)
- The core architecture is wrong (picked a totally unsuitable framework)
- Serious security issues (hardcoded API keys all over the repo)
- The business logic itself is wrong (still wrong after rescuing)
Decision rule: rescue time > 50% of rewrite time →
rewrite
. Client says “I have time to rescue slowly” → rewrite. Client says “we launch this week” → rescue.
Long-term maintenance after a rescue
- Write 1 new test per week (50+ after a year)
- Write 1 ADR per month (record major decisions)
- Refactor 1 old file per quarter (stop it rotting again)
- All AI-written code must be reviewed before merge (most important!)
- Onboard new hires with the post-rescue README + ADRs (productive in 30 days)
Vibe Code Rescue FAQ
What is Vibe Code Rescue?
Taking code rapidly generated by AI that lacks tests, docs, and architecture, and turning it into stable, maintainable, handoff-ready software through a systematic process. The core is to stabilize with minimal changes, not rewrite.
Can vibe code be rescued?
About 90% can. Judge by the last 30 git commits, development time, and whether it builds cleanly. No git history, failing builds, wrong architecture, or serious security holes mean rewrite instead.
How long and how much does it take?
A moderately messy project can be stabilized in ~3 weeks (90 hours). Mentry offers a 30-minute rescue consultation for NT$1,500 and a full rescue project from NT$30,000, including the 7-step SOP and 30 days of free support.
When should you rewrite instead?
When there’s no git history, it won’t run, the architecture is wrong, there are serious security issues, or the business logic itself is wrong. Rule: if rescuing takes more than 50% of a rewrite’s time, rewrite.
Further reading — Engineers in the AI Era series
FAQ
- Can the code I wrote with AI actually be rescued?
- About 90% of the time, yes. Judge it by the quality of the last 30 git commits, how long the project has run, and whether it builds cleanly. Clear commit specs plus a passing build give the best odds.
- When I start a rescue, do I just dive in and change the code?
- No. The first step is building a safety net. Create a rescue branch, tag and freeze the repo, and run a full build to preserve evidence before reading what the AI wrote line by line. With a baseline, you know what you break later.
- When should I just rewrite instead of rescuing?
- Rewrite in five cases: no git history, it won't even run, the core architecture is wrong, there are serious security issues, or the business logic itself is wrong. Rule of thumb: if rescuing takes more than 50% of a rewrite's time, rewrite.
Building something and stuck?
Get the field notes every two weeks, or reach me directly on LINE.