“Tech debt” is the most overused phrase in our industry, and one of the least precise. We use it to excuse the mess we shipped last quarter and to blame the team that shipped the mess before that. What we almost never do is use it the way it was meant: as a tool.
Because intentional debt is a tool. Accidental debt is the problem. They share a name, and that shared name is costing us more than the debt itself.
One Phrase, Two Opposite Things
The same two words cover two situations that have nothing in common.
One is a deliberate shortcut. Someone looked at the tradeoff, decided to ship the cheaper version now, and knew exactly what it would cost to make it right later. The other is a mess nobody chose. It just piled up. No decision, no plan, just the residue of a hundred small “we’ll fix it later” moments that never got fixed.
These are opposites. One is a financial instrument we took out on purpose. The other is a leak we didn’t notice until the floor was wet. But we file them under the same label, so the conversation collapses.
A developer says “this is just tech debt, we’ll get to it” and means the first thing. A manager hears “tech debt” and means the second. They’re now arguing, and neither realizes they’re talking about different objects.
The word did that. It hid the one distinction that actually matters1.
Pull the two apart, and most arguments about debt resolve themselves.
Intentional Debt: The Shortcut We Chose
Intentional debt is a shortcut taken on purpose, with the cost known up front and a plan to repay it.
We’re launching a feature next week. The config it needs will go into a proper settings system eventually, but that system is two sprints out. So we hardcode the three values, ship on time, and write the backlog item to replace them the week after launch.
That’s intentional debt. We traded correctness-now for speed-now. We know the size of the trade (roughly an afternoon to undo), and the repayment is already scheduled. Next sprint the settings system lands, the three values move into it, the backlog item closes, and the loan is paid.
The same idea shows up everywhere once we look. Skipping the cache and hitting the database directly because the launch won’t see enough traffic to matter yet. Returning the whole result set instead of adding pagination, because the table holds a few hundred rows today, and the page renders fine. Shipping the manual admin step because automating it costs three days we don’t have this sprint.
What makes all of these tools rather than liabilities is the same thing every time: a decision and a cost analysis behind it. Someone weighed the trade, named the cost, and wrote it down where the team can see it. Done that way, intentional debt genuinely accelerates delivery. We buy speed now, and we know the bill is coming, the same way a business takes a loan to seize an opportunity it couldn’t afford to wait for. The debt is real. So is the return.
There’s a catch, and it’s the one teams reliably trip on. Intentional debt only stays intentional while the ledger entry is alive. The backlog item you wrote to replace those hardcoded values is what keeps this a strategy rather than a mess. Let it slide to the bottom of the backlog, let the launch ship and the team move on, and the same code that was a smart trade on Monday becomes indistinguishable from accidental debt by the end of the quarter.
The shortcut didn’t change. The decision behind it expired. Intentional debt that never gets repaid isn’t a special, forgivable category. It’s accidental debt with a better origin story.
So the discipline isn’t in avoiding the shortcut. It’s in the ledger, and in keeping the ledger honest after the pressure that justified the shortcut is gone2.
Accidental Debt: The Mess Nobody Chose
Accidental debt is everything the previous section wasn’t.
No decision. Nobody weighed a trade. The fifth branch got bolted onto the type-code ladder because it was the fastest way to close the task, and the person who added it wasn’t thinking about debt at all, they were thinking about lunch3. No known cost. Ask how long it would take to untangle the service that seven features now route through, and the honest answer is a shrug4. And no repayment plan, because we can’t schedule the repayment of something we never recorded taking on.
This is what most teams mean when they say “we have a lot of tech debt”. Not a portfolio of deliberate trades with known payoffs. A pile of decisions nobody remembers making, with costs nobody measured, that slow everything down and buy nothing in return.
That last part is the whole point. Intentional debt buys us speed. Accidental debt buys us nothing. It is pure drag, a tax with no service behind it.
And because it wears the same word as the useful kind, it gets the same shrug: “that’s just tech debt”. It isn’t. It’s the thing the useful kind was named after, borrowing its name to avoid getting fixed.
One kind is a loan. The other is just a moan.
It’s worth saying plainly: accidental debt is rarely anyone’s fault, and treating it as one is part of why it never gets fixed. Nobody set out to build the unownable service. It grew one reasonable-looking commit at a time, each made under deadline by someone solving the problem in front of them. That’s exactly why “who let this happen” is the wrong question5.
There was no single decision to trace back to a person, which is the definition of the accidental kind. The useful response isn’t to blame for the mess that exists. It’s a habit that stops the next one from piling up unseen.
The LLM Gotcha: The Velocity Push Widened the Gap
The intentional vs. accidental distinction always mattered. It matters even more now, and the reason is in our editors.
AI-assisted coding made it trivial to produce a lot of plausible code very fast. That is genuinely useful, and it has a side effect we’re only starting to price in: code now ships faster than anyone decides anything.
A generated module lands in the PR fully formed, reads fine, passes the tests, and gets reviewed read blindly accepted. Nobody chose its shape. Nobody weighed a trade. There was no decision, so by definition there’s no ledger entry. That’s accidental debt, accumulating at machine speed.
The dangerous part is the costume. Because the output is fast, it feels like the good kind of debt, the intentional shortcut that buys velocity. It isn’t.
Speed of typing was never what made debt intentional. The decision was. Generated code gives you the velocity without the decision, which is exactly the combination that produces accidental debt faster than any human team ever could.
The gap between the two kinds of debt didn’t close in 2026. It got wider, and a lot of it is now invisible, hidden in code no human ever chose to write that way.
A Test That Tells Them Apart
We don’t need a framework to sort one from the other. We need three questions, and we can run them on any shortcut in under a minute.
Did someone decide this? Was there an actual moment where a person weighed the trade and chose the shortcut, or did it just happen?
Is the repayment cost known? Can you say, even roughly, what it would take to make it right?
Is there a plan to repay it? Is the fix written down somewhere the team will see it, with some sense of when?
Three yeses, it’s intentional debt. We took out a loan with our eyes open, and that’s fine. It’s a tool.
Any no, it’s accidental. It doesn’t matter how good the intention sounded in the moment, and it doesn’t matter that we “meant to come back to it”. Meaning to is not a decision, a shrug is not a cost estimate, and a vague intention is not a plan. A shortcut that fails any of the three questions is a mess we haven’t admitted to yet, calling itself a strategy.
The test is boring on purpose. That’s what makes it usable in a standup.
What the Confusion Costs You
Mixing up the two kinds isn’t a vocabulary nitpick. It has a price, and we’re paying it in the one currency engineering teams can’t make more of: time.
When accidental debt hides behind the word “debt”, it never gets prioritized, because “debt” sounds like a choice we can defer. So it compounds. The branches multiply, the service nobody owns gets thicker, and every new feature has to route around the mess instead of through it.
In my experience watching teams hit this, a meaningful slice of each sprint, often something like a fifth to nearly a third of the capacity, quietly disappears into unplanned rework: re-opening code that “worked”, fixing the thing the last fix broke, paying for shortcuts nobody remembers taking. That’s not a measured benchmark, it’s an estimate from patterns I’ve seen repeat6. Every team’s number will differ. But if we’ve never named which kind of debt we’re carrying, the number is almost certainly not zero, and it’s almost certainly larger than anyone has admitted out loud.
The fix is cheap, which is the frustrating part. We don’t need a tool, a tracker, or a quarter-long initiative. We need a shared vocabulary.
Once a team can say “that was intentional, here’s the backlog item” or “that’s accidental, nobody chose it”, the two stop getting the same shrug. The intentional debt gets repaid on schedule. The accidental debt gets seen, named, and prioritized like the liability it is. The word stops hiding the distinction, and the distinction starts doing its job.
Adopting it costs one sentence in a code review. When someone ships a shortcut, ask: “Is this intentional, and where’s the backlog item?” If the answer is a task number, good, it’s a tool, and the team can see the bill coming. If the answer is a pause, we just caught accidental debt at the only moment it’s cheap to catch: before it compounds.
That single question, asked consistently, is the entire intervention. It turns a word everyone uses loosely into a decision the team makes on purpose.
The Takeaway
Intentional debt is a tool we picked up on purpose. Accidental debt is a tax we’re paying without a vote. They share a name, and that shared name is the most expensive thing we haven’t fixed.
Forward This to Your Team
If your team uses “tech debt” as both an excuse and an accusation, it’s missing the third meaning, the one that turns the phrase into something useful. This is the post to forward when you want everyone working from the same definition.
Here’s the version for the person who decides what the team works on next:
This reframes tech debt as a conscious engineering tool, not a failure. It separates intentional debt (a deliberate shortcut with a known cost and a plan to repay) from accidental debt (the mess nobody chose, with no cost and no plan). The point: intentional debt speeds delivery when it’s tracked and repaid on schedule. Accidental debt, which is what most teams actually accumulate, slows delivery and buys nothing. Teams that confuse the two quietly lose a real chunk of every sprint to unplanned rework. Worth fifteen minutes if we want a shared vocabulary for how we talk about debt on this team.
The goal isn’t to take on less debt. Some debt is the right call. The goal is for your team to know, every time, which kind it’s taking, and to stop letting the accidental kind hide behind the word the useful kind earned.
Media attributions:
Cover image by the author (generated with Gemini)
This split isn’t new. Ward Cunningham coined the debt metaphor at OOPSLA 1992, in the WyCash experience report, and Martin Fowler’s Technical Debt Quadrant later sorted debt along two axes: deliberate vs. inadvertent, and prudent vs. reckless. Our intentional-vs-accidental cut is essentially Fowler’s deliberate-vs-inadvertent line. What’s new here is the claim that the industry still files both halves under one word, and that merging is the expensive part.
Yes, this sounds like overhead, one more thing to track. It isn’t, as long as the test does its filtering: we only log the debt that passed the three questions, the deliberate kind, not every shortcut anyone ever took. The ledger can be as plain as a TECHDEBT.md in the repo. The catch is discipline. That file only works if the team actually reviews it on a schedule, the same way it would a real backlog. A ledger nobody reads is just accidental debt with better formatting.
Lunch, unlike the launch, shipped on time.
A shrug is not a recognized estimation unit, though it predicts delivery dates about as well as story points.
It's also a bad question because it's the opposite of a blameless culture. We should hunt the cause, not the actor. The moment "who wrote this" becomes the question, people stop pointing at the messes they already know about, and the accidental debt we most need to find goes underground. Amy Edmondson named the alternative psychological safety. Google's Project Aristotle later ranked it the most important factor in how well a team performs. Blame is just a reliable way to make the next mess hide better than the last one.
Stripe’s 2018 The Developer Coefficient put it near a third of developer time lost to bad code and technical debt (about 13.5 hours of a 41.1-hour week). Treat it as a directional industry estimate, not a measurement of your team.