Code Is a Liability

Tech debt in the AI age

---

Good morning! This is the Canadian AI Newsletter. Tuesdays are the weekly rundown; today is an essay.

Was this forwarded to you? Subscribe below.

I am Raif Barbaros, Partner at Mistral Venture Partners. Views are my own.

---

All my career as a CTO, I put every line of code we shipped in the liabilities column. The asset is what the software does for users and for revenue. The code is the cost of carrying that asset.

My working definition of tech debt: any dev work on existing code that doesn’t add a new feature. That work maintains three things, and all three degrade on their own. Scalability degrades because volume grows past what the code was built for, or the code quietly stops handling the volume it used to. Stability degrades because code gets buggier as everything around it changes. Maintainability degrades because the people who understood the code leave, or they didn’t understand it fully to begin with :)

Code is the rare liability that grows while you leave it alone. Nobody touches a module for a year, and in that year a dependency picks up a security hole, traffic doubles, and the engineer who wrote it takes another job. The code sat still, and the debt grew anyway.

Ward Cunningham coined the debt metaphor in 1992. His original point was about understanding: you ship code before you fully understand the problem, and the gap between the code and your understanding is a loan. A small loan is fine, even smart, as long as you repay it by reworking the code once you know better. The key word is knowingly. You chose to borrow.

Code got cheap

Google says 75 percent of its new code is AI-generated and approved by engineers. The trajectory is the striking part: 25 percent in late 2024, 50 percent by last fall, three-quarters today. Snap reached 65 percent this spring, and Meta has been targeting similar levels by the middle of this year.

My model never depended on code being expensive. But expensive code was a natural brake on how fast the liability could grow. Every line was written by a human who at least momentarily understood it, and headcount capped the volume. AI removed the brake.

More code means more debt

Start by giving AI coding the benefit of every doubt. Assume more code means more features, and assume the quality per line is unchanged. Tech debt still grows massively, because maintenance load scales with the amount of code you carry. A dependency vulnerability hits a five-million-line codebase harder than a five-hundred-thousand-line one. Ten times the code, ten times the debt.

The quality data

Now drop the assumption, because quality per line does not look constant.

GitClear, a code analytics firm, has tracked 623 million code changes from 2023 through this year. Refactored code has fallen from 21 percent of changed lines in 2022, the last year before AI, to under 4 percent so far in 2026, while copy-pasted code has climbed to nearly 16 percent. Before AI, developers refactored about twice as often as they pasted. Today they paste five times as often as they refactor. Block duplication is up 81 percent since 2023, the highest level GitClear has recorded, and the share of changes that touch code more than a year old has fallen 74 percent. Old code is increasingly left frozen. Duplication matters because it creates debt without creating features. A duplicated block is a second copy of something you already had, and now the same bug gets fixed twice.

Google’s own DORA research, a survey of about 5,000 software professionals, found that AI adoption now correlates with higher delivery throughput. Teams genuinely ship more, and that finding deserves to be stated plainly. The same research found AI adoption still correlates with lower delivery stability, for the second year running. Their conclusion is that AI amplifies whatever discipline a team already has.

Veracode tested over 100 models and found that 45 percent of AI-generated code samples contained a known security vulnerability, a rate that has stayed roughly flat as models get bigger.

One caveat on all of this. GitClear sells code analytics, Veracode sells security scanning, and every vendor in this fight has numbers that favour its product. DORA is the interesting exception, because Google sells the AI and keeps publishing the stability finding anyway.

Then there is the witness I find most convincing, because he wants the opposite to be true. DHH, the creator of Ruby on Rails, spent five hours with Lex Fridman two weeks ago describing himself as fully AI-pilled. He runs 16 agent threads and shipped his latest release without handwriting any code. In the same conversation he described what happened when 37signals let designers vibe code on Basecamp, a large production codebase. Each pull request looked justifiable on its own. Taken together, he says, they “destroyed the architecture of the system,” and the team had to clean it up manually, by human hand. He also described watching agent code compound in his own repos: the first PR is mediocre, and five PRs stacked on top of it get bad.

The paydown side didn’t scale

Debt only matters relative to your ability to pay it down. The thing that retires tech debt is senior engineers understanding and reworking the system, and that input is roughly fixed.

It may be shrinking. Faros AI’s telemetry across 22,000 developers found 31 percent more pull requests merged with no human review at all, bugs per developer up 54 percent, and incidents per PR up 243 percent, year over year. Addy Osmani, an engineering lead at Google, points out the inversion underneath those numbers: a senior engineer used to review faster than a junior could write, and a junior with AI now generates code faster than a senior can audit it.

