What I Check When I Inherit a Vibe-Coded App

TL;DR: A new service category has formed with three different names and no coordination between the vendors selling it — evidence that “take over an app someone else built with an AI agent and no longer understands” is now a real, priced engagement, not a hypothetical. This is the intake playbook I run when I inherit one: what I open first (dependency manifest, secrets handling, the honest state of the tests, the deploy path, the data model), the specific failure signatures abandoned AI-built systems share, and the decision most people get backwards — kill-and-rewrite versus stabilize-in-place. I price the discovery audit as a fixed fee, not hourly, because the thing you’re actually selling in week one is a verdict, not time.

The scenario, and why it’s different from a normal handoff

A normal codebase handoff is uncomfortable but tractable. There’s a departing engineer you can still Slack for a week, a README that’s stale but not fictional, a test suite that at least ran once. The AI-build-rescue scenario removes the one thing every handoff playbook quietly assumes: a person who can answer “why is it built this way” from memory.

Three versions of this show up, and they read differently at intake even though the audit is nearly identical:

• The departed contractor. Someone was hired to move fast with an agent, delivered something that demoed well, and left when the contract ended. The commit history is dense but the commit messages are agent-generated boilerplate — “fix bug,” “update component,” repeated hundreds of times, none of it explaining a decision.
• The employee dabbler. Someone inside the company who isn’t an engineer — ops, a PM, a founder’s cousin — built a genuinely useful internal tool with an agent because it was faster than filing a ticket, and now half the company depends on it and nobody who can read the code owns it.
• The founder who hit their ceiling. The most common version I expect to keep seeing: a non-technical or lightly-technical founder built a real product with Claude Code or Cursor, got it to paying customers, and hit the point where the next feature requires understanding the system as a whole instead of describing the next change in isolation. This is the inverse of the seat I’ve written about for an AI founder walking into technical due diligence — same underlying system, but here nobody’s grading it for an investor. Somebody just has to be able to change it safely, starting now.

In all three, the constant is the same: no docs, no tests you can trust, and no living person to ask “why.” That’s precisely the gap I’ve written about from the new-hire side in onboarding an agent-heavy codebase — except here there’s no one left to ask, ever, and the whole system has to be understood from evidence alone. That’s the job description for the first week.

The market told on itself

I went looking for who’s already selling “fix the app an AI built and the builder walked away from,” expecting a niche. I found three unrelated vendors, three different names, live right now. Coretechs Consulting — a Kensington, MD dev shop running since 1986 — sells AI Code Rescue. Nine by Six, a web agency, sells AI Build Rescue for projects that stalled 80% of the way to launch on Cursor, v0, Lovable, or Bolt. Sam Carlton, a solo consultant, offers AI App Rescue — workflow mapping and a 30-day plan.

None of these three cite each other, and none reads like it copied the others’ positioning — they landed on the same offer independently, which is stronger evidence than any one of them alone that there’s now real inventory of abandoned AI-built systems to work through. And the pricing shape one of them publishes — Nine by Six lists its audit from $499 before any fix work — is close to right, for reasons I’ll get to. The pattern behind why this category exists is the one I’ve been documenting from the inside for a while: agents optimize for tests going green, not for a system a stranger can maintain a year later, and eventually somebody other than the original builder has to open the result.

What I open first

The order matters, because each step either rules out a bigger problem cheaply or tells you where the expensive one is hiding. I run these roughly in this sequence on any inherited system, agent-built or not — but an agent-built one changes what I expect to find at each stop.

The dependency manifest, before anything else. package.json, mix.exs, requirements.txt — whatever the language uses. An agent working fast and unsupervised tends to add a new library for a problem the codebase already solved three files over, because it only knows what’s in its context window and has no map of what already exists in the repo — the same reinvented-helper pattern that shows up constantly in agent sessions. A manifest with four different HTTP clients or three different date libraries isn’t a style complaint; it’s a fast read on how much of the system was built with no one holding a consistent mental model of it.

Auth and secrets handling, second. Where do credentials live, how does a request get authorized, and is there a consistent boundary or does every route roll its own check. This is a five-minute grep, and it’s the single highest-signal five minutes in the whole audit — I’ll get into why in the failure-mode section below.

Test coverage as it actually is, not as it’s described. Run the suite. Read what it actually asserts, not the count of files that pass. A “we have tests” claim in an inherited AI-built system needs verification more than almost any other claim, because generating a test that passes is exactly the failure mode agents default to when the intent behind a feature was never made explicit. This is a different read than the same check in a diligence engagement, too — there you’re grading the claim’s credibility for someone else’s decision; here you’re deciding whether you can safely change a line without breaking a customer who’s already relying on it.

The deploy path. How does code get from a laptop to production, who has the credentials, and is there a rollback that’s ever actually been exercised. Vibe-coded systems frequently have a deploy path that only ever worked because one person’s local machine had the right environment variables set — which is fine until that person is the one who left.

The data model, last, because it’s the slowest to audit and the hardest to fix later. Is there a schema at all, or is shape enforced only by whatever the frontend happens to send? Are there migrations, or did the table get altered by hand against production more than once? This is the one place where “we’ll fix it later” gets exponentially more expensive with every week of new data written against an unstable shape.

The failure signatures, and which ones are structural

Not every gap in an inherited system is equally alarming — the calibration question is the same one I use in due diligence: is this expected at this system’s stage, or is it a genuine structural risk. A few signatures show up often enough — in my own agent-driven work, and in the scan data above — that they’re worth checking by name.

