Technical Debt
A metaphor introduced by Ward Cunningham in 1992 describing the technical compromises development teams make to accelerate short-term delivery, which accumulate into additional maintenance and modification costs over time.
Core Facts
The concept of technical debt was proposed by Ward Cunningham in 1992, referring to the long-term maintenance costs that accumulate when suboptimal solutions are chosen for the sake of short-term delivery speed.
The concept of Technical Debt was first proposed by Ward Cunningham in 1992.
技术债务（Technical Debt）概念由Ward Cunningham在1992年提出，用于描述为了短期交付而采用的次优方案所积累的隐性成本
Timeline (last 90 days)
AI slop is seen as a new form of technical debt that speeds up delivery in the short term while eroding codebase maintainability and team trust in the long term.
Staying on an old version for a long time accumulates two kinds of technical debt: security debt (no patches for new vulnerabilities) and compatibility debt (multiple versions' breaking changes must be handled all at once during a future upgrade).
A large-scale empirical study on technical debt introduced by AI coding assistants, built on a dataset of 302,600 verified AI-authored commits from 6,299 repositories, found that 22.7% of tracked AI-introduced issues were still present in the latest repository versions.
This pattern does not provide unlimited backward compatibility; one needs to decide the time window for accepting old versions and when to remove the adaptation logic, which is technical debt that must be actively managed.
An organization's technical debt exists not only in the code, but also at the repository and permission levels.
The industry usually divides technical debt into four categories: deliberate and prudent, deliberate and reckless, inadvertent and prudent, and inadvertent and reckless.
Common means of measuring technical debt include code complexity metrics (such as cyclomatic complexity), duplicate code rate, the degree of version lag in dependency libraries, test coverage, and the more business-oriented delivery lead time and change failure rate.
Unreviewed solutions become the norm, the subtle bugs and vulnerabilities introduced spread in production environments, AI-generated security protocols may hide flaws, technical debt accumulates, and the quality feedback loop breaks.
Lines of code (LOC) itself is not a reliable proxy metric for technical debt, and a concise implementation may also hide deep coupling.
"Cognitive debt" is an approximate term in software engineering research for the phenomenon of "code growing faster than understanding," distinguished from technical debt: technical debt concerns code quality and maintenance costs, while cognitive debt concerns whether the team's mental model of the system is complete.
10 more timeline events
All Facts (20)
The concept of technical debt was proposed by Ward Cunningham in 1992, referring to the long-term maintenance costs that accumulate when suboptimal solutions are chosen for the sake of short-term delivery speed.
85%VerifiedThe concept of Technical Debt was first proposed by Ward Cunningham in 1992.
80%Verified技术债务（Technical Debt）概念由Ward Cunningham在1992年提出，用于描述为了短期交付而采用的次优方案所积累的隐性成本
80%VerifiedTechnical debt refers to the compromises made in code quality and architectural design in pursuit of short-term delivery speed, which will be repaid in the future at a higher cost of maintenance and refactoring.
75%VerifiedWhen the cost of producing code approaches zero, AI-generated code that 'looks plausible but contains subtle defects' is often harder to detect than obvious errors in human-written code.
65%VerifiedThe metaphor of 'technical debt' was proposed by Ward Cunningham, comparing the practice of sacrificing code quality for short-term delivery speed to taking out a loan.
65%UnverifiedSonarQube等工具已将技术债务量化为修复所需工时
90%Unverified嵌入式产品一旦出货，OTA升级能力有限，线上修复的窗口极为狭窄，技术债务的代价远高于互联网软件
85%Unverified硬编码模型名称在代码中会导致切换模型时需要全量代码扫描、回归测试和重新部署
85%Unverified在Vibe Coding模式下，技术债务以指数而非线性速度增长，因为开发者不读代码、AI不会主动重构
75%UnverifiedAI Agent时代的技术债出现新形态：用低代码或自然语言快速搭建的自动化流程往往缺乏清晰的错误处理、权限边界和可观测性设计
75%UnverifiedAI slop is seen as a new form of technical debt that speeds up delivery in the short term while eroding codebase maintainability and team trust in the long term.
50%UnverifiedStaying on an old version for a long time accumulates two kinds of technical debt: security debt (no patches for new vulnerabilities) and compatibility debt (multiple versions' breaking changes must be handled all at once during a future upgrade).
50%UnverifiedA large-scale empirical study on technical debt introduced by AI coding assistants, built on a dataset of 302,600 verified AI-authored commits from 6,299 repositories, found that 22.7% of tracked AI-introduced issues were still present in the latest repository versions.
50%UnverifiedThis pattern does not provide unlimited backward compatibility; one needs to decide the time window for accepting old versions and when to remove the adaptation logic, which is technical debt that must be actively managed.
50%UnverifiedAn organization's technical debt exists not only in the code, but also at the repository and permission levels.
50%UnverifiedThe industry usually divides technical debt into four categories: deliberate and prudent, deliberate and reckless, inadvertent and prudent, and inadvertent and reckless.
50%UnverifiedCommon means of measuring technical debt include code complexity metrics (such as cyclomatic complexity), duplicate code rate, the degree of version lag in dependency libraries, test coverage, and the more business-oriented delivery lead time and change failure rate.
50%UnverifiedUnreviewed solutions become the norm, the subtle bugs and vulnerabilities introduced spread in production environments, AI-generated security protocols may hide flaws, technical debt accumulates, and the quality feedback loop breaks.
50%UnverifiedLines of code (LOC) itself is not a reliable proxy metric for technical debt, and a concise implementation may also hide deep coupling.
50%