1
0 Comments

We can write code faster than we can read it now. Nobody's talking about the bill.

I shipped a feature last month that I did not fully understand.

Not a small one either. It touched our billing retry logic. The AI wrote most of it, I read it the way you read the terms and conditions before clicking agree, the tests were green, and it went out. Two weeks later something broke in a way that made no sense to me, and I sat there staring at code that had my name on the commit, trying to reverse engineer what past me had apparently agreed to.

That was the moment it clicked for me. The bottleneck in software used to be writing the code. That bottleneck is basically gone. The new bottleneck is understanding the code, and almost nobody is measuring it.

Here is what changed underneath us this year. Roughly half of new code is now AI generated. Surveys put developer adoption of AI tools around 84 percent, but trust in the output has actually dropped, down to under a third. So we have more and more people shipping more and more code that fewer and fewer of them can explain. The machine writes at a couple hundred lines a minute. A human reads carefully at a fraction of that. The gap between those two numbers is not neutral. It accumulates.

Someone smarter than me gave it a name recently: comprehension debt. It is like technical debt, except technical debt at least shows up eventually as messy code you can point at. Comprehension debt is invisible. The code can be clean, the tests can pass, the PR can merge, and the debt is simply that the humans on the team no longer know how their own system works. You do not see it on any dashboard. You see it the day something goes wrong and everyone in the incident channel is reading the code for the first time.

The frustrating part is that we measure everything except this. We have DORA metrics for deployment frequency and lead time and failure rate. We track velocity and cycle time and a dozen other things. All of those tell you how fast the code is moving. None of them tell you whether anyone still understands what is moving. A team can look elite on every delivery metric and be quietly hollowing out its own understanding of the product.

I keep coming back to a study I saw where junior engineers who leaned on AI scored around 50 percent on comprehension quizzes about their own work, versus 67 percent for the ones who wrote it by hand. The interesting bit was not the gap itself, it was that the people who actively interrogated the AI, asked it why, pushed back, scored much higher than the ones who just accepted the output. So the tool is not the problem. The passive relationship with the tool is the problem.

I do not have this fully figured out. What I have started doing personally is stupidly simple: before I merge anything the AI wrote, I make myself explain the tricky parts out loud, as if a senior reviewer were about to grill me on why it works this way and not another way. If I cannot, I do not merge yet. It is slower. It has also caught two genuinely bad decisions that the tests would have happily let through.

I think this is going to be one of the defining engineering questions of the next few years. Not can AI write the code, it clearly can, but can we keep up with understanding what it wrote well enough to be responsible for it. Speed without comprehension is just debt with a shorter fuse.

Curious whether other people here feel this or whether it is just me being paranoid. How much of the code you shipped in the last month could you actually explain under pressure?

on July 15, 2026