technical debt

basicwidespread

Technical debt is the cost of accumulated quick, unfinished solutions in software: they save time today but make every future change slower and more expensive.

In plain terms

Imagine that during a renovation, the electrician does not embed the wire in the wall but solves it with an extension cord because you are moving tomorrow. It works, but with every new lamp and socket, you have to go around it, and eventually, it must be done properly. In software, this is technical debt: a quick solution is a loan that you pay back later with interest.

The 'interest' is the extra work that arises with every subsequent modification: new features are built more slowly, there are more bugs, and it is harder to train new colleagues. The 'capital' is the cleanup itself, meaning the time it takes someone to rewrite the code properly.

Debt is not necessarily bad. If a deadline or market opportunity is worth it, it can be taken on intentionally, like a mortgage. Problems begin when no one keeps track and repayments are always missed.

In the AI era, the topic has gained new weight: coding agents write vast amounts of code that works at first glance in minutes, but if no one reviews and maintains it, technical debt grows just as fast.

How it works

Taking on debt: the team chooses the faster path over the better one, for example skipping tests, copying a piece of code instead of writing a shared solution, or not documenting.
Interest: the system keeps working, but every new development takes a little longer because the old workarounds have to be worked around.
Accumulation: newer fast solutions build on older ones, so over time even a small change can cause errors in unexpected places.
Accountability: a good team keeps a list of its debts and estimates how much time each item takes per month.
Repayment: developers regularly receive time to refactor code, add tests, and replace outdated elements, preferably starting with the items carrying the highest interest rates.

An everyday example

Your favorite online store's app has not received new features for months, and updates consistently break something that previously worked. Behind the scenes, this is often because developers spend most of their time navigating old, patched-together code, effectively paying the interest on technical debt.

Who is affected

developerThey feel it daily, because disorganized code makes every task take longer and generate more errors. → Code

entrepreneur, executiveThey decide how much time is allocated for cleanup and pay if development slows down or the system needs rewriting.

employeeIf corporate systems are slow, cumbersome, and frequently go down, the cause is often technical debt that has been postponed for years. → Work & HR

everyoneBehind the sluggish, outdated systems of banks, government agencies or service providers, there is often accumulated technical debt.

A common misconception

MythTechnical debt is simply the result of bad, sloppy programmers' work.

In realityIt is often a conscious and rational business decision to get something done first, and technical debt arises even in good teams because requirements and technology change along the way. The problem is debt that is not tracked and never repaid.

Limits and risks

It is hard to quantify precisely in forints: there is no unified metric, and estimates vary by team and by tool.
From the outside, it remains invisible for a long time because the program runs, while leaders only perceive slowdowns and errors.
The analogy is flawed: unlike a bank loan, there is no contract or known interest rate here, and it may happen that a debt never needs to be repaid because the code is discarded.
Code rapidly produced by AI agents without review can silently increase technical debt if no one understands exactly what and why the machine wrote it.

Similar, but not the same

szoftverhiba (bug) – A bug means the program works incorrectly, whereas a program with technical debt may work well but is hard and expensive to modify.
legacy system – A legacy system is old but still used software, while technical debt is accumulated deferred work within it (or even in brand-new code).
refactoring – Refactoring is not the debt itself but one way of paying it down: tidying up code so that its behavior does not change.

Related concepts

Broader

software development, software quality, software maintenance

Narrower

code debt, architectural debt, testing debt, documentation debt

On the edge

refactoring, legacy system, code review, vibe coding, coding agent

A brief history

The debt analogy was introduced by American programmer Ward Cunningham in 1992 in a conference report on financial software (OOPSLA) to explain to business leaders in understandable terms why time must be spent on code cleanup. He wrote only of 'debt'; the term 'technical debt' spread in the following years and has since become a fundamental term in the software industry.

Where things stand

At the end of 2026, the term is part of the software industry's everyday vocabulary, used by both developers and executives. With the spread of coding agents, a new debate is underway on whether AI accelerates debt repayment or, through mass-generated code, increases the debt.

Status: 2026 November

In the news

Appears in 2 Agent Age stories; the curve shows weekly occurrence in the news magazine.

Harvard study of 718 firms: AI produces more code but does not speed up deliveryOct 19, 2026 · Code
AI-generated code raises quality and maintainability risks, says Info-Tech; GitHub launches Code QualityAug 10, 2026 · Code

Also known as

technical debt · technical debt · technical debt · code debt · technical debt · tech debt · code debt · design debt

Sources

Martin Fowler: Technical Debt

This entry was machine-edited and has undergone machine expert review; the “In the news” section updates automatically from Agent Age stories.