Plaintext or hardcoded secrets. This is the one I check first because it’s the cheapest to find and the most binary to grade — either the key is in the repo or it isn’t. It’s also not a hypothetical risk with AI-generated code: GitGuardian’s 2026 State of Secrets Sprawl report found Claude Code-assisted commits leaking secrets at a 3.2% rate against a 1.5% baseline across all public GitHub commits — roughly double, though the report is careful to attribute the gap to developers overriding or ignoring guardrails under time pressure, not a tool failure (GitGuardian, 2026). Separately, Escape.tech scanned roughly 1,400 applications built on vibe-coding platforms and reported 2,038 highly critical vulnerabilities and 400+ leaked secrets, including 175 instances of exposed PII — bank account data among it (Escape.tech). If you’re inheriting a system built the way most of these were, assume there’s an exposed credential somewhere until you’ve grepped and disproven it — my checklist for the actual remediation is in managing secrets in an agent-driven workflow.

Tests that assert nothing. Not “no tests” — that’s an honest, visible gap. This is a green suite that passed because it was written to observe the code’s current behavior and lock it in, not to check the behavior against what the feature was supposed to do. It’s the specific pattern I’ve written up in detail from my own review sessions in the tautological-test failure mode, and I’m not going to re-list the catalogue here — the short version for intake purposes is: read the assertions, not the pass count, and ask of each one whether it would fail if the behavior were wrong.

Dead endpoints and stale routes. Agents rarely delete. Ask one to replace a flow and the old route often survives, unreferenced by the current frontend but still live, still deployed, and still an attack surface nobody’s thinking about because nobody remembers it exists.

Mock or seed data left in a production code path. A fixture built to make a demo look good during development that never got swapped for the real integration — a hardcoded response, a stubbed payment confirmation, a “success” branch that never actually calls the service it claims to call. This one is dangerous specifically because it looks like working code in a walkthrough and is invisible until the exact moment someone relies on it being real.

Kill-and-replace vs. stabilize: the actual decision

The instinct on seeing a system with several of the above is to burn it down and start clean. That’s usually the wrong call, and it’s worth being explicit about why, because the wrong call here is expensive in a specific way: a rewrite throws away the part of the system that’s actually validated — the fact that real users are using it and it mostly works.

The framework I use is closer to triage than to a rewrite-or-don’t binary:

• Stabilize in place when the core data model is sound and the failure signatures are concentrated in a knowable set of files — the auth boundary, one integration, the deploy script. You can fix a bounded set of specific things faster than you can rebuild and re-validate an entire system, and you keep the thing that’s genuinely hard to fake: production traffic that already exercises the happy paths correctly.
• Kill and rebuild the specific module, not the app when one component is rotten in a way that’s cheaper to replace than to understand — commonly the auth layer, if it was clearly bolted on route-by-route with no consistent boundary, or the data layer, if the schema was never designed and just accreted from whatever the frontend sent over time.
• Full rewrite is the answer far less often than instinct suggests, and it’s only right when the data model itself can’t be trusted — when you genuinely don’t know what’s real in the database because nothing enforced its shape — or when the system has no meaningful production usage yet, so there’s nothing validated to preserve by keeping it.

That reframe is the actual point of the audit. A technically embarrassing codebase serving real paying customers with an intact data model is usually worth stabilizing. A clean-looking one with no data integrity and no users yet is often cheaper to replace than to fully understand.

Pricing the takeover: fixed-fee audit, then a retainer

Only one of the three above publishes a price for the audit itself, which I think is the piece they’re all circling and worth naming explicitly, because it’s a different pricing shape than most of my consulting work. I’ve written separately about pricing ongoing feature work when an agent is doing the building — that post is about milestone billing for defined, forward-looking scope, where the client and I both roughly know what we’re building next. A takeover audit is the opposite problem: neither of us knows what’s actually in the system yet, which makes hourly billing the worst option for both sides — it pays me to find more problems and pays the client for uncertainty they can’t budget against.

So I price the intake audit as a flat fee, scoped to a fixed output: a written findings report, the failure-signature checklist above scored against the actual system, and the kill-vs-stabilize recommendation with a rough cost estimate for whichever path it points to. That’s the distinction from fixed-bidding remediation, which I won’t do sight-unseen: I’m fixing the price of the report, not of whatever the report turns up. That’s a bounded deliverable regardless of what I find inside, which is exactly the property a nervous founder or a company that just discovered its internal tool has no owner needs from the first engagement — a fixed number they can say yes to before committing to anything bigger.

What comes after the audit is a retainer, not a per-ticket quote, because stabilizing an inherited system isn’t a fixed scope of work — it’s an ongoing judgment call about what to fix now, what to fix next, and what’s fine to leave alone, applied by someone who now actually understands the system because they did the audit. That’s a different shape of engagement than shipping the next feature on a system everyone already understands, and pricing it like the same thing undersells the actual value: the audit is buying certainty about what you own, and the retainer is buying the judgment to keep making it better instead of worse.

If you’re staring at one of these right now

If you’re a founder who built past the point your agent can carry alone, an operator who just found out the internal tool the whole team depends on has no owner, or you’re the one who has to make the call on whether to hand a client’s inherited system to a rescue vendor or bring someone in-house to own it — that first audit is the highest-leverage hour you can spend, and it’s the one most people skip because it feels like paying to find bad news. Let’s talk about what that first audit should actually cover for your system.