Developer & Tech
Does Technical Debt Still Matter When Code Is Cheap to Write?
By Jim Vernon, Editor, AI Intelligence International · Published 15 August 2026 · Reviewed against our editorial standards · About the author
A common argument holds that technical debt matters less now: if code is cheap to write, rewriting is cheap too. The argument is wrong in a specific and important way.
Generation reduced the cost of producing code. It did not reduce the cost of understanding a system, coordinating a change across it, or recovering from an outage — and those were always where debt was actually paid.
Key takeaways
- Writing was never the expensive part; comprehension and coordination were.
- Cheap generation increases volume, and volume is what makes systems hard to understand.
- Duplication is now the fastest-growing debt category and the easiest to create accidentally.
- Invest in the things that make a system legible: tests, boundaries, and deleted code.
What did technical debt actually cost?
Not the typing. It cost comprehension time when someone new had to understand the system, coordination time when a change touched five places, and incident time when the failure mode was surprising.
None of those scale down with faster generation. Reading a 4,000-line module to understand whether a change is safe takes the same time whoever or whatever wrote it.
If anything, comprehension is harder for code nobody on the team composed, because there is no author memory to draw on.
Why does cheap generation make debt worse?
Volume. When producing a new implementation costs minutes, teams produce more code, and total system size is the strongest predictor of how hard it is to change.
Duplication specifically. It is now faster to generate a new function than to find and understand the existing one, so the same logic appears in four places with slight variations, and a bug fix reaches one of them.
Premature abstraction. Generated code tends to be generalised beyond need, adding configuration surfaces and indirection that must be understood by everyone who comes after.
Which debt is genuinely cheaper to fix now?
Mechanical debt: renaming, mass migrations, adding types to an untyped codebase, writing missing tests for well-defined behaviour, updating deprecated API usage.
These were previously deferred on effort grounds and are now a day's work. Teams should be clearing them aggressively, because the reason not to has disappeared.
This is a real and underused win, and it is worth an explicit quarterly sweep.
Which debt got harder?
Architectural debt, which requires deciding what the system should be rather than writing more of it. Generation does not help with the decision and makes it easier to avoid making one.
Anything requiring institutional knowledge: why a constraint exists, what a workaround was protecting against, which behaviour a customer depends on.
Debt in code nobody understands, which is a growing category and is exactly where incidents become expensive.
What should teams do differently?
Treat deletion as first-class work. Removing code is the highest-leverage activity in a codebase growing faster than before, and it is systematically under-rewarded.
Enforce a search-before-generate norm for anything non-trivial, backed by tooling that makes finding existing implementations fast. Duplication is prevented at the moment of writing or not at all.
Keep module boundaries tight and explicit, since boundaries are what let people understand one part without reading everything.
Track total system size as a metric people see. Anything unmeasured grows, and this now grows faster than it used to.
How do you make the case to non-engineers?
In terms of delivery predictability rather than code quality. Debt shows up as estimates being wrong and as small changes taking a fortnight, both of which stakeholders care about directly.
Use concrete instances: this change touched nine files because the same logic exists in nine places, and that is why it took three days instead of three hours.
Propose bounded work with a stated outcome rather than an open refactoring budget. 'Consolidate the four pricing implementations into one, two weeks, then pricing changes take a day' gets approved; 'reduce technical debt' does not.
Worked example: four pricing implementations
A subscription business found that a pricing change requested by finance — adding a regional discount tier — was estimated at three weeks by their team of eight, which nobody could explain to the CFO.
Investigation found pricing logic in four places: the checkout service, the renewal job, the admin override tool, and a reporting query. Three had been generated within the previous year, each by a different engineer who had not found the existing implementation.
The four disagreed subtly. A rounding difference between the checkout and renewal implementations had been producing invoices off by small amounts for months, generating roughly 15 support tickets a quarter that had never been traced to a root cause.
The consolidation took eleven working days: one shared pricing module, four call sites, and 61 tests written from the finance team's stated rules rather than from any existing implementation. Two of those tests failed against all four old implementations, which surfaced a second discrepancy nobody had noticed.
The regional discount tier, once consolidated, took a day and a half. The next three pricing changes took under a day each, against a previous average of nine days.
Total code in the pricing area fell by about 40%, and the quarterly rounding tickets went to zero. The team's rule afterwards was simple: before generating anything that touches money, search for it first, and if you find more than one implementation, that is a ticket.
Frequently asked questions
Is it cheaper to rewrite rather than refactor now?
Sometimes, for isolated components with clear behaviour and good tests. Almost never for anything with unclear behaviour, because the rewrite loses the accumulated edge-case handling that nobody documented.
How do you find duplication that already exists?
Structural similarity tooling plus targeted searching around anything business-critical. Money, permissions and identity are the areas where duplication is most costly and worth auditing first.
Should teams set a code-size budget?
A visible metric is more useful than a hard budget, which invites gaming. Reporting total size and net change per quarter is usually enough to change behaviour.
Does this change how you onboard new engineers?
Yes. Comprehension is the bottleneck, so invest in a written architecture overview and in module boundaries. Onboarding time is a good proxy for how legible your system actually is.