If you tell a Product Manager that the code is “messy” or “ugly” or “needs a refactor,” they tune you out.


They can’t see the code. To them, the app works, the buttons click, and the customers are happy. They assume you just want to tidy up your workspace because you are a perfectionist.


But if you tell them, “We have taken out a high-interest loan that is taxing every new feature by 20%,” they listen.


The problem isn’t the code. The problem is the language.


Engineers who get the budget for refactoring don’t necessarily have cleaner codebases. They have better communication strategies. They stop talking about “cleanliness” and start talking about “liabilities.”


It is not a mess. It is a financial instrument.


Ward Cunningham gave us the term “technical debt” in 1992, but most teams only use half the metaphor. They treat debt like a mess to be cleaned up, like a teenager’s bedroom. That is not how debt works. Debt is financial. It has a Principal, it has Interest, and it compounds.

Think of it like a credit card.


The Principal is the shortcut itself. It is the hard-coded API endpoint or the copy-pasted validation logic. You saved 3 days of dev time by doing this. You swiped the card to buy speed.


The Interest is the extra time you pay every single time you work around that shortcut. Every new feature takes 20% longer. Every bug fix requires archaeological digging.


If you don’t pay down the principal, the interest compounds. That 20% tax becomes 50%. Eventually, you hit Technical Bankruptcy, where 100% of engineering time is spent keeping the lights on, and 0% goes to shipping new value. This progression is predictable. It isn’t dramatic. It is a slow suffocation. Teams don’t notice until they realize they can’t ship anything anymore.


How AI Changed the Economics

Paying down technical debt used to be purely manual labor. It was tedious, unglamorous work that nobody wanted to do. But AI has changed the math on this.


First, it acts as an Auditor. In the past we had to guess which code was causing the slowdowns. We would say things like “The billing controller feels messy.” That is an opinion.


Now, tools like CodeScene or Stepsize analyze git history to give you data. They can tell you that the Billing Controller was modified 45 times this month with high complexity. They can tell you it is costing you $10,000 a month in wasted dev time. Those numbers are defensible in planning meetings. Opinions are not.


Second, AI acts as the Janitor. AI struggles with writing complex new systems from scratch but it excels at translating old ones. It turns the work nobody wants to do into a 10-minute task. You can ask it to write a test suite for a legacy function or explain what a 5-year-old regex actually does.


The “Subprime” AI Trap

But you have to be careful. There is a new danger here.


Junior engineers using AI to generate thousands of lines of code they don’t understand are creating Subprime Debt. The code ships fast, so the velocity looks great. But nobody, including the AI, understands how it actually works. This isn’t just debt. It is a toxic asset. The knowledge to fix it doesn’t exist anywhere in the building. When that code breaks, you are in big trouble.


Strategic vs. Destructive Debt

This brings us to the difference between Junior and Senior engineers. Juniors aim for zero debt. They want perfect code. Seniors know that some debt is good.


You have Strategic Debt, which is like a Mortgage. You say, “We are hard-coding this integration to hit the Black Friday launch. It is not elegant, but we will refactor it in January.” This is smart business. You bought speed with a clear repayment plan.


Then you have Destructive Debt, which is like a Payday Loan. You say, “We didn’t write tests because we were in a hurry.” This is just negligence. You took out a loan with no plan to pay it back.


The Conversation That Gets Budget Approved

So how do you actually get the time to fix things?

When a Product Manager asks why a feature requires 5 story points instead of 3, do not explain that “the code is bad.” They cannot evaluate that claim.


Reframe it as a business decision using this script:


“To build this feature, we have two options.
Option A: We build it on the current foundation. It takes 3 days now but it increases the cost of all future features in this module by 10%.
Option B: We spend 2 extra days paying down debt while we build this. It takes 5 days total but future features will be faster and cheaper. The break-even point is just 3 features from now.
Which approach makes more business sense to you?”


This transforms refactoring from a “developer preference” into a “financial investment” with measurable ROI. PMs almost always choose Option B when they understand the compound costs.


The Senior Shift

Stop arguing about code cleanliness. Start managing your technical portfolio.

Go look at your backlog. Identify one “High Interest” liability that is taxing your team every week. In your next planning meeting do not ask to “refactor.”


Ask to “retire a high-interest liability.”


Language matters.