You can ship a lot of software before anyone notices the team no longer understands it.

That is the real risk in AI-assisted coding.

Ugly code is a familiar problem. So are bugs, bad architecture, and sloppy review. We already know how to talk about those.

The nastier problem sits in the heads of the people building the thing.

AI tools can now generate working code at a pace that easily outruns human comprehension. You prompt, it scaffolds. You ask for a fix, it rewrites three files and updates the tests. You ask for a feature, it obliges with perfect confidence and a cheerful summary. The build goes green. Everybody moves on.

Until they have to change it.

That is when the hidden bill arrives.

Margaret-Anne Storey has a useful name for it: cognitive debt. Technical debt lives in the code. Cognitive debt lives in the developers' minds. It builds when teams go faster than their shared understanding can keep up.

The phrase works because many developers have already felt this happening without a name for it. The code may still compile. It may even look tidy. Meanwhile the mental model of why the system works, where the sharp edges are, and what must not be touched starts to thin out.

And once that happens, velocity becomes theatre.

Ownership is the real issue

I am not anti-AI coding. Far from it. The tools have crossed a real threshold in the last year, and pretending otherwise is its own kind of denial.

Used properly, these tools are superb. They are brilliant for boilerplate, scaffolding, refactors, test generation, migrations, and all the dull but necessary work that drains energy from a project. I made a version of this point in The 75/25 split: the tools are extraordinary, then suddenly awkward.

That still feels right.

The mistake is assuming the main risk sits in the code the model produces. Often the bigger risk sits in how humans relate to that code.

At the level of the individual rather than the team, the same dynamic shows up as cognitive surrender: the quiet habit of accepting the machine's output without doing the harder thinking yourself.

Simon Willison put the line in the right place last year: if an LLM wrote every line but you reviewed, tested, and understood it all, that is not vibe coding. It is an LLM acting as a typing assistant. Trouble starts when review quietly degrades into pattern recognition and hope.

You skim. You recognise the libraries. The tests pass. Nothing obviously insane jumps out. So you merge it.

Three days later, somebody asks a simple question about the change and the room goes quiet.

Why does this helper exist?

Which assumption is this cache relying on?

What breaks if the upstream API starts returning partial objects?

Nobody is sure.

That is cognitive debt.

Faster output can make experienced developers slower

This is where the hype gets awkward.

A 2025 METR randomised controlled study looked at experienced open-source developers working on mature repositories they already knew well. Before the test, developers expected AI tools to speed them up by 24 per cent. After doing the work, they still thought AI had sped them up by 20 per cent.

In reality, they took 19 per cent longer.

The finding matters because it cuts against the easy story. We like to imagine that AI always compresses effort. Sometimes it just moves the effort somewhere less visible: into prompting, re-reading, correcting, waiting, checking, and rebuilding confidence that the change is actually sound.

The tool may save typing while increasing cognitive load.

No contradiction there. That is the point.

When the machine produces code faster than you can absorb it, the work has not vanished. It has changed shape. Less composition. More supervision. Less writing. More judging. More effort spent keeping the theory of the system alive.

That shift, from producing to judging, is the same one I keep coming back to: when execution gets cheap, everyone is a product manager now, and the rare skill becomes deciding what is actually good.

A codebase is shared memory

Peter Naur's old line still holds: a program is not just its source code. It is a theory living in the minds of the people who understand it.

That theory is rarely neat. It is distributed. One person knows why the billing logic is slightly strange. Another knows which customer edge case forced the ugly branch in the onboarding flow. Somebody else remembers why a seemingly redundant retry loop is not redundant at all.

Good teams keep enough of that theory alive to move quickly without becoming reckless.

AI-generated code changes the economics of that shared memory.

When the first draft of every feature arrives fully formed, the temptation is to stay at the level of intent and let the machine handle the plumbing. That feels efficient. Sometimes it is efficient. But it also means fewer of the little cognitive reps that used to build ownership: tracing data flow, choosing structure, naming carefully, spotting awkward couplings, discovering that one innocent change actually ripples through six assumptions.

You do not just lose keystrokes. You lose contact.

And because the output often looks polished, the team can mistake readability for understanding.

Those are not the same thing.

Why this debt is more dangerous than technical debt

Technical debt is at least visible once you know where to look. Slow tests. Tangled modules. Repeated workarounds. Strange dependency choices. Mess leaves clues.

Cognitive debt is quieter.

It shows up as hesitation. Engineers avoiding parts of the system they no longer trust. PR reviews turning vague because reviewers cannot hold enough context to challenge the change properly. A growing dependence on one or two people who still remember how the thing hangs together. Teams becoming strangely cautious around code that was supposedly accelerated into existence.

The codebase may even look cleaner than before.

Which is what makes the problem easy to miss. AI can produce code that appears more consistent than a human team's natural style, while the team's real understanding becomes more fragmented underneath.

So the system looks healthier right up until an important change, incident, migration, or edge case reveals that hardly anybody has a firm grasp of it.

Then the repair job is no longer technical. It is intellectual.

You have to buy back understanding.

Small teams should worry about this first, not last

Enterprise teams can hide comprehension loss for longer because they have more people, more ceremony, and more spare capacity for recovery.

Small teams do not get that luxury.

If a two-person or five-person team starts shipping AI-assisted changes nobody fully owns, the debt compounds quickly. The same people doing the shipping are the same people who must debug the incident on Friday afternoon, untangle the regression next Tuesday, and explain the architecture to the next hire three months later.

So I do not buy the argument that cognitive debt is an edge case for big engineering organisations. It is a management problem for any team using AI beyond toy projects.

It connects to something I've argued before. As AI raises the floor and everyone becomes full-stack, the thing that stays scarce is the judgement to know what you're actually looking at.

If you run a small software business, or even just a product team inside a non-software company, this is the question worth asking every week: which recent changes are we now relying on that no human here could confidently explain from first principles?

If the answer is more than a handful, the speed gains are probably overstated.

Practical ways to keep ownership

You do not solve cognitive debt by banning AI.

You solve it by refusing to confuse generation with comprehension.

The practical response is fairly ordinary, which is reassuring.

Start by putting a named human owner on every non-trivial AI-generated change. Make reviews reconstruct the logic of the change, not merely spot obvious defects. Ask somebody to explain it back clearly before it ships. Keep the changes smaller than the model would prefer. Leave short notes about why a decision was made, especially in older systems full of hidden assumptions.

There is also a useful distinction between offloading and outsourcing.

Offloading is healthy. Let the machine handle the dull syntax, repetitive test scaffolding, or first-pass refactor while you stay mentally engaged with the structure.

Outsourcing is different. That is the moment when the machine is effectively doing the thinking and the human is reduced to approving motion.

Debt starts there.

The trick is not to reject speed. It is to make sure speed does not hollow out the people responsible for the system.

The bill arrives later

This is why AI coding debates so often miss each other.

One side points at all the software getting built faster. Fair enough.

The other side points at brittle systems, strange regressions, and developers who are starting to supervise code more than understand it. Also fair enough.

Both things can be true at once.

AI can absolutely increase output.

It can also quietly erode the shared theory that makes a codebase maintainable.

That erosion is the hidden cost.

Not because AI-written code is automatically bad. Often it is perfectly decent. The danger is that teams start accumulating systems they can operate, but no longer really inhabit.

And software always gets expensive the moment nobody can explain it with confidence.

That is when the cheap code stops being cheap.