The invisible debt

24 July 2026 ·5 min read

• building with AI
• understanding

I sat in a meeting last week about a system my own team built, and I couldn’t answer the simple questions. Neither could most of the room. Nobody had been lazy. We’d all put in the hours. So how does a team work this hard and still not understand its own code?

The meeting

It was an engineering meeting, and we were trying to explain to each other how our platform actually worked. The major piece was a workflow engine that runs and chains background jobs.

Someone asked a simple question: when one of those chained jobs fails halfway through, does the whole thing start over, or pick up where it stopped? I opened my mouth to answer and realised I wasn’t sure. I didn’t understand it as well as I should. And I wasn’t alone. Most of the people in the room had gaps too, still unsure about parts of how it fit together.

Nobody had been lazy. In the weeks before that meeting, I’d watched the team put in real hours: writing design docs, mapping out flows, building prototypes, working through problems late.

We’d done all that work. And we still couldn’t fully explain the system we were building. That stung a little, because I’d helped build it.

Understanding used to be free

So why does a team that works this hard still not understand its own system? The answer isn’t effort. It’s where understanding comes from.

When AI writes and reviews the code, understanding stops being free. It used to come built-in. You couldn’t write a function without understanding it. The understanding was the price of getting the thing to work at all.

Reviewing a teammate’s PR did the same job from the other side. To sign off, you had to follow the reasoning. Writing and reviewing were the two moments that forced you to understand.

Both of those moments are now being handed to AI.

The name for it: cognitive debt

Geoffrey Litt gave a talk this month called “Understanding is the new bottleneck” (on YouTube). His argument:

AI has made writing code cheap, and it usually gets it right. So the rare thing now is a human who actually understands what got written.

He borrows a name for what happens when you skip it: cognitive debt. It’s like technical debt, but it’s the understanding you didn’t build. You can run on it for a while. It’s invisible. Then it comes due.

When the debt comes due

And you know the exact moments it comes due.

A bug hits production. Nobody can say which part owns the behaviour. So what’s supposed to be a one-line fix turns into a long back-and-forth with the AI.

Or a customer asks for a small change and you can’t promise what it’ll break. Back to the AI to figure that out.

Back in that meeting, the debt showed up as simple questions I couldn’t answer.

The bigger bill

The obvious cost is money. When no one understands the code, you fix it the only way you have left:

You ask the AI to try again.

And again.

Each try burns tokens and time, and you’re really paying the AI to rediscover something an engineer on the team should have known.

The cost I worry about more? The newest engineers coming up right now.

If they never have to build understanding, they never learn how to. They get very good at accepting whatever the AI hands back, as long as it passes. And “good enough” is where it stops.

But “good enough” has never been where good software comes from. The better way, the idea nobody asked for, the redesign that makes a whole class of bugs disappear? Those come from someone who understands the system deeply enough to see it.

That’s the exact skill cognitive debt lets fade. A generation that can’t answer basic questions about its own code isn’t going to reinvent how software gets built. That reinvention is what companies need. And it doesn’t come from “good enough.”

I’m guilty too

And I should be honest: I’m guilty of this too. Given the choice between shipping fast and slowing down to understand, I pick fast more often than I’d like to admit. The speed feels like progress, but that’s exactly how the debt builds without you noticing.

Fighting the debt with AI

So what do we do? We can’t go back to writing everything by hand. That ship has sailed, and honestly I don’t want it back.

The interesting move, and the one Litt points at:

Use AI to buy the understanding back. Fight the debt with the same tool that ran it up.

A few things I’m trying:

Make the AI teach, not just tell. It’s easy to get an AI to explain a diff. It’s more useful to have it quiz you on the code afterward: what breaks if this value is null? Reading an explanation and being able to answer a question are very different states of knowing. One only feels like understanding. The other is actual understanding. On my team, someone built a skill that reads a set of sources and turns them into a self-paced course: the same idea, automated.

Build a throwaway to poke at. Litt calls these micro-worlds: tiny, disposable playgrounds where you run the confusing thing on its own and watch how it behaves. AI makes them nearly free to build. You learn the system by breaking a copy of it, then you throw the copy away.

Put a regulator on the speed. The whole appeal of AI is speed, so this feels backwards. But if understanding is now the scarce thing, then going faster than you can understand is borrowing against it, at interest you’ll pay later.

The trade

AI made writing code cheap. That’s real, and I’m not giving it back. But the cost shifted from writing code to understanding it. Understanding used to be free: you got it by doing the work. Now it’s the one thing you have to pay for on purpose.