There's a question that comes up often in teams and meetings: what exactly is technical debt? People mention it a lot, almost always as a complaint, but rarely does anyone stop to explain it.
One way to explain it is through a mortgage.
And this week two pieces of news showed why that mortgage can grow much faster when artificial intelligence is involved. Not so much because AI writes bad code, but because it writes a lot of it, very fast, and someone has to pay the installments.
Technical debt is a mortgage
When you take out a mortgage, you get something today that you couldn't pay for in cash. In exchange, you commit to paying installments for years, with interest.
Software works in a very similar way. You take a shortcut to hit a deadline: you duplicate a function instead of generalizing it, you hard-code a business rule in an odd place, you postpone a test. You get there sooner. But every future change in that area costs a bit more, because first you have to understand, work around or fix what was left half done.
That extra cost is the interest.
Here's something important: debt isn't bad in itself. Just like a mortgage, sometimes borrowing is the right call. Launching earlier, validating an idea, getting to a demo that closes a contract. The problem starts when you borrow without noticing, when nobody knows how much is owed or at what rate.
And that's where AI changes the scale.
Generating code got cheap
In an article published this week, Anthropic described how it redesigned its source control system. According to its own figures, it averaged around 2,500 code changes merged per day in May 2026 and was merging over 30,000 by September.
At that volume, source control became their biggest development bottleneck. They built their own system, Scion, and migrated their monorepo in five months. Anthropic says its case is very unusual: it uses Claude to write code far more than almost any other company. Even so, it expects similar pressures could appear at other organizations within six to twelve months.
There's a detail in the same article that I find even more interesting than the numbers. They explain that very often the engineers' role was to tell the model "no," because the agent would sometimes violate core system constraints or over-engineer parts of the system to handle hypothetical concerns.
I raised this in Too much code: who reviews all of it?: the bottleneck didn't disappear, it moved. Writing stopped being the expensive part. Understanding, reviewing and sustaining did not.
Six proposals, two approved
The second case comes from Google. In an article published alongside Gemini 4 Argon, its team described a concrete experiment: they asked the model to improve the performance of ADK, its Python agent framework. According to Google, the repository had roughly 205,000 lines of code and nearly 17,000 unit tests.
The agent worked alone for 11 hours, overnight. By morning it had proposed six optimizations across 32 files.
In review, the team kept two and rejected four:
- A cache that improved a synthetic benchmark but could return stale data across sessions.
- A check that read a private attribute of another library and could break silently on a minor upgrade.
- A rewrite that made a core part of the code harder to read without improving real latency.
- An index that added complexity and only helped synthetic tests.
Look at that list through the lens of technical debt. An improvement can pass the available tests and still introduce bugs or future costs. The cache already risked returning incorrect data; other proposals added fragile dependencies or complexity without a useful benefit. Review caught those problems before the changes were integrated.
Google also reports that another proposal, lazy module loading, passed all 16,892 public tests but failed 25 internal test targets. It needed adjustment before being merged. Passing tests were one part of the evidence, and review also needed to examine what they had missed.
Google's own team sums it up in a phrase that stuck with me: the agent explores, the maintainer subtracts.
The onboarding guide detail
There's another part of the case worth telling. In a first round they gave the model the goal without any instructions about how the team works. The agent found real improvements, but it also accidentally changed a public schema and ran only a fraction of the tests.
For the second round they put the maintainers' guidelines into the repository, like an onboarding guide for a new engineer. They also enabled /goal mode, which preserves the objective during a long run, and requested an unmerged pull request with before-and-after measurements. In that round the agent read the rules before editing code, worked for 11 hours, and ran all 16,892 unit tests. Since several conditions changed, the case does not establish that instructions alone caused the improvement.
I really like that image, because it takes the magic out of it. An agent is a lot like a very capable person who just joined: they can do many things, but they don't know your agreements, your history or what must not be touched. If you don't explain it, they'll sign loans in your name without knowing it.
How I would approach it in a large company
Imagine a large company that depends on an old system with incomplete documentation and costly changes. Before asking an agent to add more code, it would help to understand which parts are hard to maintain and why.
In that context, I would suggest using AI in this order.
First, to understand. Ask it to walk through a module, explain what it does, spot dependencies and write the documentation that doesn't exist today.
Then, to verify. Have it propose tests for the current behavior before changing anything, so you know what breaks if you touch something.
Only then, to build. And with a well-crafted definition of done, so it doesn't do more than needed. An agent without clear limits tends to improve things nobody asked for, and every unrequested improvement is a bit more surface to maintain.
I would also use AI to understand the commitments we are taking on when we change the system.
Questions I'd ask before accepting a change
If your team already works with agents, here are a few simple questions for every big change:
- Can someone on the team explain this change without the code in front of them?
- Does it solve a real problem or improve a benchmark?
- Does it rely on internal details of another library or system?
- Does it add state, caching or complexity we'll have to look after?
- If it fails tomorrow, who owns it?
None of these questions is new. They're plain software engineering. What's new is how many times a day they need to be asked.
And one more, maybe the most uncomfortable: are we measuring how much code comes in, or how much code we understand?
Closing
AI didn't invent technical debt. What it does is make borrowing much cheaper. A loan that used to take days of work now gets signed in minutes, and it arrives tidy, with reasonable names and green tests.
That's why I think the role gaining the most value isn't the one that generates the most, but the one that knows how to subtract. The person who looks at six proposals and has the judgment to keep two.
If your team generates twice as much code as a year ago, does it also understand twice as much?
References
- Anthropic, Redesigning source control at Anthropic (October 13, 2026).
- Google Developers Blog, Optimizing a 200,000-line Python codebase overnight with Gemini 4 Argon (October 13, 2026).
I keep these conversations going on my YouTube channel. Take care.