How to Take Over a Vibe-Coded Codebase Without a Rewrite

An increasing share of the products we see started without an engineer. A founder used Cursor, Claude Code, Lovable, Replit, or Bubble to get something shipped. It works. Users pay. Now the founder needs someone who can actually own the code, and the incoming engineer has to figure out what they have inherited.

This is a different problem than a normal engineering handoff. The person who wrote the code is a model, and the person who accepted it was not reading it closely. There is no one in the room who knows why things are the way they are.

The codebase has a different shape than a human-written one

AI-assisted codebases tend to share a few patterns. The code works, but it is rarely idiomatic. File organization reflects the order prompts were written in, not the structure of the domain. Abstractions appear where a human would have used a function and disappear where a human would have used a class. Variable names are often correct in isolation and inconsistent across files.

None of this makes the code bad. It makes it hard to read quickly, which matters because the first week of the takeover is mostly reading.

Start with an inventory, not a refactor

The temptation is to start cleaning. That is almost always wrong. The codebase is the product. Until you understand which parts are load-bearing and which are scaffolding, you cannot tell what is safe to change.

The inventory we usually produce in the first few days:

• Every third-party service, what it does, and who holds the account
• Every credential, where it lives, and which files reference it
• Every route or endpoint, and which ones handle money, auth, or user data
• Every background job, what it touches, and how it is scheduled
• Every place user data enters or leaves the system

This is the minimum surface area a new owner needs to avoid breaking the product by accident in week two.

Fix the things that bleed

A few categories almost always need immediate attention before any other work happens.

Secrets. Hardcoded keys, committed env files, single root credentials with full permissions. These get rotated and moved behind environment variables before anything else is touched.

Billing reconciliation. Local subscription state that does not match Stripe. Webhooks that silently fail. Receipts that are processed by polling rather than by event. Every hour this stays broken costs trust.

Auth. Session handling that does not invalidate on password change. No rate limiting on login. Permissions checked in the UI only. These are the holes that turn into incidents.

Data integrity. Missing foreign keys, columns that are nullable because the initial prompt forgot to specify, writes that are not transactional. These are the issues that produce ghost data you cannot explain three months later.

Everything else can wait.

Leave the working business logic alone

The parts of the code that encode what the product actually does are usually fine. Pricing rules, matching logic, paywall gates, domain-specific transformations. These reflect the founder's judgment about the business, and rewriting them in cleaner code risks breaking behavior the founder cannot describe in a ticket.

The rule we try to hold to is simple. If a block of code is ugly but correct, and it is not in the path of a security or data problem, it can stay ugly for another quarter.

Rewrite is rarely the answer

Once or twice a year, a codebase is structurally beyond repair. The model picked a framework the ecosystem moved away from. The data model has contradictions that no migration can resolve. A critical dependency has been abandoned.

In every other case, the takeover is incremental. Secrets get rotated in week one. Billing and auth get hardened in week two. Observability goes in during week three. The first new feature ships before the end of the first month, on top of the existing code, without a rewrite.

The founder does not lose velocity. They gain an owner.