# What is technical debt, and do coding agents add to it?

Technical debt is the future cost of shortcuts in code or design, paid as slower changes and more bugs until someone cleans the shortcuts up.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define technical debt
-   Explain how debt builds up and is repaid
-   Identify how agent-written code changes the debt picture

## Related content

-   [What is code review?](https://specstory.com/learning/code-review/code-review)
-   [What is static code analysis?](https://specstory.com/learning/code-review/static-analysis)
-   [What is AI code review?](https://specstory.com/learning/code-review/ai-code-review)
-   [How to review a pull request written by a coding agent](https://specstory.com/learning/code-review/reviewing-agent-pull-requests)

## What is technical debt, and do coding agents add to it?

Technical debt is the extra work that later changes cost because of a shortcut taken earlier in code or design. It is also called tech debt. Each change that touches the shortcut takes extra time and risks bugs until someone removes it. [Coding agents](https://specstory.com/learning/ai-coding/coding-agent) can add to the debt quickly, because they generate code faster than people read it.

Ward Cunningham introduced the debt metaphor in an [OOPSLA 1992 experience report](https://c2.com/doc/oopsla92.html) about the WyCash portfolio management system. He wrote, "A little debt speeds development so long as it is paid back promptly with a rewrite." [Martin Fowler describes](https://martinfowler.com/bliki/TechnicalDebt.html) the extra effort of adding features as the interest on the debt. Cleaning up the code pays off the principal.

Code with a shortcut can work correctly, so debt is a cost, not a defect. [Code review](https://specstory.com/learning/code-review/code-review) is often the last point where a person can ask for a cleaner design before a shortcut merges.

## How does technical debt build up?

Debt from a deliberate shortcut usually builds up and is repaid in six steps:

1.  A team faces a deadline, e.g. a release date.
2.  A developer takes a shortcut, e.g. copying a function instead of changing the shared one.
3.  The change merges, and the software works.
4.  The next change that touches the shortcut takes longer, and that extra time is the interest.
5.  Other code builds on the shortcut, so removing it costs more with each change.
6.  A developer reworks the code, and later changes cost the normal amount again.

Diagram: How technical debt charges interest until it is repaid

The shortcut costs nothing until someone changes the code around it. The interest stops when someone pays off the principal.

Fowler's technical debt quadrant sorts debt into four types, by whether a team took it on purpose and whether the choice was prudent or reckless:

-   **Prudent and deliberate.** The team knows the design will not last and uses it to meet a date, with a plan to repay.
-   **Reckless and deliberate.** The team knows a better design and skips it, e.g. by shipping without tests.
-   **Prudent and inadvertent.** The team learns what the design should have been only after building it. Fowler writes that this kind is inevitable for teams that design well.
-   **Reckless and inadvertent.** The code is messy because its authors did not know good design practice.

## What is an example of technical debt?

Here is an illustrative example. Acme Co. sells furniture online. A developer at Acme picks up the request "Let customers edit their delivery address during checkout." The debt builds up over 2 months:

1.  The shared address check in `src/lib/address.js` serves 5 pages, so changing it safely would take 3 days. The holiday sale starts in 2 days.
2.  The developer copies the check into `src/checkout/address.js`, adds a phone number rule to the copy, and files a ticket to merge the two after the sale.
3.  The feature ships on time, and the ticket waits.
4.  Acme starts delivering to Canada. Another developer adds Canadian postal codes to `src/lib/address.js`, and its tests pass.
5.  Customers in Canada save an address on their account page, then see "Invalid postal code" at checkout.
6.  The fix takes a day, because the developer first has to find the second copy.

A search for the postal code rule shows the two copies, and only one accepts Canadian codes:

```text
$ grep -rn "POSTAL_CODE =" src
src/lib/address.js:4:const POSTAL_CODE = /^(\d{5}|[A-Z]\d[A-Z] ?\d[A-Z]\d)$/;
src/checkout/address.js:3:const POSTAL_CODE = /^\d{5}$/;
```

The shortcut was prudent and deliberate, and it let the feature ship before the sale. The interest was a day of repair and the orders that customers in Canada could not place. Merging the two checks into one pays the principal. This example is simplified. A real codebase would hold many such shortcuts, and many would have no ticket.

## What changes when a coding agent writes the code?

A coding agent can take the same shortcuts without leaving a ticket. An agent works from the files in its [context window](https://specstory.com/learning/ai-coding/context-engineering), so it can duplicate a helper that sits in a file it never read. Its summary often omits the copy, so nobody records the debt.

The debt grows when agents extend their own code. On [SlopCodeBench](https://arxiv.org/abs/2603.24755), where agents repeatedly extend their own code, no agent solved any problem end to end. The code usually became more bloated and tangled as the agents extended it. The authors report that written quality guidance made the first version less bloated and tangled but did not slow the decline.

In [vibe coding](https://specstory.com/learning/ai-coding/vibe-coding), nobody reads the code, so its debt is inadvertent in the quadrant's terms. Nobody chose it, and it stays hidden until someone has to change the code. Unread output that is bloated or duplicated is [AI slop](https://specstory.com/learning/verification/ai-slop), and later changes that touch it pay interest once it merges.

Reading each change before it merges, the step that separates [agentic coding](https://specstory.com/learning/ai-coding/agentic-coding-vs-vibe-coding) from vibe coding, catches copies while they are cheap to remove. Agents can also do the repayment, as a separate change that starts after tests pin the current behavior.

## How do teams pay down technical debt?

Teams pay down technical debt by changing the structure of code while keeping its behavior. These habits make that safer:

-   **Record each known shortcut.** A ticket that names the code and its cost lets the team plan the repayment.
-   **Pin the current behavior first.** A [characterization test](https://specstory.com/learning/test-quality/golden-file-testing) records what code does now, even when that is wrong, so a cleanup that changes it fails. Golden file testing is a common way to write one, and an [end-to-end test](https://specstory.com/learning/testing/end-to-end-testing) of each main workflow adds a check from the user's side.
-   **Refactor in small steps.** [Refactoring](https://specstory.com/learning/glossary#refactoring) changes the structure of code without changing its behavior, e.g. merging two copies of a check into one function.
-   **Rerun the checks after each step.** [Regression testing](https://specstory.com/learning/testing/regression-testing) reruns existing tests, so a cleanup that breaks tested behavior fails before it merges.
-   **Start where the code changes most.** [Fowler writes](https://martinfowler.com/bliki/TechnicalDebt.html) that "crufty but stable areas of code can be left alone," because debt charges interest only when someone changes the code.
-   **Measure the trend.** [Static analysis](https://specstory.com/learning/code-review/static-analysis) tools can report duplicated code and complexity per file, so a team can see whether those signs of debt grow.

## What are the limits of the debt metaphor?

The metaphor helps explain design work to people who do not read code, but it fits loosely:

-   **The interest rate is unknown.** The cost of a shortcut depends on how often later changes touch it, and nobody knows that in advance.
-   **Some debt never comes due.** [Wikipedia's article](https://en.wikipedia.org/wiki/Technical_debt) points out that if a system is retired before anyone modifies it, the shortcut was a real saving, e.g. in a prototype that is thrown away.
-   **The word covers too much.** Authors disagree on whether messy code counts. Fowler's quadrant counts it as reckless debt, while other writers keep the term for shortcuts a team chose.
-   **Similar code is not always debt.** Duplicated code is debt only when the copies must change together. Copies that follow different rules can change separately, and merging them would tie together code that should stay apart.
-   **Some debt comes due all at once.** A dependency that nobody upgrades often adds no work to later changes. When a security fix ships only in a much later version, the team must make the whole upgrade in one change.

## How is technical debt different from a bug?

A bug is behavior that differs from what the software should do, which a user or a test can observe. Technical debt is a property of the code's structure, and software can work correctly while it carries a lot of debt. They overlap. Debt makes bugs more likely, as the second address check at Acme did, and a quick fix for a bug can add debt. [Verification debt](https://specstory.com/learning/verification/verification-debt) is a different gap, code whose behavior nobody has checked by running or testing it.

## FAQs

### Is vibe coding creating a hidden technical debt crisis?

Vibe coding can create technical debt that nobody chose, because nobody reads the code it produces. For a prototype that is thrown away, that debt never comes due. For an app that developers keep changing, each change to that code pays interest until someone reads and cleans it up.

### Who coined the term technical debt?

Ward Cunningham coined the technical debt metaphor in an experience report for the OOPSLA conference, about the WyCash portfolio management system. He used the idea to explain why code shipped early should be rewritten promptly, before the extra cost of working around it grows.

### How do you recover a codebase you no longer trust?

To recover a codebase you no longer trust, first record what it does now with characterization tests and end-to-end tests of its main workflows. Then refactor in small steps, starting where the code changes most, and rerun the tests after each step so a cleanup that changes recorded behavior fails.

### Is all duplicated code debt?

Duplicated code is debt only when the copies must change together, e.g. the two address checks at Acme, which both needed the Canadian postal code rule. Two pieces of code that look alike but follow different rules can change separately, and merging them would tie together code that should stay apart.

---

Source: [What is technical debt? | AI technical debt | SpecStory](https://specstory.com/learning/code-review/technical-debt)