The numbers are out, and the doomsayers are celebrating.

Two years of the same refrain: "this is going to be a nightmare to maintain." Intuition and zero data. Well, now we have the data, and it doesn't look good. The % of AI-written code keeps climbing, 41% of new code* is now machine-generated. An analysis of over eight million PRs* found significant bottlenecks after adoption, while another study* observed 1.7 times more issues in AI-written PRs. Technical debt rises by a third* in the year after teams adopt the tool. And even Gartner*, who makes a living selling the future, predicts four out of ten agentic projects will be cancelled by end of 2027. They even gave the hole a fancy name: comprehension debt. Code that runs, that nobody fully understands, written faster than any human can read it.

And here's the uncomfortable part, what neither camp will tell you: the numbers are true. The mess is real. I feel it in my bones every day. I said it before and I'll say it again. But don't believe the snake oil salesmen who swear everything's fine either.

The thing is, I think I've seen this movie before. With the same cast.

Picture yourself in October 1968. In Garmisch*, a village in the Bavarian Alps, NATO gathered about forty people who knew about computers to deal with a problem that had them scared white. Programs had grown so much and so fast that nobody understood them whole anymore. They crashed. They cost a fortune. (...Sound familiar? Feels like a flashback) They were delivered late and broken. From that meeting came a term that made a career: the software crisis. Not a passing crisis, mind you. A capital-C Crisis, the kind where "this thing can't be governed."

They got the symptoms right but missed the prognosis. Because nobody threw the computer out the window. The opposite happened: that disorder started manufacturing its own remedies, and they came out by the handful.

That same year, a quiet Dutchman named Dijkstra published a three-page letter tearing apart the *goto*, and with it structured programming. In '76, a guy named Michael Fagan* at IBM turned looking at someone else's code into a method with a name and a roadmap: formal inspection. And in '77, at Bell Labs, someone fed up with the C compiler letting any hack through wrote a little program to catch them before they bit. He called it lint*).

And what does that debt graph not show you? The usual: the tool that comes after the fire. Nobody retired the compiler; they surrounded it with tools until they tamed it. The linter, the analyzer, the test that runs by itself: all of that was born to fill the same gap, the one opened by writing faster than you can read. Because that's what comprehension debt is about, a mismatch. The machine runs and the one watching trails behind, panting. And a mismatch isn't cured by slowing down the runner. It's cured by arming the reader.

And here's what the doomsayers miss: we're going to give the reader the same engine we gave the writer. The same AI that pours out code in torrents is the one that's going to read it, review it, and audit it at the speed it's generated. It's just still early. Those tools are still green, half of them still need building, and that's exactly why the ugly numbers show up now. It's the same awkward moment as always, the gap between the problem and the toolbox that solves it.

So when someone shows you the technical debt curve with a funeral face, don't argue with salesman optimism. Agree with them on the symptoms, like at Garmisch. And then ask them about the tools we haven't finished building yet. Because the craft never solved its messes by throwing away what caused them. It solved them by building the next tool. What do you think?