Key points

• Technical debt is the future work a software system owes you, created when a team ships something faster or simpler than the problem deserves.

• Debt has a principal, the work needed to bring the stack up to standard, and interest, the tax every new project pays to work around it.

• CIOs told McKinsey that tech debt equals 20 to 40% of their entire technology estate, and that it diverts 10 to 20% of the budget meant for new products.

• GitClear found duplicated code blocks up 81% since 2023 while refactoring fell to 3.8% of changed lines, so AI-assisted teams now accumulate debt faster than they clear it.

• Zero debt was never the goal: price what you owe, then repay only the parts blocking the next four quarters of roadmap.

What is technical debt?

Technical debt is the accumulated cost of the work a software system still needs, created when a team ships something faster or simpler than the problem actually deserves. Like financial debt, it buys speed now in exchange for repayments later. Those repayments arrive as slower delivery, higher maintenance effort, more defects, and features that take three sprints instead of one.

The debt itself is invisible on any balance sheet. Its effects are not. When a team tells you a small change will take a month, you're usually looking at interest payments.

Where does the term technical debt come from?

Ward Cunningham coined the term in 1992 while working on WyCash, a financial software product. He needed to explain to his boss why the team kept rewriting code that already worked.

His framing: shipping first-time code means shipping with an incomplete understanding of the problem. Every time the system's model of the domain disagrees with the team's current understanding, work slows down. That slowdown is the interest. You can carry it for a while, or you can pay down the principal by refactoring.

It's worth being precise about what Cunningham meant, because the term has drifted. He wasn't describing sloppy work. He was describing the distance between what a team now knows and what the code still assumes. That gap opens up on well-built systems too.

Is technical debt the same as bad code?

Technical debt and bad code get used interchangeably, and they shouldn't be.

Bad code is a quality failure. Technical debt is a timing decision. A clean, well-tested service built on assumptions that stopped being true two years ago carries real debt. Meanwhile a rushed, ugly script that runs once a quarter and nobody depends on might carry almost none.

Martin Fowler's technical debt quadrant is the most useful way we've found to separate them. It asks two questions: was the debt taken on deliberately or by accident, and was that choice prudent or reckless? That gives four positions, and only one of them is a plan:

• Deliberate and prudent. "We ship without the abstraction to hit the launch, and we fix it in Q3." A real trade, made with open eyes and a repayment date.

• Deliberate and reckless. "We don't have time for design." No trade, just a shortcut nobody wrote down.

• Inadvertent and prudent. "Now that we understand the domain, we'd model this differently." The unavoidable kind, and the one good teams generate constantly.

• Inadvertent and reckless. "What's a layered architecture?" A capability gap wearing a debt costume.

Only deliberate and prudent debt is a strategy. Inadvertent and prudent debt is unavoidable, and as Fowler points out, it's the kind excellent teams accrue simply by learning the domain while they build it. The two reckless positions signal something else: planning, standards, or capability.

Which parts of a system carry technical debt?

Technical debt shows up in more places than the codebase. When we assess a legacy system before a modernization engagement, these are the categories we look at:

Code debt. Duplication, dead code, unclear naming, functions doing five things. The most visible type, and usually the cheapest to fix.

Architecture debt. Wrong boundaries, tangled dependencies, a monolith where the business now needs three independently deployable services. The most expensive type to repay, and the one practitioners most often name as the biggest source of debt: in a survey of 1,831 software practitioners, architectural decisions came out as the leading cause.

Infrastructure debt. Manual deployments, unpatched runtimes, servers nobody wants to touch, environments that don't match production.

Test debt. Missing coverage on critical paths, brittle suites people rerun until they pass, no way to verify a release without a week of manual checks. Test debt is what turns every other kind of debt into something too risky to repay.

Documentation and knowledge debt. Systems only one person understands. This one compounds quietly and then arrives all at once, on the day that person resigns.

Data debt. Inconsistent models across services, no single source of truth, reporting built on assumptions that stopped holding. Increasingly the blocker for anything AI-related, because model quality follows data quality.

Dependency and security debt. Frameworks two major versions behind, libraries no longer maintained, upgrade paths that got harder every quarter you postponed them.

What does technical debt look like in practice?

Abstract definitions don't help much when you're making the case to a board. Three patterns come up again and again.

1. The hardcoded business rule

A subscription platform launched with pricing logic written directly into the checkout service. It worked, and it shipped six weeks early.

The interest: every pricing experiment now needs an engineer, a release, and a regression test. Marketing waits two weeks for a change that should take an afternoon. Three years in, the rules have been copied into four other places, and nobody's certain they agree.

The repayment: extract pricing into a configurable service. Weeks of work, and it turns a two-week cycle into a same-day one.

2. The framework that stopped being supported

An internal operations tool built on a framework that reached end of life. The app runs fine, so nobody prioritized the upgrade.

The interest: no security patches. New hires need a week to get productive in a stack they've never seen. Each year of delay makes the migration path longer, because the version gap keeps widening.

The repayment: either migrate now at a known cost, or accept a growing security exposure and an eventual forced rewrite at an unknown one. This is the clearest case of debt where waiting is the expensive option.

