“We don’t have tech debt.”
Come on, I know you’re lying.
I have heard this line for more than a decade.
“We’re fine. We don’t really have tech debt.”
And I hear this usually right before:
a “one-day change” turns into a week
production incident reveals nobody understands one critical flow
the team touches one old module like it is a landmine
And that… That is tech debt.
And no, it is not just old libraries.
Again: working software can still be debt-ridden software.
Tech debt is not one thing
Most dev teams reduce it to dependency hygiene:
old packages
outdated framework versions
TODO comments from three product managers ago
That is real debt. No debate there.
But the uglier debt is usually invisible:
what the team no longer understands
what was never documented
what AI generated in 20 minutes and nobody really internalized
It is visible, measurable, and easy to plan.
The trap is obvious: people fix what they can count.
So they count CVEs, version gaps, stale libs.
Meanwhile, architecture drifts and team understanding erodes quietly in the background.
The debt that drains velocity: architecture
This appears when local shortcuts slowly kill global coherence.
Symptoms:
duplicate logic across services
unclear module boundaries
“temporary” integrations that became permanent
coupling nobody planned
Code still compiles. Features still ship.
But every next change costs more negotiation, more regression risk, more fear.
I have seen teams with “clean code” and broken architecture.
Nice functions. Painful delivery.
If your team says “it’s just one more exception” every sprint, you are already paying architecture interest.
What if your A-player leaves?
Knowledge debt is the gap between how the system behaves and how much the team truly understands.
Examples:
critical flow understood by one person only
business rules trapped in Slack, Notion, and memory
onboarding takes months, not weeks or days
people are afraid to refactor because they cannot predict side effects
You are blocked by missing shared understanding.
When one senior leaves and velocity drops by 40%, that is not a hiring problem first.
That is knowledge debt coming due.
Decisions.
Every system is a graveyard of old trade-offs.
When trade-offs are not recorded, the team keeps re-deciding the same problems:
“Why did we choose this queue?”
“Why not event-driven here?”
“Was this endpoint intentionally synchronous?”
Without lightweight ADRs or any decision log, context evaporates.
Then teams confuse old constraints with current reality.
Same debates, new sprint, same confusion. That is decision debt.
One classic smell: two senior engineers debating a decision from six months ago, both confident, both wrong, because the original constraints changed and nobody wrote them down.
So what about AI generated code?
AI increases throughput. It also increases the amount of code the team only “kind of” understands.
If you generate faster than you absorb, debt accumulates in the understanding layer first, and in production behavior later.
That is why teams can look “productive” and fragile at the same time.
The dangerous myth: “If it works, we’re fine.”
Working software is not healthy software.
A lot of debt stays hidden until:
a new integration arrives
traffic doubles
team composition changes
incident response requires knowledge nobody has
By then, paying that debt is much more expensive.
What to do instead (pragmatic version)
You do not need a 6-month “tech debt transformation program.”
You need boring engineering discipline.
Start with tracking debt by type, not as one generic backlog label. Add one architecture checkpoint per sprint. Write short ADR notes for non-trivial decisions (really short, but written).
Small process upgrades beat heroic cleanup projects every time.
Sooooo?
So next time someone says, “We don’t have tech debt,” ask two questions:
Do we have current dependencies?
Good.
Do we still understand the system we are shipping?
If the second answer is “mostly” or “kind of,” you have debt.
You just have not paid interest yet.
If this sounds familiar, do a quick audit with your team this week:
Where are we carrying dependency debt?
Where are we carrying architecture debt?
What part of the system is “known” by one person only?
If those answers are uncomfortable, good.
That is where your next engineering win is.