Can your team maintain AI-written software?

Software gets handed over twice. Once on paper, when the invoice is settled, and once in reality, the first time someone on your side has to change it under pressure. The second handover is the one that counts, and plenty of projects that passed the first fail the second.

AI-written code makes both handovers more important. A working system can be produced far faster than before, which is the point. But the understanding of why it is shaped the way it is does not arrive at the same speed, and it is not in the files.

The test that matters

Here is the only test worth running. Take a real change, not a small practice one. Something a user would notice, touching more than one part of the system. Give it to an engineer on your side who did not build the thing. Let them do it while the original team watches and answers nothing.

If they can do it, you own the software. If they cannot, you depend on whoever built it for every change, whatever the contract says about intellectual property.

This is uncomfortable to run, which is exactly why it is informative. Everyone agrees the handover went well until someone tries to use it.

Why generated code drifts

Handover difficulty is not new. Two things about generated code make it worse, and both are structural rather than a matter of care.

The first is local consistency. A model works from the context it is given. Across a large codebase built over weeks, different parts get generated with different context, so the same problem gets solved three reasonable ways in three places. None of them is wrong. Together they mean a new reader cannot form one understanding and apply it everywhere, which is the thing that makes a codebase fast to work in.

The second is missing intent. Generated code is unusually good at explaining what it does, because comments and naming are exactly what models are good at. It says nothing about what was rejected. Why this approach and not the obvious alternative, which constraint forced the awkward design, what broke last time. That information never existed in text, so it cannot be in the repository. It was in a conversation.

The volume of code adds to both problems. Google's DORA programme surveyed nearly 5,000 technology professionals for its 2025 report and found AI adoption has a positive relationship with delivery throughput and a negative relationship with delivery stability [1]. More change arriving, a higher share of it going wrong. A team inheriting that needs more support than a team inheriting a smaller, slower codebase, not less.

What a real handover contains

Four things, in rough order of how much they matter.

The specification the software was built from. On an AI-native build this is not documentation written afterwards. It is the input the implementation was generated against, so it is the closest thing to a statement of intent that actually shaped the code. If it has been kept current, it is worth more than the code.

The eval suite, and proof it can fail. A new maintainer's first question is "if I change this, will I know I broke something." The suite is the answer. It has to be runnable on their machine on day one, and someone should show that a deliberate break makes the build fail. A suite that has always passed and never failed proves nothing. That is covered in when evals give false confidence.

A short record of the decisions. Not a design document. A list of the choices that would look wrong to a newcomer, each with the reason and the alternative that was rejected. Ten entries of three sentences beats forty pages nobody opens.

A runbook for the routine emergencies. How it deploys, how to roll back, where the logs are, what the alerts mean, which failures are expected and safe to ignore. This is the artefact people skip and then need at two in the morning.

The specification is the asset now

There is a reversal here worth stating on its own, because it changes what you should be negotiating over.

On a hand-written project, the code is the artefact. It holds the effort, and everything else describes it after the fact. On an AI-native project the relationship reverses. The implementation is the cheap, regenerable part. The expensive, difficult part is the precise statement of what the software must do, because that is what took the arguing, and it is what any future change has to be checked against.

That has a practical consequence. If you have the specification and the eval suite, a large part of the implementation can be regenerated. If you have only the implementation, you have the one thing that was easy to produce and none of the reasoning that made it correct. A team that hands over a repository and calls it done has given you the easy part and kept the valuable part.

It also explains why the specification has to be current rather than the version written before the work started. Requirements change during a build. A specification that stopped being true in week two is a historical document, not a maintainable asset, and the gap between it and the code is exactly where the next maintainer will make mistakes.

Getting it, rather than hoping for it

Ask for these while you can still insist on them, which means in the contract, not after the last invoice.

Three clauses matter most. Name the artefacts as deliverables in their own right, so the work is not complete without them. Make the handover test above an acceptance condition, with a named engineer on your side and a real change. And schedule a support window after the handover that is deliberately consultative, where the original team answers questions rather than making changes, because the moment they start making the changes again you depend on them again.

One thing worth saying plainly: a team that has built this way properly will welcome all three, because the artefacts already exist as a by-product of how they work. A team that resists is usually telling you the specification was never written down and the suite is weak. That reaction is itself a useful answer.

The honest limit

None of this makes an unfamiliar codebase feel familiar. Your engineers will still be slower in it for a while, and expecting otherwise will annoy everyone. What a good handover buys is that the slowness is temporary and self-resolving, rather than a permanent cost that sends you back to the original team for every change.

If you are deciding what to keep in-house in the first place, in-house vs outsourced engineering covers that split, and how to review AI-generated code covers what your reviewers should be looking at while the work is still in progress.