Experienced developers in a 2025 randomised study were 19% slower when they used AI tools, and they still believed they had been 20% faster. That gap between feeling and fact is the real story of AI-generated code in 2026. The code arrives faster than ever. Our understanding of it does not.
I am very positive about AI coding assistants, and our teams use them every day. My worry is quieter. When you run a services company that has maintained other people's software for many years, you learn that the expensive day is never the day the code is written. It is the day, eighteen months later, when something breaks at midnight and nobody in the room knows why the system was built that way.
That is the maintenance reckoning I see coming. The problem is lost knowledge.
What has changed now that AI writes the first draft
For most of software history, writing code was the slow part. A developer had to think through the logic line by line, and that thinking left a trace in their head. Slow typing was, without anybody planning it, a knowledge transfer mechanism.
Now the first draft appears in seconds. A junior developer can produce in one afternoon what used to take a week. Review, testing and governance have not sped up at the same rate, and a September 2026 Forbes Technology Council piece on future technical debt makes exactly this point: AI writes so much code that the checks lag behind.
The data points the same way. According to the 2024 Accelerate State of DevOps report from Google's DORA team, every 25% increase in AI adoption came with an estimated 1.5% dip in delivery throughput and a 7.2% dip in delivery stability. More code, shipped with less stability.
A Computer Weekly report from this week describes a poll in which software teams say they are struggling to keep pace with the volume AI tools produce. None of this says AI code is bad. It says our habits were designed for a slower world, and the world has moved on without asking them.
What is lost knowledge in software, and why does it matter more than code quality?
Lost knowledge is the gap between the code a team owns and the understanding that team holds about why the code works the way it does. It matters more than code quality because bad code that people understand can be fixed quickly, while clean code that nobody understands becomes risky to touch, slow to change and expensive to hand over.
The program is a theory, and the theory lives in people
In 1985 the Danish computer scientist Peter Naur wrote an essay called "Programming as Theory Building". His argument was simple. The real product of programming is the theory in the programmers' heads: why this table exists, why that rule has an exception, what will break if you change the order of two steps. The source code is only a partial record of that theory.
Naur also observed that when the original team leaves, the theory dies, even if every file survives. Forty years later, AI has made his point sharper. Now the theory can fail to exist from day one.
Cognitive debt grows without any warning light
Technical debt at least shows up in the code. You can see the copy-paste, the missing tests, the ugly workaround. A September 2026 essay from Sogeti Labs uses a better phrase for the new problem: cognitive debt. The burden moves from creating code to reviewing, maintaining and understanding it, and no linter measures it.
Earlier this year I sat in on an incident review for a module that had been written largely with an AI assistant. The code was tidy. It had tests. A capable developer walked us through it, and when I asked why a particular retry ran three times before giving up, the honest answer was: "That is what the assistant suggested, and the tests passed." Nobody had decided it. Nobody knew if three was right for that payment gateway. The fix took ten minutes. Finding out that nobody owned the decision took the whole meeting.
The confidence trap
The METR numbers are the most uncomfortable part. In their July 2025 study of experienced open-source developers, participants expected AI to speed them up by 24%, felt afterwards that it had sped them up by 20%, and were actually 19% slower. If we cannot judge our own speed, we should be humble about judging our own understanding.
| Code you did not write is fine. Code nobody understands is a loan, and the interest is paid at the worst possible moment. |
How do you keep AI speed without losing system knowledge?
Make understanding part of the definition of done. Whoever merges AI-assisted code must be able to explain it without the chat window open, the reasons behind key decisions must be written next to the code, and every module must have a named owner who can defend it. Speed stays; only unexplained code gets stopped.
Here is the practical sequence I recommend. None of it slows a good team down much.
- Make the author explain, not the tool. If a developer cannot explain a change in plain words to a colleague, it is not ready to merge. This one rule removes most of the problem.
- Write the why, briefly. A three-line decision note beside a tricky piece of logic is worth more than twenty pages of documentation that nobody opens.
- Change the review question. Instead of "does this look right?", reviewers ask "what breaks if this fails, and how would we know?"
- Run explain-back sessions. Once a sprint, someone who did not write a module explains it to the team. Gaps show up immediately, and they show up kindly.
- Put orphan modules on the risk register. Any part of the system that nobody can explain is a business risk, just like an expired certificate.
- Teach juniors to read before they generate. Reading code is the skill AI makes more valuable, not less.
| The expensive mistake. Do not measure AI success by lines of code, pull requests or tickets closed. Those numbers rise fastest in exactly the months when understanding is falling. |
Let's be honest. Some teams will read this and say it sounds like more process. It is a little more process. However, the alternative is paying for the same knowledge later, at emergency rates, from people who were never there.
What success looks like, and how to measure it
Success is not zero AI code. Success is a team that uses AI heavily and can still answer hard questions about its own system on a bad day. Here are the signals I watch.
On the last row, GitClear's research on AI-assisted repositories has reported rising churn and copy-pasted code since its 2024 study. That is exactly what you expect when people accept code they have not absorbed.
A few months ago we started asking one simple question in our internal demos: who can explain this without opening the code? The first weeks were uncomfortable. The silence in some meetings told me more than any dashboard had. Today the silence is shorter, and our developers ask better questions of the AI because they know they will have to defend the answer.
The lesson is simple. AI is a brilliant junior colleague who never attends the incident call.
Where to go from here
I remain an optimist. AI will write a large share of our code, and that is good news for anyone who wants to build more with smaller teams. But the teams who win will be the ones who treat understanding as an asset they deliberately protect.
If this topic interests you, read the short, sharp essay on why the problem is not the AI code but that nobody knows anything anymore. Then start one conversation with your team this week: which part of our system would we struggle to explain tomorrow morning? That list is your real technical debt.
Frequently asked questions
Is AI-generated code worse than human-written code?
AI-generated code is not automatically worse than human-written code. It often looks clean and passes tests. The difference is that a human author usually understands the reasoning behind the code, while AI-assisted code can reach production without anyone on the team holding that reasoning, which makes future maintenance slower and riskier.
What is cognitive debt in software development?
Cognitive debt in software development is the growing gap between how much code a team owns and how much of that code the team truly understands. Unlike technical debt, cognitive debt is invisible in the code itself. It appears only when someone must change, debug or hand over a system that nobody can explain.
How can a team check if it still understands its own codebase?
A team can check its understanding with an explain-back test. Pick a core module, ask someone who did not write it to explain what it does, why key decisions were made and what breaks if it fails. If nobody can answer without reading the code line by line, that module carries lost knowledge.
