Don't deal with technical debt at the end. Deal with it in every commit.

The article argues against deferring technical debt to one-off “hardening sprints”

Two teams, the same company, the same product. Team A delivers eight stories per sprint and once a quarter schedules a "hardening sprint" for technical debt. Team B delivers six stories per sprint, but every pull request leaves the code cleaner than the developer found it. After a year, Team A has a velocity of three stories per sprint and a backlog full of regression bugs. Team B steadily delivers seven.

This scenario is not hypothetical. It is a pattern that repeats in every organization that puts off code maintenance until "later." And the data shows why.

The Stack Overflow Developer Survey 2024 found that technical debt is now the leading professional frustration for over 62% of the 65,000 developers surveyed — roughly twice as much as any other complaint. A longitudinal study by Besker, Martini and Bosch of Chalmers University tracked 43 developers twice a week for seven weeks and measured that developers lose an average of 23% of their working time to technical debt. A replication study with 258 respondents showed as much as 36%. The most common cause of lost time was additional testing — compensating for shortcuts that someone took "temporarily."

Technical debt does not behave like a mortgage with a fixed payment. It behaves like a credit card with a variable interest rate. You pay interest every time you have to work with the affected part of the code — and in an actively developed project that is constant.

Ward Cunningham, the author of the original 1992 metaphor, clarified it himself: he never meant the deliberate writing of poor-quality code with a plan to fix it later. He was talking about the evolution of one's understanding of the problem domain — about how, after months of development, you finally grasp how the system should have looked from the start. That is unavoidable. What is not unavoidable is leaving that insight to lie idle.

Picture the code as a city. Every shortcut is a pothole in the road. One pothole is a trifle — you drive around it. Ten potholes and you start planning detours. A hundred potholes and no one knows which route is passable. Fixing one pothole in the first week takes minutes. Fixing a hundred potholes after a year requires you first to map out which roads even exist.

GitClear's 2025 data, analyzing 211 million lines of code, documents this mechanism. The share of refactoring operations (moving existing code to the right place) fell from roughly 25% in 2021 to less than 10% in 2024. At the same time, the overall rate of copied code rose by 48%, and the number of duplicate blocks with five or more repeated lines rose eightfold over the course of 2024. Developers are giving up on refactoring and copying instead. Every copy is a future bug multiplied by the number of duplicates.

Why does this happen? Because the system rewards short-term velocity. When a team discovers on the tenth day of a sprint that it will finish only three of the five promised stories, stakeholders perceive three quality stories as a failure — but five stories with shortcuts as a success. The Agile Alliance described the destructive spiral that results: deadline pressure raises velocity at the expense of quality, this leads to the accumulation of debt, a decline in actual velocity follows, and even greater deadline pressure.

Deferring debt to the end stems from waterfall thinking, where a project has a defined start and finish. In agile development the product is a living organism with an indefinite horizon. Even if you have a fixed release date, the code does not disappear afterward — someone else will maintain it.

Google tried a different approach. They tackled debt with one-off migrations — "let's rewrite module X into the new architecture." Unfinished migrations became the most frequently reported category of technical debt across the entire company — that is how an internal quarterly survey of engineers identified it. Only a continuous approach with a maturity model, regular metrics and systematic training produced the largest positive trend in five years of measurement.

SAFe offers an Innovation & Planning iteration at the end of every Program Increment, intended to serve innovation and debt reduction. In practice, however, it often degenerates into a dumping ground for unfinished work from previous sprints. Developers know it as the "catch-up sprint" — and the debt that lands there often remains untouched even after it.

The solution is not "either continuously or in one go." It is a two-layer system.

Layer 1 — micro: every commit, every day. Robert C. Martin formulated the Boy Scout Rule: leave the code in a better state than you found it. You open a file for a feature, you see a magic number, an unclear variable name, a missing test — you fix it now, in that same pull request. It does not take hours. It takes minutes. But the cumulative effect is enormous: with five developers and three commits a day, that is 75 micro-improvements a week. No planning, no negotiating with the product owner, no tech-debt sprint.

Context is the key argument for the micro-layer. The developer who wrote a shortcut on Tuesday knows exactly why and how to fix it. Three sprints later no one knows — including the developer themselves. The Besker et al. study identified the loss of context as the main reason additional testing consumes so much time.

Layer 2 — macro: dedicated capacity for architectural problems. The Boy Scout Rule will not fix a poorly chosen messaging architecture or a missing abstraction layer. For that you need planned capacity. Proven approaches:

The rule of allocating 15–20% of each sprint's capacity to reducing technical debt is recommended in agreement by both Scrum.org and McKinsey. Shopify distinguishes four time horizons: daily micro-improvements (about 10% of time), weekly "discoveries" (about 10%), monthly targeted refactorings and annual systemic rewrites.

