Rescue an AI-Generated Codebase: The Field Guide

The rescue wave the old guard warned about is no longer a forecast. Industry writeups report that a large share of the startup apps built at vibe-coding speed in 2025 now needs rebuild or rescue work — some analysts have simply declared 2026 "the year of technical debt." I see it in inquiries: "We had something built. It worked great. Now nobody dares to touch it."

That makes rescuing an AI-generated codebase perhaps the most valuable engineering discipline of the moment. And almost everywhere, it's approached wrong — with the same tool and the same haste that created the problem.

Why AI debt is different from classic debt

Classic technical debt is taken on knowingly: someone understood the shortcut and took it. AI debt accumulates invisibly: the code was generated, never really read, and looked correct from the outside. Nobody on the team remembers the decision, because no one ever made one.

The pattern is common enough that it has a name now: the spaghetti point. Weeks one through four feel fantastic. Around month three, every new feature starts breaking two old ones. Error handling is missing, logic is duplicated, and the database trusts anyone who asks politely — security audits of AI-built apps routinely find access controls entirely disabled, not misconfigured.

When you take over a system like this, your enemy isn't the code. It's the reflex to start building immediately.

Week 1: triage, not therapy

Before anything gets improved, you need answers to five questions. This is the checklist I start every rescue project with:

1. Does it run reproducibly? Fresh machine, build, deploy, one end-to-end pass. If that fails, that is job number one — not refactoring.
2. Where is the blast radius? What's in production, who depends on it, where do money and personal data flow? Rescue prioritizes by damage potential, not by code ugliness.
3. Security quick-scan. Secrets in the repo, open endpoints, database-level access controls, dependencies with known CVEs. One hour that can save the company.
4. What does the system claim to do? Don't read the docs (there are none) — capture the behaviour. More on that next.
5. Rescue or rebuild? Only decidable now. Rule of thumb: if the core data model is sound and the product is validated, rescue. If both are broken, the honest advice is a controlled rebuild — with discipline this time.

Characterization tests: the safety net comes first

The most important step, and the most skipped one: before you change any code, write tests that freeze the current behaviour — bugs included. Not "what should it do" but "what does it do today." Michael Feathers called these characterization tests, and they're the difference between refactoring and roulette.

This is where AI becomes genuinely useful for the first time: agents are excellent at generating test cases for the golden paths of existing code and at extracting business logic into prose. Have the agent describe and secure before it improves anything. Read before write — the same ordering that decides everything in AI code review.

Rescuing with the agent, without digging deeper

Yes, AI helps with the rescue — using the very tools that made the mess. The difference is four rules:

• Explanation pass first. The agent reads module by module and documents what it finds — assumptions, data flows, dead paths. You correct the prose, not the code. The result is the map for the whole project.
• No change without a net. Every restructuring step requires an existing (characterization) test. No test, no change — the agent writes the test first.
• Small, reviewable steps. One module, one boundary, one pull request. Big "I cleaned everything up" diffs are a firing offence in an unfamiliar codebase — for agents too.
• Boundaries first, cleanup second. Separate the layers (I/O, logic, persistence), then modernize within them. Without boundaries, refactoring just relocates the chaos.

That's how the tool that skipped the last 20% becomes the tool that delivers them after the fact.

What you can do this week

Pick a project you don't trust — an inherited one, an AI-built one, your own from a year ago — and run only triage steps 1 through 3: reproducible run, blast radius, security quick-scan. Three hours, and you'll know whether you have a maintenance problem or a ticking clock.

And if the clock is ticking and nobody in-house has capacity: rescues like these are one of the few engagement types we take on each year — from triage to a handover-ready, tested codebase. Write to hire@halvic.ch.