Osmani has a name for what accumulates when this goes on long enough: comprehension debt, the gap between the code your team has shipped and the code your team understands. It is Cunningham’s original gap in a harsher form. The gap used to open slowly, as your understanding of the problem improved past the code. Now it exists at the moment the code is written, because nobody read it.

Martin Fowler’s tech debt quadrant sorts debt by whether it was taken on deliberately. Cunningham’s loan was deliberate. Unreviewed AI code is inadvertent debt by construction. Nobody chose the tradeoff, because nobody read the code closely enough to know a tradeoff was being made. We are originating far more debt with far less underwriting.

One lab result backs up the intuition that understanding stays the scarce input. An ETH Zurich study hid the generated code entirely from participants and had them build small apps through prompting alone. Computer science knowledge was still the strongest predictor of who got good results. You can hide the code from the human. You can’t remove the human’s mental model from the outcome.

“We’ll just use AI to pay it down”

This is the natural rebuttal, and the honest answer starts with a concession. AI genuinely works for mechanical maintenance. Amazon says its Q assistant cut Java upgrades from about 50 developer-days to hours, saving a claimed 4,500 developer-years. Morgan Stanley built an internal tool called DevGen.AI that reviewed nine million lines of legacy code and saved a claimed 280,000 hours. Both numbers come from the vendors themselves, but the pattern is credible. Version upgrades, migrations, and translation are well-specified chores that a machine can check. All of that is real.

The broader claim, that AI will take care of tech debt overall, runs into three problems.

The first is revealed preference. If AI made cleanup cheap, cleanup should be booming. GitClear measures the opposite, and the collapse in refactoring happened precisely during the AI adoption wave. The tools made adding code effortless and made consolidating it only somewhat easier, so teams took the effortless path. AI paydown is available, and it isn’t happening.

The second is that comprehension debt can’t be paid down by a tool, because of what the debt is. The gap sits between the system and your team’s heads, so the paydown has to happen in the heads. AI can write excellent explanations, and someone still has to learn them. Even Morgan Stanley, running the flagship AI paydown project in the industry, had DevGen.AI produce plain-English specs and kept humans doing the rewriting, so the understanding would end up back in its engineers.

The third is that AI reviewing AI has a bootstrap problem. Investors have put roughly a quarter of a billion dollars into startups that review AI code with AI, and those tools do catch mechanical problems. But a code review’s real function was for a human to accept responsibility for a liability entering the books. When an AI reviewer approves an AI author, no human ever held the loan. The comprehension gap grows at the moment of approval, at machine speed, with a green checkmark.

The extreme version of the rebuttal says to stop maintaining code altogether: keep the spec and the tests, throw the code away, regenerate it. That works for throwaway software. For durable systems, the problem is that specs and tests are always incomplete. A spec pins down only the behaviour you thought to write down, and a production system’s users depend on far more than that: error handling, edge cases, timing, quirks nobody ever documented. Regeneration re-decides everything the spec left out. You trade code you don’t understand for new code you don’t understand.

AI pays down the debt that was cheap to pay down anyway. The debt that compounds, the kind that lives in people’s heads, grows faster under AI while the dashboards look healthier.

What I’m watching

Code is still a liability. The part of the debt that matters most has moved from the code to the heads of the people running it.

Two numbers will tell us how this plays out. The first is the share of engineering hours going to non-feature work. Stripe measured it at roughly half a developer’s week back in 2018, before any of this started. My bet is that this share rises in AI-heavy codebases even as feature output also rises. The second is lines of code per feature: how much code you end up carrying for each feature you ship. If AI coding is working the way the optimists say, that ratio holds steady. The early duplication data says it is not holding.

Near the end of that Fridman interview, DHH said something that stuck with me. He spent 25 years sweating every line, and the economic payoff of beautiful code, he now admits, was premised on humans doing the future modifications. He calls it an open question how much that premise still holds.

That is the real question the industry is deciding right now, mostly without saying it out loud: are we willing to run production systems no human understands? For some software, the answer can be yes. Some UI, one-off internal tools, anything you’d rebuild rather than repair. For the critical parts of an architecture, I don’t think it holds. If lumber and carpenters were suddenly free and abundant, you would not get strong, sustainable homes and beautiful, livable cities. You would get a lot of construction.

Thank you for reading! Subscribe, and please share any feedback 🙏🏽

— Raif