The numbers are in, and the doomsayers are throwing a party.

Two years of the same refrain: this is going to be hell to maintain. Hunch and zero data. Well, now we've got the data, and it doesn't look good. The share of AI-written code keeps climbing; the machine already bangs out 41% of new code*. An analysis of more than eight million PRs* found serious bottlenecks after adoption, while another study* clocked 1.7 times more issues in PRs written with AI. Technical debt climbs by a third* in the year after teams take up the tool. And even Gartner*, which makes its living selling the future, forecasts four in ten agent projects scrapped by the end of 2027. They even gave the hole a pretty name: comprehension debt. Code that runs, that nobody fully understands, written faster than any living soul can read it.

And here's the uncomfortable bit, the one neither camp will tell you: the numbers are true. The mess is real. I feel it in my own flesh every day. I said it in its day and I'll say it again. But don't go believing the snake-oil salesmen who swear everything's fine either.

The thing is, I reckon I've seen this film before. Same cast.

Picture yourself in October 1968. In Garmisch, a village in the Bavarian Alps, NATO gathered some forty people who knew computers to wrestle with a problem that had them white with worry. Programs had grown so much, so fast, that nobody understood them whole anymore. They crashed. They cost a fortune. They shipped late and badly. (Sound familiar? Feels like a flashback.) Out of that meeting came a term that went places: the software crisis. Not a passing crisis, mind. A crisis with capital letters, the "there's no governing this" kind.

They nailed the symptoms and blew the prognosis. Because nobody threw the computer out the window. The opposite happened: that mess set about making its own remedies, and they came out by the fistful.

That same year, a quiet Dutchman named Dijkstra published a three-page letter tearing the *goto* to pieces, and with it, structured programming, which was about as close to sweeping the house as this trade had ever seen. In '76, one Michael Fagan*, at IBM, turned looking at someone else's code into a method with a name and a roadmap: the formal inspection. And in '77, at Bell Labs, someone fed up with the C compiler letting any old botch slip through wrote a little program to catch them before they bit. He called it lint*), the fluff you pick off a jumper. The mess wasn't buried. It got combed out.

And what doesn't that debt chart show you? The usual: the tool that comes along behind the fire. Nobody retired the compiler; they ringed it with tools until they tamed it. The linter, the analyzer, the test that fires on its own, the colleague who reviews your change before it lands: all of it born to plug the same gap, the one that opens when you write faster than you read. Because that's what comprehension debt is, a lag. The machine runs and the one watching trails behind, panting. And a lag isn't cured by slowing 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 as the writer. The same AI that spews code in torrents is the one that'll read it, review it and audit it at the speed it's generated. It's just early yet. Those tools are still green, half of them still to be built, and that's exactly why the ugly numbers show up right now. It's the same awkward stretch as always, the one 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 back with salesman's optimism. Grant them the symptoms, like at Garmisch. And then ask them about the tools we haven't finished building yet. Because the trade never solved its messes by throwing out whatever caused them. It solved them by banging out the next tool. What do you reckon?