Tech debt = near-zero steady state

Tech debt near-zero steady state is the L5 condition where technical debt does not accumulate over time because the rate of debt remediation equals or exceeds the rate of debt creation. This is not a debt-free codebase - debt is continuously created by feature development under time pressure, changing requirements, and evolving standards. It is a codebase where debt is continuously eliminated as fast as it is created, producing a stable, low-debt baseline rather than the compounding backlog that characterizes L1-L2.

The mechanism is continuous agent-based maintenance. At L5, an agent fleet runs 24/7 against the codebase: updating dependencies, applying refactoring recipes, migrating deprecated patterns, resolving lint warnings, and improving test coverage in areas where new features left gaps. These agents operate asynchronously, produce PRs that are reviewed on a lightweight SLA, and collectively handle more debt reduction per day than any human team could produce. The rate of automated debt reduction is high enough that the debt inventory stabilizes near zero rather than growing.

This is qualitatively different from the L3 state of "agents reducing debt." At L3, agents work through a backlog - there is a queue, and the queue is getting shorter, but it started from a large accumulated balance. At L5, there is effectively no backlog because debt is addressed before it accumulates into a backlog. A deprecated API introduced in a library update is replaced within days of the update, not months. A lint rule violation introduced in a feature PR is resolved in the next agent cycle, not flagged and deferred. The debt inventory is managed at the velocity of creation, not at the velocity of a periodic cleanup project.

The organizational implication is significant: at L5, engineering velocity is no longer capped by accumulated technical debt. Teams work in a codebase that stays clean because it is continuously cleaned. The "this area is too messy to touch" experience that characterizes L1-L2 development is absent because the messy areas are continuously improved. Developer experience is measurably better, and the productivity ceiling of a high-debt codebase is removed.

• Removes the velocity ceiling imposed by accumulated debt - In high-debt codebases, developer velocity declines over time as debt accumulates; in near-zero steady state, velocity is stable or improving because the debt ceiling is continuously removed
• Eliminates the debt paydown project category - At L5, there are no multi-week migration sprints, no "tech debt Q3" initiatives, no debt reduction projects competing with features; debt is handled continuously at maintenance cost, not project cost
• Produces consistently high developer experience - Developers working in a near-zero debt codebase report higher satisfaction, faster onboarding, and less time spent fighting the codebase; the quality of the work environment is a direct function of codebase quality
• Reduces incident rate from debt-related failures - A significant fraction of production incidents trace back to deferred maintenance: outdated dependencies with security issues, legacy code paths with insufficient test coverage, stale configuration that no longer reflects current infrastructure. Near-zero debt steady state addresses the root causes of this incident category.
• Enables compound improvement - A clean codebase is easier for both humans and agents to improve further; near-zero debt creates a positive feedback loop where quality improvements compound rather than being offset by accumulating debt

1. Measure current debt velocity - Before attempting to reach steady state, establish baseline metrics: debt items created per sprint, debt items resolved per sprint, net debt growth rate. Without this baseline, you cannot determine when you have reached steady state.
2. Achieve backlog clearance first - Near-zero steady state is not achievable while starting from a large accumulated backlog. The path to steady state runs through L3 and L4 backlog clearance. Ensure the inherited debt backlog is near-empty before targeting steady state maintenance.
3. Establish debt creation detection - Instrument the development workflow to detect debt creation: lint warnings in new code, deprecated API usage in new PRs, dependency bumps that immediately fall behind. These are the inputs to the maintenance agent's work queue.
4. Configure agents for proactive maintenance - Move from reactive debt resolution (agent addresses items from the inventory) to proactive maintenance (agent monitors for debt creation and addresses it before it enters the inventory). This requires agents with code review integration and continuous monitoring capabilities.
5. Set a debt age limit - Define a policy: no debt item older than 30 days in the codebase. Items older than 30 days that have not been addressed by an agent are escalated to human review. The 30-day limit prevents steady state from silently degrading into a slow-growth backlog.
6. Review steady-state metrics monthly - Track debt inventory size, debt age distribution, and agent PR merge rate. If the inventory is growing, the agent's output rate needs to increase or the debt creation rate needs to decrease. Monthly review ensures the steady state is actually maintained, not assumed.

Declaring steady state before the backlog is clear. If the inherited debt backlog is not cleared first, "steady state" maintenance will be continuously overwhelmed by the historical backlog. The sequence matters: clear the backlog, then transition to maintenance mode.

Not accounting for drift in debt creation rate. A new framework release, a major refactoring effort, or a large new feature area can temporarily increase the debt creation rate above the agent's maintenance capacity. Monitor the debt age distribution regularly; if the 90th percentile age is growing, the maintenance capacity needs to increase.

Automating without human oversight. Near-zero steady state does not mean zero human oversight. The agent fleet requires periodic review: are the PRs it is generating correct? Are there categories of debt the agents are missing? Are there new patterns being created that the agents do not yet recognize as debt? Monthly human review of agent activity is the minimum viable oversight.

Treating all debt equally in steady state. Not all debt requires the same urgency. Security debt (CVE-exposed dependencies) should be addressed within hours, not within the standard 30-day limit. Architectural debt in rarely-touched code may safely have a longer limit than debt in hot-path code. The steady-state policy should have tier-based SLAs, not a single limit for all categories.

Letting test debt accumulate while fixing other debt types. Test debt - gaps in coverage created by new features, flaky tests that obscure signal, tests that verify implementation rather than behavior - is the debt type that most undermines the agent's own effectiveness. Agents that cannot validate their output reliably cannot operate at steady-state autonomy. Test debt must be a first-class target for the maintenance agents, not an afterthought.