Tech Debt in the Age of AI: It’s Real

4 minutes ago

6 min read

Atlas kneeling under the weight of the words TECH DEBT, illustrating how tech debt builds up in the age of AI, from Customer Success by Design.

He sidled up next to me at the PyTorch Conference happy hour.

He’s a data science PhD building go-to-market (GTM) agents for a well-known social media company.

The conversation was fun, fluid, and informative. Then we nerded out on the sexiest topic of all: tech debt.

I love chatting with engineers and product leaders about tech debt because years of having to swim through the sludge of it while trying to deliver customer value have left me with more than a few battle scars and opinions on the topic.

AI is moving so fast that in September, the CEOs of Anthropic and OpenAI publicly called for the industry to pump the brakes on frontier model development.

Meanwhile, confidence in AI remains sky high, and “faster” feels like the only mantra.

My new Dr. amigo and I spent two hours going back and forth on what we think this will all mean from a tech debt perspective.

There are some lessons from history that shed light on this. So let’s dig in.

Under Pressure

Intuition and experience give me confidence that generative AI will NOT solve all our problems, especially when it comes to technical debt.

The data agrees.

Back in 2015, Google researchers warned that machine learning systems can be quick to build but expensive to maintain. They carry the maintenance challenges of regular software, plus risks unique to ML. Even more alarming, a 2026 study in ACM Transactions on Software Engineering and Methodology found that the median share of code comments in which developers acknowledged technical debt was twice as high in ML projects as in comparable non-ML projects.

Eek! Twice the flagged debt is no bueno.

None of this is new, either. In 1980, computer scientist Meir Lehman published his laws of software evolution in Proceedings of the IEEE. One of Lehman’s laws describes how software tends to grow more complex as it evolves unless work is done to control that complexity. AI doesn’t repeal that pressure. If anything, shipping changes faster makes deliberate maintenance more important.

And that’s on top of a pile that was already big. In a 2020 McKinsey survey, CIOs at large financial services and tech companies estimated their tech debt at 20% to 40% of their technology estate’s value before depreciation. That should set off everyone’s spidey sense that something not pretty is headed their way.

Won’t Get Fooled Again

It’s tempting to imagine AI systems that learn from every mistake, course-correct on their own, and keep improving with little human intervention. No humans needed here. Just AI awesomeness.

Well, it doesn’t work that way.

Same goes for the dream of AI spinning up a new agent for every problem it runs into.

The underlying model doesn’t change just because you use it. Its training stays fixed until its developers update or retrain it. The product around it may adapt through saved memory, chat history, or feedback loops, but changing the model itself still takes people. So you’re back to human intervention and management, not everlasting self-sufficiency.

AI coding tools can fix some technical debt, but the results depend on the task and benchmark. A 2023 study found the best approach tested fixed about 2.3% of developer-flagged debt on the first attempt and 8.1% after ten. A 2026 study used a larger dataset and different scoring methods, so its results aren’t an apples-to-apples comparison. My advice: treat benchmark results as a moving target, and measure what the tools actually fix in your own environment.

Finally, remember that every agent, even one built to resolve tech debt, is its own ML system. It needs maintenance, and as we’ve seen, it will incur its own tech debt.

So no, the robots aren’t coming to pay off our debt. Not yet, anyway. It keeps building, and it still takes people to manage it.

My Way

My Customer Success paranoia, and the scar tissue from watching tech debt hit NRR, NPS, and my own sanity, led me to create a 1/3 rule.

I was dealing with enough customer pain that I believed committing one-third of our resources to tech-debt-driven issues would net a greater return than letting them linger while the customers affected by them died on the vine as casualties of new feature work.

The research suggests my math and approach weren’t far off. A peer-reviewed study out of Chalmers University found developers reported losing an average of 23% of their working time to tech debt. Meanwhile, McKinsey found most CIOs put less than 20% of their tech budget toward paying it down. A third may still look like an alarming chunk to a growth-minded CEO and an efficiency-driven CFO. Against those numbers, it looks less like paranoia and more like catching up.

Fortunately, experience and data point to a playbook anyone can build from.

Taking Care of Business

We’re in new territory, with constant pivots and faster production than ever. Even so, the research and my own experience line up on how to approach tech debt.

Make it a business issue with an owner. That’s tough when Product, Engineering, and Sales all vie for influence. But without an owner, the problem flails, and in my experience it inevitably falls to the retention team, who then have to scream loud enough (backed by renewal data) to get anything to change. McKinsey recommends tracing ownership of each system’s debt to the P&L it serves. What’s worked best for me is a dedicated product owner for tech debt.
Don’t aim for zero. Perfection is always pursued and never truly attained. A zero-tech-debt goal is grand but unrealistic, and McKinsey notes it would mean spending everything on cleanup instead of building. Work together toward the level that makes the most impact for the business.
Close the gap between business and engineering. Finger-pointing helps no one, and trade-offs get made constantly. A small interview study of IBM architects found the call to take on tech debt was often made by business stakeholders, not engineers. Own that, and take the time to recall why decisions were made so the whole team learns from them.
Set rules for AI-assisted coding. AI governance isn’t a buzzword. It’s a must, especially in healthcare and other regulated industries, and it requires clear guidelines for when and how teams use AI-assisted coding. Make sure everyone knows where the risk lives. MIT Sloan Management Review has warned that AI-generated code can create costly problems when layered onto legacy systems, especially in the hands of inexperienced developers.
Measure what it costs in time. It’s the easiest base metric to track. Developer time is expensive, so use it to decide which debt to tackle first. Pair it with customer sentiment and your growth and revenue metrics, and the answers get easier to find.
Don’t count on recovery to save the relationship. This is the one that keeps me up at night. A great apology may calm a customer down, but don’t expect it to win back the renewal. Don’t agree? A meta-analysis in the Journal of Service Research found that good service recovery lifted satisfaction but had no significant effect on whether customers bought again or recommended the company. That’s one more reason to spend on prevention.

The Beat Goes On

My new pal and I didn’t “solve” the tech debt question over our beers.

Though we were pretty confident we’d made sufficient headway after another round. 😉

What we did agree on, and what the research supports, is that AI isn’t a whiz-bang fix-all, and that includes tech debt.

Maybe we’ll get there someday. For now, though, we need to be careful not to confuse faster code production with less technical debt.

Discipline and teamwork are what keep the most critical debt from landing on your customers.

What’s your tech debt horror story? Drop it in the comments.

If tech debt is showing up in renewals, customer sentiment, or delivery capacity, I help SaaS and healthcare teams connect that customer impact to the work worth fixing first, including the debt an AI rollout may be adding. Let’s compare notes.

Schedule a Conversation →

Cheers,

Adam Peddicord

Customer Success by Design

Sources