Technical Debt Item

Technical debt is invisible. Developers know the codebase has problems — brittle tests, copy-pasted logic, deprecated libraries — but none of it is written down. 'How much tech debt do we have?' is answered with a sigh and a vague hand wave. There is no inventory, no prioritization, and no way to make the case for addressing accumulated code quality issues.

None — AI cannot identify, prioritize, or recommend addressing technical debt items because no documentation of code quality issues exists.

Technical debt items exist as scattered TODO comments in code and occasional Jira tickets, but documentation is inconsistent. Some items have detailed descriptions of the problem and its impact; others say 'refactor this' with no context. There is no standard format, no consistent severity rating, and no way to assess the total scope of accumulated debt. 'How bad is our tech debt situation?' still gets answered with opinions, not facts.

AI can find TODO comments in code and read existing technical debt item tickets, but cannot assess total debt burden or prioritize remediation because the items lack consistent severity ratings, effort estimates, and impact assessments.

Technical debt items follow a standard template with required fields — problem description, affected modules, business impact, estimated effort, and severity. The debt inventory is maintained in the task tracker alongside feature work. Quarterly debt reviews assess the portfolio. But technical debt items are standalone records — they don't link to the production metrics they affect, the incidents they cause, or the velocity drag they create.

AI can rank technical debt items by severity and estimated effort, and generate a remediation roadmap. Cannot quantify the actual business cost of each technical debt item because debt records don't connect to production performance metrics or incident history.

Technical debt items are comprehensive records with quantified business impact. Each item links to affected production metrics, correlated incident history, and developer velocity impact. An engineering director can query 'show me all technical debt items affecting the API gateway, their annual incident cost, their velocity drag on the platform team, and the estimated ROI of remediation' and get a data-backed answer.

AI can compute remediation ROI by correlating technical debt items with incident costs and velocity impact. Can recommend prioritized remediation plans based on business value. Cannot yet auto-detect new technical debt items because detection criteria aren't formalized.

Technical debt items are formal entities with machine-readable detection rules, quantified remediation criteria, and structured relationships to the full engineering and business context. AI agents auto-detect new technical debt items when code complexity exceeds thresholds, dependencies age beyond policies, or test coverage drops below floors. Each detected item arrives with a pre-computed remediation ROI.

AI can autonomously detect, document, and prioritize technical debt items within the formal quality model. Can generate remediation plans for standard debt patterns. Human judgment is needed for architectural debt and strategic technical decisions.

Technical debt items are self-maintaining entities that auto-detect, auto-document, and auto-prioritize in real-time. New code quality issues surface automatically. Severity recalibrates from production incident patterns. Remediation ROI updates as business conditions change. The technical debt inventory is a living system that reflects the actual state of codebase health without manual debt audits.

Fully autonomous technical debt intelligence. AI detects, documents, prioritizes, and tracks remediation of all technical debt items in real-time based on production impact and business value.

Ceiling of the CMC framework for this dimension.