Technical debt is the cost of the shortcuts in your software: the decisions that made something faster to build and will make everything after it slower to change. Every real system carries some. The question has never been whether you have it. It is whether you know where it is and whether you are paying it down or letting it compound.
AI has changed the shape of that question, and mostly not in the direction people expect.
What changed
For twenty years technical debt accumulated at the speed a team could type. A shortcut was a deliberate act by a person who usually knew it was a shortcut. AI coding tools have removed both limits. Code is produced faster than anyone can review it, and the shortcuts are taken by a tool that does not know it is taking them.
Three things follow.
More code, less understanding. A system can now grow to a size that no one on the team has read in full. The knowledge of why a piece exists, which used to live in the head of the person who wrote it, sometimes lives nowhere at all.
Debt looks like progress. A working screen produced in an afternoon feels like a win. The tests, the error handling, the security, and the data model behind it are exactly the things a tool skips when nobody asks, and they are invisible from the screen.
The bill comes due faster. Because the system grows faster, it reaches the point where changes break other things in months instead of years. We now see companies hit the wall on a system that is eighteen months old.
None of this is an argument against the tools. We use them every day. It is an argument for knowing what you are accumulating.
Healthy debt and the other kind
Not all of it is bad. Some debt is a sound business decision.
Healthy debt is deliberate, documented, and scheduled. You ship the first release with a simple version of a feature because you do not yet know whether customers want it, and you write down what you skipped and when you will revisit it. The interest is small and you are paying it on purpose.
Unhealthy debt is accidental and invisible. Nobody chose it, nobody knows where it is, and it shows up as a pattern: changes take longer each time, bugs recur, the same problem gets fixed twice, and the one person who understands the system becomes irreplaceable. This is the kind that stops a business, and it is the kind AI tools produce when they run without engineering discipline around them.
Five signs you have more of the second kind than you think:
- Nobody can say how long a small change will take.
- Fixing one thing breaks another, and it is a surprise every time.
- There is a part of the system people are afraid to touch.
- New engineers take months to become productive.
- The answer to “why does it work this way” is “it just does.”
Why we pay it down as we go
There are two ways to handle technical debt: let it accumulate and schedule a big repayment later, or pay a little on every release. We do the second, on every project, for the same reason you pay a credit card monthly instead of once a decade.
The big-repayment plan fails for a predictable reason. The repayment never gets scheduled, because there is always a feature that matters more, until the day the system cannot take another feature and the only option left is a rewrite. Rewrites are the most expensive and most failure-prone projects in software. We have rescued enough of them to say that with confidence.
Paying as you go looks like this in practice:
- A share of every cycle goes to the foundation. Tests, refactoring, dependency updates, and documentation are in the plan, not squeezed in when someone has time.
- Debt is written down when it is taken on. A decision to skip something is recorded with the reason and the trigger for revisiting it, so it is a choice rather than a discovery.
- Reviews look for it. Senior engineers review all the work, and part of what they are looking for is the shortcut that will cost more later than it saved today. This matters twice as much when a tool wrote the first draft.
- The disciplines never come off. Source control, separate environments, automated testing, code review, and monitoring are the guardrails that keep fast from becoming fragile. They are the first thing an unsupervised AI tool skips and the first thing we put back on a rescue.
The cost is a slightly slower first release. The return is a system that is still cheap to change in year three, which is where most of a system’s life and value actually sit.
What to do if you suspect you are carrying too much
Find out. A System Evaluation tells you what you have, what it would take to stabilize it, and what to fix first. If the system was built quickly with AI tools by one capable person, that is exactly the situation it is scoped for, and the answer is usually not a rewrite. The what is technical debt post covers the basics if you want them, and before an AI-built system runs your business covers the specific case.
If a system you depend on is getting harder to change every month, here is how getting started works.