What is technical debt — and why it piles up faster with AI

"Technical debt" has a bad reputation: it sounds like "somebody messed up." Here's the surprise: debt isn't a mess-up. It's a deliberate trade, like a bank loan. You cut a corner so the feature ships today instead of next week — and agree to pay later. The problem isn't taking on debt. The problem is forgetting about it while the interest keeps ticking.

Why it's called "debt" in the first place

The metaphor comes from programmer Ward Cunningham, and it's painfully accurate. A loan works like this: take money now — return more later. Same with code:

• You borrow — hardcode a value, copy-paste a chunk instead of writing a shared function, skip error handling. The feature ships by evening. That's a real gain — you tested your idea sooner.
• You pay interest — every next change in that spot takes a bit longer. The value is hardcoded in three places — you change it three times. The copied code drifted apart — you fix the same bug twice.
• You stop paying entirely — interest eats all your speed. A project where a feature used to take an evening now takes weeks. Not because tasks got harder — because every step snags on old cut corners.

And here's the important bit: even good code becomes debt. You honestly wrote a module for yesterday's problem, then the product turned — and code that was right yesterday is in the way today. Debt is the gap between "how it's written" and "what's needed now," not someone's laziness.

What debt looks like in a real project

Signs you'll feel in your gut:

• A simple change like "edit the button label" somehow touches five files.
• There's a file you think about as "better not touch it, everything will break."
• One two-hundred-line function does everything at once, and nobody remembers why.
• To add anything new, you first spend half an hour re-learning how the old stuff works.

Now, about AI. Vibe coding generates code in minutes — and debt piles up at the same speed. Models happily write new code instead of reusing old code: ask for three forms — get three copies of nearly identical code. Each one works, review passed, everything's green. A month later you change a validation rule and edit it in three places. That doesn't mean AI code is bad — it means the borrowing speed went up while the repayment speed stayed human. Yours.

Three signals it's time to pay

You don't repay debt "all at once" — you catch the moment when the interest hurts more than the gain:

1. Changes got sticky. A half-hour task reliably turns into half a day because everything is coupled to everything.
2. Fear showed up. You avoid touching some part of the code. Fear is the most honest debt indicator there is.
3. A new feature "doesn't fit." You realize you'd have to reshape the old structure first. That's the invoice arriving.

How to repay without stopping the project

No "one month for a rewrite." What works is this:

• The scout rule: whenever you touch a file for any reason — leave it slightly cleaner than you found it. Rename a cryptic variable, extract a duplicate into a function. Five minutes at a time.
• Small doses of refactoring: one improvement — one check that nothing broke. Don't mix it with new features.
• AI is great at repaying debt if you ask directly: "find duplicated code in these files and extract the common part into one function; don't change behavior." Reading the result is still your job — we covered exactly how — but the model takes on the grunt work.

Is technical debt always bad?

No. Deliberate debt to test an idea is a normal tool: an MVP is mostly made of it. Only unnoticed debt is dangerous — the kind silently accruing interest.

Can you code with zero debt?

No, and you shouldn't try: you can't write perfect code for tomorrow's requirements, because you don't know them yet. The question isn't "how do I never borrow" — it's "how do I repay regularly."