You built something with an AI coding agent and now someone else has to own it. A client, a buyer, another developer, or you in six months. This guide covers what an AI code handover actually needs to contain, why the usual approach fails, and how to make the whole thing provable instead of hopeful.
People say AI code handover about three separate situations, and most advice quietly assumes one of them. Worth thirty seconds to get the right one.
The first is agent-to-agent session handoff: carrying context from one AI coding session into the next so the agent does not start cold. That is a prompting and tooling question, and it is not what this guide is about.
The second is design handoff, the old designer-to-developer workflow with AI in the middle. Also not this guide.
The third is the one that has real money attached: delivering software that was substantially built by AI agents to a human being who has to own it from now on. A freelancer shipping a client project built with Claude Code. An agency delivering an app the team vibe-coded in a fortnight. A founder selling a product whose codebase no employee has read end to end. That transfer of ownership is what the rest of this page covers.
A traditional project accumulates its knowledge in places that survive delivery: commit messages, pull request reviews, design docs, the memory of the people who wrote it. An AI-assisted project accumulates its knowledge somewhere much more fragile. The reasoning lives in agent transcripts on one laptop. The decisions live in prompts that were never saved. The claims about what works live in an agent’s confident summaries, which nobody independently checked at the time and nobody can check later.
So the typical delivery is a repository, a deployment login and a goodwill message. We call the result transfer debt: the gap between what was delivered and what the recipient can actually understand, run and maintain. The code may be fine. The recipient has no way to know, and neither, honestly, does the builder. Every question that surfaces afterwards costs a support conversation, and every support conversation erodes the trust the delivery was supposed to buy.
None of this is an argument against building with agents. It is an argument that the handover is now a distinct engineering step, the way testing became a distinct engineering step, because the old implicit version stopped working.
Strip away formats and tools and a recipient needs five things. What exists: the system’s actual shape, services, dependencies and entry points, drawn from the repository rather than from memory. How to run it: setup steps that were executed and shown to work, not steps that should work. What was decided: the choices and trade-offs made along the way, recovered from the agent history where they otherwise die. What was checked: which claims about the system were verified, and how. And what remains unknown: the honest list of things nobody confirmed, stated plainly instead of left for the recipient to discover in production.
The last item is the one that separates a trustworthy handover from a sales document. Every real project has unknowns. A handover that admits them is usable; one that claims completeness is just asking the recipient to find out the hard way. We keep a full item-by-item version of this in the AI project handover checklist, with a template you can copy freely.
Do the handover work at the end of the build, while the agent history still exists and the project still runs on your machine. The sequence that works is: collect the evidence, verify the claims, write the document, then give the recipient a way to check it without trusting you.
Collecting means going through the repository and the agent transcripts and pulling out the facts, claims and decisions. Doing this by hand is genuinely tedious, which is why it usually does not happen. It is also mechanical, which is why we built a tool for it. The Mantyl CLI reads your repository and your Claude Code, Cursor or Codex session history and does the extraction in one run, locally, with secrets redacted before anything is stored:
Verifying means actually executing the setup: clean environment, install, build, tests. Not because the code is suspect, but because an executed check is the only kind of statement a recipient can rely on. Mantyl runs these in a Docker sandbox with the network cut after dependency install, and labels every result with how it was established. A claim the agent made that the code contradicts gets marked as contradicted, with the evidence named. The full labelling vocabulary is the truth model.
The document this produces is a project passport: one artifact holding the architecture, the reproduced setup, the decision log, the verification results and the open questions, each entry labelled with its evidence. You can see a complete one at the example passport, and the passport Mantyl generates for its own repository is published live.
Here is the part most handover advice misses entirely: whatever you deliver, the recipient should be able to check it without taking your word. A handover document that cannot be independently verified is a nicer README. One that can be verified is evidence.
With a passport, the recipient runs one command against the delivered code. It recomputes the file manifest, compares the commit, and re-executes the recorded checks in their own sandbox. If a single file changed since the passport was generated, the command names the file and exits non-zero. That property changes the conversation at delivery from please trust me to please check:
For deliveries where independent proof matters, a stranger buying the codebase, a client who has been burned before, Mantyl Verified re-executes the checks on infrastructure the builder does not control and signs the result, for a one-off £19 to £49 by project size. The free local run is the product; the signature is for the moments proof has to come from someone other than you.
Everything above reads from the builder’s side. If you are the client or the buyer, the short version is: ask for the evidence, not the assurances, and check it yourself. We keep a guide written for exactly your position at how to verify AI-built software you paid for, and a plain-English explanation of the passport document at the recipients page. Neither requires an account, and neither tries to sell you anything the builder did not already pay for.