It is 11 at night and a client's checkout has stopped taking payments. The developer who built that module was moved to another account three months ago. The engineer on call opens the file, sees clean and well-formatted code, and realises that nobody on the current team has ever read it closely.
The module took two days to build with an AI assistant. Understanding it tonight will take longer than that. Every IT services company will recognise this moment, and in 2026 we are going to see much more of it.
My view is simple. AI-generated code maintenance is where services projects will now succeed or fail, and the code itself is rarely the problem. The problem is lost knowledge.
What changed in IT services delivery when AI started writing the code
Services companies used to sell time and skill. A client paid for developer hours, and those hours produced two things together: working code and a team that understood it. We never priced the second thing separately because it came free with the first.
AI split them apart. Today a team can deliver a feature in a fraction of the old hours, and the client sees a faster sprint. What the client does not see is that the understanding produced during those hours has shrunk as well.
The industry numbers match what we see on the floor. According to the 2024 Accelerate State of DevOps report from Google's DORA team, a 25% rise in AI adoption was associated with an estimated 1.5% dip in throughput and a 7.2% dip in delivery stability. A September 2026 Computer Weekly report describes software teams struggling to keep pace with the volume of AI-produced code.
For a product company, that is an internal headache. For a services company, it is a contract problem.
Three ideas every delivery team must understand
Code became cheap, context did not
When code was expensive, we protected it. Now code is cheap, and the scarce resource is context: why this integration retries, why this discount rule has an exception for one region, why this report runs at 2 a.m. Brian Houck makes a related point in his September 2026 essay on the quality paradox of AI-generated code: output is easy to measure, while quality lives in things that are much harder to count.
The handover is where knowledge dies
In services work, knowledge leaves a project at three predictable moments. A developer rotates to another account. The project is handed over to the client's own team or to a new vendor. The warranty period ends and the maintenance contract begins with a different, cheaper team. AI does not create these moments. It makes each one more dangerous, because less understanding was built in the first place.
We learned this the hard way. On one engagement, our team had used AI assistants heavily and shipped ahead of schedule, and we were proud of it. During handover, the client's architect asked a simple question about why a background job processed records in a certain order. Our lead developer paused, opened the code, and started reading it in front of the client. The code was fine. The meeting was not. We spent the next two weeks, unbilled, writing decision notes that should have been written during the sprints.
Fixed-price maintenance assumes someone understands the system
Most annual maintenance contracts are priced on an assumption nobody writes down: the support team can understand the system quickly. When a large share of the code was generated and never deeply reviewed, that assumption breaks. The first serious ticket after the warranty ends becomes an investigation, and investigations do not fit in fixed-price buckets.
| A handover of code without a handover of understanding is a box of spare parts with no manual. |
How should an IT services company change its delivery process for AI-generated code?
An IT services company should treat system understanding as a contracted deliverable. That means a definition of done that includes an explain-back by the author, short decision records inside the repository, a named owner for every module, recorded knowledge-transfer sessions at handover, and maintenance pricing that starts with a knowledge audit of the system.
Here is the sequence we now follow. We got some of these wrong before we got them right.
- Add explain-back to the definition of done. The developer who merges AI-assisted code explains it to a reviewer in plain words. If they cannot, it waits.
- Keep decision records in the repository. Three lines per important choice: what we decided, why, and what we rejected. We tried long design documents first. Nobody read them.
- Name a human owner per module. An AI assistant cannot join an incident call, so the ownership table has only names of people in it.
- Tell the client how AI was used. We now disclose which parts of a system were heavily AI-assisted. Clients have reacted well, because it tells them where to ask more questions.
- Record handover sessions. The receiving team explains the system back to us, on video, before sign-off. Their questions become the missing documentation.
- Start every maintenance contract with a knowledge audit. Before quoting fixed support, a senior engineer maps which modules the team truly understands and which ones are black boxes.
- Train juniors to read before they generate. Code reading is now a core skill, and we assess it in hiring.
| Where most firms lose money. Pricing a maintenance contract on lines of code or number of screens, without checking how much of the system the support team actually understands. The black-box modules eat the margin in year two. |
But here's the catch. None of this works if leadership keeps celebrating sprint velocity alone. We made that mistake for a few months and quietly rewarded the teams that were building the biggest future bills.
How do you measure whether your team still understands the system?
You measure system understanding with signals that fall when knowledge is lost: time to resolve the first incident in a module, the number of modules at least two people can explain, the share of important merges with a decision record, and how many handover questions the delivery team can answer without reading the code live.
Success does not mean using less AI. Our teams use more AI today than a year ago. Success means the client can call us at 11 at night and the person who picks up can find the problem without first reverse-engineering their own work.
The METR team's July 2025 study is a useful reminder here. Experienced developers felt 20% faster with AI but were 19% slower. If a team cannot feel its own speed accurately, it will not feel its own knowledge gaps either. Measure them.
I wrote a more personal take on this topic, why lost knowledge is the real crisis behind AI-generated code, for readers who want the broader argument beyond services delivery.
Your 24-hour challenge
Do one thing before this time tomorrow. Pick one module your team shipped in the last 90 days with heavy AI help. Ask its owner to explain it in ten minutes to someone who has never seen it, with the code closed. Write down every question they could not answer.
That list is your real maintenance risk, and it is also your first decision record. Clients will not remember how fast you delivered. They will remember whether you could fix it when it broke.
Frequently asked questions
Who is responsible for AI-generated code in an outsourced project?
The delivery partner that merges AI-generated code is responsible for it, exactly as it is for code typed by hand. An AI assistant cannot own a defect or join an incident call. Contracts should name a human owner for each module and require that owner to explain the code before it ships.
What should a software handover include when AI tools were used?
A software handover with AI-assisted code should include the source code, short decision records explaining why key choices were made, a named owner per module, recorded explain-back sessions with the receiving team, and a list of areas the delivery team itself considers poorly understood. Code alone is not a complete handover.
Does AI make software maintenance cheaper?
AI makes routine maintenance tasks such as small fixes and refactors cheaper when the team understands the system. When the team does not understand the system, AI can make maintenance more expensive, because every change needs investigation first. The saving depends on the knowledge the team kept, not on the tool.
