Vibe code rescue

Frequently askedquestions

• What counts as 'vibe-coded' — when should we call you?

  Vibe code is the codebase produced when an AI-assisted tool (Cursor, Claude Code, Copilot, Lovable, Bolt) ships a working v1 fast and a maintainable v2 slowly. The hallmarks: features work in the happy path but break on edges, the same logic exists three times in slightly different shapes, types are stringly-typed or missing, tests are sparse or coupled to implementation, and every new feature breaks an unrelated one. If your team is now spending more time fighting the codebase than shipping into it, that's the signal.
• What do you actually do to the codebase?

  First we run an AI Technical Audit — usually a few days — and produce a written assessment of where the architecture is fighting you. Then a rescue sprint stabilises the urgent issues: failing tests, leaking memory, broken builds, security holes, deploy-blocking flakiness. After that comes the re-architecture phase, which is the longer arc: pulling shared logic into typed modules, separating side effects, adding a real test surface, simplifying the data layer, and writing the runbooks the original developer never produced. None of this is a from-scratch rewrite.
• How long does a typical rescue take?

  The audit takes three to seven business days. A focused stabilisation sprint runs two to four weeks; broader re-architecture engagements run six to twelve weeks depending on how much surface needs work and whether feature delivery continues in parallel. Equity-partnership rescues are longer because we stay on as ongoing technical partners. The audit is fixed-price so you can stop after it if the verdict is "this is fine, leave it alone."
• Will you rewrite from scratch or refactor in place?

  Almost always refactor in place. Rewrites have a terrible track record — they take longer than projected, they reproduce the original bugs in new locations, and the business stops shipping while they run. The exceptions are narrow: when a single load-bearing decision (wrong database, wrong rendering model, wrong language) is doing all the damage, replacing that one piece is cheaper than untangling the rest. Even then we replace it in place, not by starting a new repository.
• Can you keep shipping features while you stabilize the codebase?

  Yes — and usually we have to, because the product cannot freeze for three months. We run rescue and feature work on parallel tracks: critical-path features go through a hardened path we set up in the first week, while structural work happens against the same codebase under feature flags. Sometimes a planned feature gets postponed because shipping it on the current architecture would deepen the damage; we will say so explicitly and propose a sequencing that avoids it.
• What if the original prompts and AI history are lost?

  It rarely matters. The prompt history of an AI-assisted codebase is interesting archaeology but not useful structurally — the patterns are visible in the code itself and the bug surfaces are visible in production behaviour. We work from what's in the repository, the issue tracker, and a few hours of conversation with whoever last touched it. If the only documentation was in a Cursor session that's now gone, that's the same situation as inheriting any undocumented codebase: solvable, just slower the first week.