Technical debt

Definition
Technical debt is the accumulated cost of shortcuts left in a codebase, the quick hack or half-finished migration that makes every future change slower until it is paid down.

Why it matters

Debt that is taken on knowingly can be planned for. Debt that builds up unnoticed cannot. Each leftover shortcut makes the next change harder to predict, and a product can go from quick to fragile without anyone deciding it should.

Building with an AI coding agent raises the stakes. A model will produce a working feature in minutes, and just as quickly leave near-duplicate versions of the same logic side by side, or old code that nothing uses any more. The speed is real, and so is the clutter it can leave behind.

How to apply it

  • Say out loud when debt is being taken on, and write down what paying it back will look like.
  • Finish migrations. A database with old and new columns both live is debt that grows every day, because every query has to know which one to trust.
  • Ask the agent to extend an existing pattern rather than create a second one next to it.
  • Keep a visible list of known shortcuts, and review it on a fixed rhythm instead of only after something breaks.
  • Pay debt down in small, regular pieces through refactoring, not in one rewrite that stalls everything else.

What it is

The phrase borrows from finance. Taking a shortcut is like borrowing money: the feature ships sooner, but interest is charged afterwards, paid in extra time on every later change. Software developer Ward Cunningham came up with the comparison in the early 1990s. Debt is not always a mistake. Borrowing on purpose to hit a launch date, and then repaying, is a normal trade.

A small example from running a business: a quote tool is built in a day by copying the invoice tool and changing a few lines. It works. Six months later a tax rate changes, and the same fix has to be made in two places. Someone forgets one, and the quotes are wrong.

Common mistakes

  • Treating all debt as bad. A throwaway prototype does not need to be tidy.
  • Never paying it back. A shortcut with no repayment plan is not a loan, it is a leak.
Worked example

Suppose a twelve-person services firm adds a payment reminder feature in a day by copying the existing reminder schedule and changing the dates. It works. Six months later the firm changes the wording and the timing rules for overdue invoices, and the fix has to be made in two places. The team updates one copy and forgets the other, so some clients receive the old reminder. The repair takes an afternoon, and the lost trust costs far more.

The team asks Claude to find every place the reminder rules live and move them into one shared function before any new feature is added. Its rule from then on is simple: each shortcut goes on the backlog with a date, and no new feature ships until the duplicate is gone. A month later the backlog shows one item instead of four.

Tools in the example

Some links are affiliate links: we may earn a commission at no cost to you. It never decides a ranking. How we work with partners

  1. Article

    Refactoring

    How debt is paid down without changing behaviour.

  2. Article

    Stub

    A small, visible kind of debt if it is never finished.

  3. Article

    Test coverage

    The safety net that makes paying debt down less risky.

  4. Article

    Code review

    Where new debt is best caught.

Where it shows up

  • Writing copy that feels like conversation instead of marketing. How to sound like yourself.
    12 chapters