3. The database nobody dares change

A schema designed for a single product, now serving four. Column names mean different things depending on which service wrote the row. Reporting requires three joins and a caveat.

The interest: every new feature negotiates with the schema first. Analytics answers arrive with disclaimers. The AI roadmap stalls, because there's no reliable training data underneath it.

The repayment: incremental. Define the target model, route new writes through it, migrate consumers one at a time. Slow, unglamorous, and the highest-value work available to that team.

Why is technical debt accumulating faster in 2026?

AI-assisted development changed the arithmetic. Teams ship more code, faster, than they did three years ago. That part is real, and as a Digital Product Studio working across client codebases, we see it in our own work.

What's also real is the maintainability cost. GitClear's analysis of 623 million code changes found duplicated code blocks up 81% since 2023, error-masking constructs up 47%, and cross-file function calls, a signal of reuse, down 35%. Refactoring fell from 21% of changed lines in 2022 to 3.8% year to date in 2026. Developers are now roughly five times more likely to duplicate code than to consolidate it.

The pattern isn't that AI writes bad code. It's that the default AI workflow rewards the closed ticket and quietly defers the consolidation. Volume goes up, structure goes down, and the bill arrives in year three.

Which makes debt discipline more valuable than it used to be, not less. If a team can generate a quarter's worth of code in a week, the constraint moves from writing to owning.

How do you measure what technical debt is costing you?

Pricing technical debt doesn't need a maturity model. It needs four numbers most teams can pull this week.

Lead time for a small change. If a one-line fix takes days to reach production, the delay is interest, and it's measurable.

Share of engineering capacity going to unplanned work. Track it for a month. McKinsey put debt-related diversion at 10 to 20% of new-product budget, and in later research, 30% of CIOs said more than 20% of that budget went to debt work. A former CIO at a major cloud provider described going from 75% of engineer time paying the debt tax down to 25%.

Change failure rate and time to restore. Debt shows up as fragility long before anyone names it.

Concentration risk. How many files can only be safely changed by one person? That's a number, and it's usually worse than expected.

Put those in front of the business as a quarterly cost, not an engineering complaint. Debt gets funded when it has a price tag.

When should you not pay down technical debt?

Not all technical debt is worth repaying. Code in a product line you're sunsetting can stay exactly as it is. A service that hasn't changed in two years and isn't blocking anything is cheap to carry. Rewriting a system that works, purely because the stack isn't fashionable, is how modernization programs lose credibility.

McKinsey's framing is useful here: zero debt would mean spending everything on remediation and nothing on differentiation. The threshold worth watching is when a division's debt passes roughly half its technology asset value. Past that point, cost and risk start outweighing what the system still gives you.

Prioritize where debt intersects roadmap. If it sits on the path to something the business needs in the next four quarters, repay it. If it doesn't, document it and move on.

Final thoughts

The teams that handle technical debt well treat it as a decision, not a defect. They talk about it the way a finance team talks about a credit line: something you take on knowingly, size honestly, and repay on a schedule you chose rather than one an outage chose for you.

That shift is mostly cultural, and it starts with visibility. You can't govern what nobody's written down.

Legacy systems rarely fail dramatically. They just make every good idea slightly more expensive until the roadmap quietly shrinks to what the architecture allows. Naming the debt, pricing it, and repaying the parts that block the next two years of the business is how that trend reverses.

Frequently asked questions

What is technical debt in simple terms?
It's work your software still owes. When a team ships something faster or simpler than the problem requires, the difference doesn't disappear. It gets paid back later as slower delivery, more bugs, and higher maintenance effort.

What does technical debt mean in Agile?
In Agile teams, technical debt usually refers to work deferred to protect a sprint commitment: skipped tests, missing refactors, temporary workarounds. Healthy teams track these items in the backlog and allocate a fixed share of each sprint to repaying them rather than letting them accumulate invisibly.

Is technical debt always bad?
No. Deliberate debt with a repayment plan is a legitimate trade, and shipping early to validate a market is often the right call. The problem is debt nobody recorded, priced, or scheduled. Zero debt isn't the goal either, since reaching it would mean spending everything on remediation and nothing on new value.

What are the main types of technical debt?
Code, architecture, infrastructure, test, documentation and knowledge, data, and dependency or security debt. Architecture debt is usually the most expensive to repay, and test debt is often the one blocking everything else, because without reliable tests it's too risky to change anything.

How do you measure technical debt?
Combine code-level signals like duplication, complexity, and coverage with delivery metrics: lead time for a small change, change failure rate, time to restore, and the share of capacity going to unplanned work. Static analysis tools can estimate remediation effort, but the delivery numbers are what make the cost legible to the business.

Does AI-generated code increase technical debt?
It can. Analysis of 623 million code changes found duplicated code blocks up 81% since 2023 and refactoring activity down sharply over the same period, as AI-assisted authorship scaled. The throughput gains are real, but so is the maintainability cost when teams don't budget for consolidation and review.

Who is responsible for technical debt?
Engineering identifies it, but ownership sits with whoever owns the product and the budget. Debt only gets repaid when it's treated as a business cost with a named owner, not as an engineering preference competing against features.