For code you did not write and cannot fully explain
AI-Built Rescue
Founders discover the same way every time: a bug that shouldn't exist, an investor question nobody can answer, or a security report naming something the team never wrote by hand. The tool that built it cannot be interrogated afterward. This is the dedicated path for finding out exactly what is underneath. The moment you are in changes what we do first.
What an AI-Built Rescue produces
The findings register and the repair-or-rebuild call, explained by the engineers who write them.
90 secSample frame · video pending01One problem, three moments
Name the moment you are in.
Whether the code is still being written, already live and misbehaving, or the reason you are weighing a full rebuild, the same discipline applies before you spend another dollar guessing. Read what is actually there, name what it can be trusted to do, and separate what is worth keeping from what is worth replacing. The urgency changes with each moment; the method for finding the truth about the codebase does not.
Where are you in the AI-built problem right now?The right first move depends on how urgent this already is. Pick the moment that matches and the recommendation adjusts.
Pre-launch AI code audit
An audit before launch catches what a demo cannot show: the paths nobody has exercised and the assumptions a tool baked in without anyone to cross-examine it.
A findings register within a week, naming what is safe to ship and what needs work before real users touch it.
- Code provenanceCan anyone on your team explain why this logic exists?A traced comparison of stated intent against actual behaviour for the parts nobody can currently justify.
- Security exposureWhat did the tool expose without anyone reviewing it?A review of credentials, endpoints and access controls the tool generated unsupervised.
- Architecture ceilingWhat breaks first as real usage grows?An honest read of where the current structure stops holding under load.
None of the three moments fit, or the code is only partly AI-generated? Describe the situation instead
02Days, not weeks, when it matters
Built to move at the speed your incident does.
The pace matches your situation rather than a fixed calendar. A live incident gets a same-week read, a pre-launch worry gets a fuller pass without invented urgency, and a rebuild question gets a proper comparison rather than a rushed guess. Either way, you get a stated position before most calendars would even call it week one.
Triage and access
A short call to place your situation precisely, then read-only repository access and whatever monitoring, ticket history or incident notes already exist, so nothing gets re-explained twice.
What arrives firstReading the actual code
Every module is read against what it claims to do. Attention goes to error handling nobody has tested and logic no person would choose to write this way.
Line by lineFindings ranked by damage
What will break, what already has, and what is merely inelegant get separated and ranked, each one carrying a plain recommendation your team can act on immediately.
A verdict, not a vibeHandover and next move
The register, any urgent fixes already made, and a costed path forward are handed to your team directly, whether the next step runs through us or somebody else entirely.
Yours either way
03The rescue record
Four documents that outlive the panic.
This is not a slide deck reassuring you that things are fine. It is a working record naming every risk, priced options for fixing or replacing what is broken, and a handover built so your own engineers can question the system going forward. Every document is written to be handed to someone else entirely, including a different vendor, without losing its meaning.
Risk-ranked findings register
Every defect is named and ranked by the damage it could plausibly cause, then marked safe to keep, repairable with bounded effort, or not worth saving at all.
Security and data exposure
Credentials, open endpoints, and places where user data can leak, duplicate or silently disappear, each one listed with a severity rating your security team can prioritise against.
Stabilisation or rebuild plan
Two costed routes rather than one assumed answer, so the choice between repairing what exists and replacing it rests on numbers your finance team can independently verify.
Ownership handover
A direct walkthrough with your own engineers, conducted so the system stops depending on a tool that cannot be cross-examined about its own decisions.
04Evidence and proof
Rescues that changed the verdict on AI-built code.
Every rescue example below is a placeholder awaiting the client's written approval before anything goes live. They exist only to demonstrate the level of proof we intend to publish once permission is granted. Ask us directly for the underlying detail before you decide anything.
Explore case studiesA production outage traced to a single AI-generated function.
Aster North's checkout had been failing intermittently for weeks before anyone found the cause: a payment function an AI tool had written, which quietly retried failed charges without checking whether the first one had already gone through.
- Time to root cause
- 36 hours
- Repeat incidents since
- Zero
We finally had someone tell us which parts of our own product we could trust.
Sample · pending client approval
05When this isn't the right door
Three situations where rescue is not what you need.
Not every AI-generated codebase needs a full rescue: some need a lighter assessment, an earlier scoping conversation, or additional engineers rather than a diagnosis. Telling you that honestly costs us a booking today, and it is still the right trade. The three situations below are the ones we see most often outside a genuine rescue.
- Codebase Assessment
The AI-written part is a small slice
If only one feature was AI-generated inside an otherwise human-built system, the wider codebase assessment covers more ground for the same money and time.
- Project Scoping
Nothing has actually been built yet
If the AI tool has only produced a rough prototype and you are still deciding what to properly commission, project scoping is the earlier and considerably cheaper step to take first.
- Hire Developers
The real gap is capacity, not a verdict
If your team has already diagnosed the problem and is only short on capacity, bringing in additional engineers is the direct route, not another audit.
06Straight answers
Questions before you commit to a rescue.
01How fast can the audit start?
Usually within a few days of getting repository access, because the first pass does not require a full team. Live incidents get triaged sooner, sometimes within a day, while calmer situations follow the normal booking queue.
02Do you need our AI tool's chat history or prompts?
It helps but is not required. The code itself tells most of the story once someone reads it line by line, and prompts mainly explain intent rather than behaviour. Where the history exists we will ask to see it.
03What if the code turns out to be fine?
That happens, and it is a good outcome, not a wasted engagement. You leave with a written statement of what is safe, which is worth having whether or not anything was actually wrong.
04Can you fix issues while the audit is still running?
For anything actively dangerous, yes, we flag it the day we find it rather than waiting for the final report. Everything else waits for the ranked findings so fixes are ordered by damage, not by discovery order.
05How do you decide between repair and rebuild?
By the cost of the next six months of changes, not by how the code looks today. If the architecture can absorb what you need next, we repair it. If every new feature would fight the same structural fault, we say so plainly and price a rebuild instead.
06Do you work with Cursor, Copilot, Lovable or Replit output specifically?
Yes, and with output from any other tool, because the review targets the code's behaviour rather than which product wrote it. The failure patterns repeat across tools even when the syntax looks different.
07What happens to code you find is unsafe to keep?
It gets named specifically, ranked by how much damage it could cause, and handed back with a plain recommendation: patch, isolate, or replace. Nothing is deleted or changed without your team's agreement first.