What is technical debt?
Technical debt is a metaphor, coined by Ward Cunningham in 1992, comparing a rushed piece of code to a financial loan. Taking the shortcut buys you speed today. Like a loan, it accrues interest — every future change to that code costs a little more than it would have if the shortcut had never been taken, until eventually someone pays down the principal by refactoring it properly.
Deliberate debt vs. accidental debt
Martin Fowler's technical debt quadrant splits it two ways: deliberate versus inadvertent, and reckless versus prudent. Prudent-deliberate debt is a team knowingly cutting a corner to hit a real deadline, with a plan to come back to it. Reckless-inadvertent debt is code written without the experience to know a better way existed — nobody chose to take on debt, it simply accumulated. Both look identical in the codebase months later; the difference is whether it was a decision or a byproduct.
What it actually looks like
Rarely a single dramatic decision. Usually a slow accretion: a function that started at cyclomatic complexity 4 gains one more elif for each new edge case a customer reports, until eighteen months later it's sitting at 30 and nobody remembers which branch handles which case anymore. A file that "just gains one more responsibility" each sprint until it's doing five unrelated jobs. Nothing about any single commit looked alarming.
Why this is a sharper problem for AI-generated code specifically
An AI coding assistant will add the fifteenth elif branch exactly as willingly as the first, because it has no memory of how the function looked six prompts ago and no instinct that says "this function has grown enough, time to refactor before adding more." A human developer working alone in the same file for months at least has some felt sense that a function is getting unwieldy. An assistant generating a function fresh in each prompt doesn't accumulate that discomfort — which means the debt can compound faster and more invisibly than it would in code written by hand.
Paying it down without a "quality week" that never happens
- Measure before guessing. Don't refactor the file that feels worst from memory — check which one actually has the highest complexity or the deepest nesting.
- Budget a fixed slice of time, not a special event. A recurring 10–15% of each work cycle spent on the worst-scoring file beats waiting for a dedicated "quality sprint" that keeps getting bumped for new features.
- Fix outliers, not everything. The file that's 3x the codebase's average complexity is worth your time. The file that's 10% above average usually isn't, yet.
How REPO-SIGHT fits in
REPO-SIGHT doesn't have access to your git history in the current version, so it can't compute a true churn-weighted "hotspot" score the way tools with full commit history can. What it gives you instead is a structural proxy from a single point-in-time scan — complexity, nesting, and function length per file — which is usually enough to spot the worst offenders even without historical data.