The two layers complement each other. The micro-layer addresses entropy in everyday code. The macro-layer addresses architectural problems that span more than one file. Neither of them is deferred to the end.

Fairness requires acknowledging that there are legitimate scenarios for the deliberate accumulation of debt.

An early-stage startup validating product-market fit. If you are likely to throw the code away entirely, investing in its quality is wasteful. Investors reward traction, not clean code. Even in this context, however, it makes sense to allocate at least 10% of the sprint to debt and to strictly separate the proof-of-concept (to be discarded) from production code.

Stable code that does not change. Fowler points out that you pay interest on technical debt only when working with the code in question. A module that works, that no one touches and that carries no security risk, you can leave alone. But beware of self-assessed "stability" — in an actively developed product there is less stable code than you think.

Unambiguous time-to-market pressure. A conscious, documented trade-off with a remediation plan is a legitimate engineering decision. The key word is documented. Undocumented debt becomes invisible — and invisible debt does not get paid down.

All three scenarios have one thing in common: the debt is conscious, bounded, and has a repayment plan. None of them means "we'll deal with it at the end."

Change does not require reorganization, a new tool, or management approval. It requires three things.

First, a team agreement that every pull request will leave the code better than it found it. Not perfect — better. Renaming a variable, extracting a method, adding a test. Minutes of work, months of cumulative effect.

Second, visibility of debt. Chelsea Troy (Mozilla), on the Stack Overflow blog, recommends ceasing to talk about "technical debt" — the term is too abstract for business stakeholders. Instead, talk about maintenance load: what percentage of the team's capacity is consumed by maintenance that neither adds nor removes features. If you have six developers and 50% of capacity goes to maintenance, plan features for only three. The business will understand this immediately, because it sees engineers as expensive.

Third, protection of capacity. That 15–20% of the sprint for architectural debt. Not as a "bonus if time is left over" — as a fixed part of sprint planning. The DORA Report 2024, based on responses from over 39,000 professionals, confirms that teams with lower technical debt achieve better results across all four key metrics: deployment frequency, lead time, change failure rate, and time to recover from an incident.

One note on the elephant in the room. GitHub reports that 41% of code is now generated with the help of artificial intelligence, and according to Stack Overflow 2025 over 84% of developers either use AI tools or plan to start. A new variable thus enters the picture. The METR study of 2025, conducted as a randomized controlled trial on 16 experienced developers and 246 tasks, showed that with AI they were 19% slower — while they themselves estimated a 20% speedup. Among the causes they identified were the time spent reviewing and editing AI-generated code, as well as the cognitive switching between writing and prompting.

An analysis by OX Security (300+ open-source repositories) identified systematic anti-patterns in AI-generated code: avoidance of refactoring and over-specification (80–90% incidence), violation of the code-reuse principle leading to repeated bugs (70–80%), and false test coverage that inflates metrics without genuinely validating logic (40–50%). The DORA Report 2024 quantified the relationship at the macro level: an increase in AI adoption is associated with a 7.2% decline in delivery stability and a 1.5% decline in throughput.

AI is an amplifier, not a solution. For a team with a culture of continuous refactoring it is an accelerator. For a team that defers debt to "later" it is an accelerator of problems.

Technical debt is not an alternative to delivering value. It is a tax that grows with every day of delay. The cheapest day to fix the code is today. The most expensive is the day the customer tells you about it. Or the day the developer who was the only one who knew how that module worked walks out — and surveys show that roughly every second developer is considering leaving because of technical debt.

Don't deal with debt at the end. At the end it is too late.

Sources: Stack Overflow Developer Survey 2024/2025, Besker/Martini/Bosch — Chalmers University (2018, replication 2019), GitClear AI Code Quality Research 2025, Martin Fowler — TechnicalDebt/TechnicalDebtQuadrant, Jaspan/Green — Defining, Measuring, and Managing Technical Debt (Google, 2023), DORA Report 2024, METR Study 2025 (arXiv:2507.09089), OX Security — Army of Juniors Report 2025, Agile Alliance — Technical Debt is a Systemic Problem, Chelsea Troy — Stop saying "technical debt" (Stack Overflow Blog, 2023).

Transparency of creation

The concept, structure, and editorial line of the article are the work of the author, who prepared the content outline, established the key theses, and directed the entire creative process. Generative AI (Claude Opus 4.6, Anthropic) was used as a tool for research, fact-checking, and fleshing out the author's draft.

The author verified the key findings and approved the final wording. No part of the text was published without conscious authorial control. The factual data were verified against the publicly available sources listed in the text.

The procedure complies with the transparency principles of EU Regulation 2024/1689 (AI Act). #poweredByAI