A Technical Debt Glossary
A practical reference for the language of technical debt, AI-assisted development, software governance, architecture, continuity, security, diligence, and software ownership. The definitions are written for business leaders, founders, investors, and technical teams who need to talk about the same risks with the same vocabulary.
It includes the future cost of architecture, dependencies, documentation, ownership, deployment, knowledge, maintenance, security, and organizational decisions that make software harder to own.
Some technical debt reflects a rational tradeoff. The management task is to know which debt creates business exposure, which can wait, and which should be left alone.
AI coding risk
AI coding risk is the technical and business exposure created when AI-assisted software development produces systems faster than the organization can safely review, understand, secure, maintain, and govern them.
Why it matters: The risk may appear in code quality, dependencies, architecture, data flows, ownership, documentation, or continuity even when the generated software works.
AI shadow IT
AI shadow IT is the use of AI tools, AI services, or AI-built workflows outside an organization's normal approval, procurement, security, or governance process.
Why it matters: AI shadow IT can evolve into shadow software when employees begin creating applications, automations, integrations, or data workflows the business later depends on.
AI software risk
AI software risk is the broader business risk created when AI-assisted software introduces technical, security, ownership, dependency, documentation, continuity, or governance problems.
Why it matters: It includes security exposure, but it also includes problems a vulnerability scan cannot answer, such as maintainability, architecture fit, or key-person dependence.
AI technical debt
AI technical debt is future cost or fragility created when AI-assisted development produces code, architecture, dependencies, documentation gaps, knowledge gaps, or operating responsibilities that make software harder to understand, maintain, secure, or change later.
Why it matters: AI can compress the time between software creation and technical debt, allowing young systems to acquire risks once associated with much older software.
AI-assisted development
AI-assisted development is the use of generative AI tools to help design, write, explain, test, refactor, document, or maintain software. It can increase software production while also increasing the amount of code and context an organization must review, understand, and support.
Why it matters: The management question is whether review, documentation, architecture, security, and shared understanding can keep pace with the output.
AI-generated code
AI-generated code is software source code produced wholly or partly by a generative AI system in response to prompts, examples, existing code, or other context supplied by a user.
Why it matters: The important issue is not simply who or what wrote the code, but whether qualified people can explain, test, maintain, and safely change the result.
Architecture debt
Architecture debt is technical debt created when the structure of a software system no longer supports the needs placed on it. It can appear when early design decisions, shortcuts, or accumulated complexity make ordinary changes expensive or risky.
Why it matters: Architecture debt often becomes visible when product work slows, integrations become difficult, or teams avoid touching important parts of the system.
Architecture drift
Architecture drift is the gradual movement of a software system away from its intended or understood design as new features, integrations, dependencies, and local fixes accumulate.
Why it matters: Drift matters when the actual system becomes harder to explain than the diagrams, conventions, or assumptions the team uses to reason about it.
Bus factor
Bus factor is an informal measure of how many people could become unavailable before a project or system becomes difficult to continue. A bus factor of one means a single person holds knowledge or access the organization cannot easily replace.
Why it matters: In business terms, it is a practical indicator of key-person risk and software continuity.
Citizen development
Citizen development is software or automation created by employees outside a traditional software engineering role, often with low-code, no-code, or AI-assisted tools.
Why it matters: It can create valuable capability quickly, but the business still needs visibility, ownership, documentation, security, maintenance, and continuity once the software becomes important.
Citizen development risk
Citizen development risk is the exposure created when employees can build software faster than the organization can establish ownership, review, documentation, maintenance, security, and continuity around it.
Why it matters: The risk begins when useful experimentation becomes business infrastructure without a corresponding operating model.
Code debt
Code debt is technical debt located primarily in the implementation of software, such as duplication, excessive complexity, brittle logic, inconsistent patterns, or shortcuts that make future modifications harder.
Why it matters: Code debt matters when it raises the cost or risk of ordinary engineering work rather than simply offending a preferred coding style.
Code smell
A code smell is a visible pattern in source code that may indicate a deeper design, maintainability, or complexity problem. A smell is evidence to investigate, not proof that the code is wrong.
Why it matters: Good technical debt management distinguishes indicators from business consequence before deciding whether remediation is worthwhile.
Cognitive debt
Cognitive debt is the burden created when software requires too much undocumented context, mental reconstruction, or specialized memory to understand and modify safely.
Why it matters: A system can function correctly while still consuming excessive human attention because too much of its meaning lives in people's heads.
Configuration debt
Configuration debt is technical debt created by fragile, inconsistent, undocumented, or manually maintained configuration across environments, services, accounts, and deployments.
Why it matters: It becomes a business risk when the company cannot reproduce, explain, or safely recover the configuration required for important software to run.
Data debt
Data debt is accumulated difficulty caused by inconsistent, poorly documented, duplicated, low-quality, or hard-to-govern data and the systems that depend on it.
Why it matters: Data debt can increase reporting errors, integration cost, AI risk, and uncertainty about where important business information comes from or flows.
Dependency debt
Dependency debt is technical debt created by external libraries, APIs, platforms, vendors, services, or components that become outdated, unsupported, difficult to replace, poorly understood, or deeply embedded.
Why it matters: A dependency may create security risk, maintenance cost, vendor exposure, or continuity problems long after the original integration seemed convenient.
Deployment debt
Deployment debt is the accumulated risk and effort created by fragile, manual, poorly documented, or person-dependent release and recovery processes.
Why it matters: It often becomes visible when only one person can deploy safely, rollbacks are uncertain, or releases require undocumented steps.
Documentation debt
Documentation debt is the gap between what an organization needs to know about a software system and what has been recorded in a usable, durable form.
Why it matters: It includes architecture, operating procedures, dependencies, deployment, recovery, ownership, and important design decisions, not just comments in source code.
Generative AI technical debt
Generative AI technical debt is technical debt associated with software created, modified, or expanded using generative AI tools. It can include additional code volume, inconsistent abstractions, dependencies, thin documentation, review gaps, and reduced shared understanding.
Why it matters: It is a specific form of AI technical debt and can emerge very early in the life of a system.
Infrastructure debt
Infrastructure debt is technical debt in the environments, cloud resources, networks, build systems, deployment tooling, and operational foundations that software relies on.
Why it matters: It becomes costly when environments are difficult to reproduce, ownership is unclear, upgrades are deferred, or the infrastructure constrains product and security work.
Integration debt
Integration debt is the accumulated cost and fragility created when systems are connected through brittle interfaces, undocumented assumptions, duplicated transformations, or hard-to-replace point-to-point integrations.
Why it matters: The business may experience integration debt as outages, data inconsistency, vendor lock-in, or fear of changing one system because nobody knows what else will break.
Key-person risk
Key-person risk in software is the business exposure created when important technical knowledge, access, architecture, deployment, maintenance, or recovery capability is concentrated in one person.
Why it matters: The software can be technically healthy while the operating model remains fragile.
Knowledge debt
Knowledge debt is the accumulated gap between how much a software system depends on human understanding and how broadly that understanding is shared across the organization.
Why it matters: It grows when decisions are undocumented, ownership is concentrated, or new software is produced faster than people can absorb the context behind it.
Legacy code
Legacy code is source code inherited from an earlier period of a system's development that remains important but may be difficult to understand, test, change, or replace.
Why it matters: Legacy code is not automatically bad code. Its risk depends on maintainability, supportability, ownership, business importance, and the cost of future change.
Legacy code technical debt
Legacy code technical debt is the future maintenance cost carried inside older software because of accumulated decisions, outdated patterns, hard-to-replace dependencies, missing tests, weak documentation, or architecture that has become difficult to change.
Why it matters: The right response may be remediation, modernization, or leaving a stable system alone, depending on business consequence.
Legacy software
Legacy software is software that has remained in use long enough for age, technology choices, operating assumptions, vendor support, architecture, or accumulated history to affect how easily it can be maintained or replaced.
Why it matters: Legacy does not mean obsolete. A mature system can be stable and valuable if it is understood, supportable, and aligned with the business.
Maintainability
Maintainability is the degree to which software can be understood, corrected, adapted, tested, and extended with reasonable effort and confidence.
Why it matters: For business leaders, maintainability is ultimately about the cost and risk of future change.
Maintenance debt
Maintenance debt is accumulated work created when updates, repairs, upgrades, operational improvements, or routine care are repeatedly deferred.
Why it matters: It becomes visible when keeping the current system running consumes engineering capacity that the business expected to use for growth or new features.
Modern technical debt
Modern technical debt is technical debt that emerges in current software environments shaped by cloud services, APIs, rapid delivery, AI-assisted development, distributed ownership, and a growing number of external dependencies.
Why it matters: Its defining feature is often speed: software can acquire legacy-like ownership and maintenance problems while the codebase is still young.
Modernization
Modernization is the process of updating, restructuring, replacing, or replatforming software or its supporting infrastructure so that it better fits current business and technical needs.
Why it matters: Modernization should be driven by business consequence rather than age alone. Stable legacy software may be cheaper and safer to keep than to replace.
Observability debt
Observability debt is the accumulated difficulty of understanding what a running system is doing because logs, metrics, traces, alerts, or operational signals are incomplete, inconsistent, or hard to use.
Why it matters: Weak observability increases the time and uncertainty involved in diagnosing failures and can concentrate operational knowledge in a few people.
Operational debt
Operational debt is the accumulated burden created by fragile procedures, manual work, unclear responsibilities, weak recovery practices, and other operating conditions surrounding software.
Why it matters: Operational debt often explains why technically functional systems still create business continuity or staffing risk.
Ownership debt
Ownership debt is the risk created when responsibility for software, data, access, maintenance, deployment, documentation, or future decisions is unclear or concentrated in the wrong place.
Why it matters: A system can work perfectly while nobody is clearly accountable for keeping it safe and maintainable over time.
Platform debt
Platform debt is technical debt created when a core platform, framework, hosting environment, or technical foundation constrains the product because it is outdated, poorly understood, difficult to upgrade, or no longer aligned with business needs.
Why it matters: Platform debt can affect delivery speed, staffing, security, vendor choice, and the cost of future architecture decisions.
Process debt
Process debt is accumulated friction caused by development, review, release, documentation, ownership, or decision-making practices that no longer support the pace or complexity of the software organization.
Why it matters: Technical debt can persist because the process keeps recreating the same conditions even after individual code problems are repaired.
Prototype debt
Prototype debt is technical debt created when software built to test an idea or move quickly becomes production infrastructure without the architecture, documentation, testing, ownership, or operating practices expected of a long-lived system.
Why it matters: The prototype itself is not the problem. The risk appears when the business keeps scaling on assumptions that were meant to be temporary.
Refactoring
Refactoring is the restructuring of existing software to improve its internal design, readability, maintainability, or extensibility without intentionally altering its external behavior.
Why it matters: Refactoring can reduce some forms of technical debt, but it cannot by itself solve ownership, governance, continuity, staffing, or incentive problems.
Remediation
Remediation is the work performed to reduce or remove a technical risk, vulnerability, maintenance burden, or other identified problem.
Why it matters: Good remediation is prioritized by business consequence. Some findings deserve immediate action, some can wait, and some should be left alone.
Security debt
Security debt is the accumulated exposure created when security-related maintenance, upgrades, access controls, dependency updates, architecture improvements, or known risks are deferred.
Why it matters: Security debt overlaps with technical debt, but technical debt also includes maintainability, architecture, ownership, documentation, and continuity issues that may have no direct security finding.
Shadow IT
Shadow IT is technology used inside a company without going through the normal approval, procurement, security, or governance process.
Why it matters: Historically this might have meant an unauthorized spreadsheet or SaaS account. AI expands the pattern because employees can now create software as well as adopt it.
Shadow software
Shadow software is software created or assembled inside the business without the ownership, review, documentation, maintenance planning, or governance that would usually accompany a formal software project.
Why it matters: It often begins as a useful local solution and becomes a risk when other people, data, customers, or operations start depending on it.
Single developer dependency
Single developer dependency occurs when one developer becomes essential to the safe operation, maintenance, deployment, or understanding of a software system.
Why it matters: It is a specific form of key-person risk and a common source of continuity problems in small teams and founder-led products.
Software business continuity
Software business continuity is the ability of an organization to keep important software and software-dependent operations functioning when people, vendors, accounts, infrastructure, or services become unavailable.
Why it matters: It requires shared knowledge, managed access, usable documentation, recovery capability, and enough ownership to continue operating under stress.
Software governance
Software governance is the set of responsibilities, rules, decision practices, and oversight used to determine how software is created, acquired, reviewed, secured, maintained, changed, and retired.
Why it matters: Governance becomes more important as AI and citizen development allow software to appear across the organization faster than traditional engineering processes can absorb it.
Software risk assessment
A software risk assessment is a structured review of the technical and organizational conditions that could affect the reliability, security, maintainability, continuity, cost, or future value of software.
Why it matters: A technical debt audit is one form of software risk assessment focused on the burden and business consequences of owning software over time.
Technical debt
Technical debt is the future cost, friction, or risk created when software decisions make a system harder to understand, maintain, secure, change, or operate later.
Why it matters: Technical debt can exist in code, architecture, dependencies, documentation, testing, deployment, ownership, and the organizational practices surrounding software.
Technical debt assessment
A technical debt assessment is a structured evaluation of where technical debt exists, how it affects the business, which risks deserve attention, and which issues can safely remain in place.
Why it matters: The purpose is prioritization, not a search for perfect software.
Technical debt audit
A technical debt audit is a focused independent review of the software a business depends on, combining technical evidence with business context to identify where risk sits, what deserves attention, what can wait, and what does not need fixing.
Why it matters: TDA's audit reviews architecture, codebase health, dependencies, AI-assisted development patterns, security, documentation, ownership, deployment, and continuity.
Technical debt consulting
Technical debt consulting is professional advisory work that helps organizations understand, prioritize, manage, and reduce software risk across architecture, code, dependencies, governance, ownership, maintenance, and continuity.
Why it matters: It can include assessments, remediation roadmaps, architecture decisions, AI governance, vendor reviews, and ongoing senior technical judgment.
Technical due diligence
Technical due diligence is an independent evaluation of a company's software, architecture, engineering practices, dependencies, security, ownership, maintainability, and technical risk in support of an investment, acquisition, or major business decision.
Why it matters: For AI-assisted startups, diligence increasingly includes whether software production has outpaced the team's ability to understand and sustain what it has built.
Technical risk
Technical risk is the possibility that software, architecture, infrastructure, dependencies, engineering practices, or technical decisions could create negative business consequences.
Why it matters: Technical debt is one source of technical risk, but technical risk can also include immediate failures, security exposure, unsupported technology, or execution uncertainty.
Test debt
Test debt is the future cost and risk created when automated or repeatable testing is insufficient to give teams confidence that software behaves as expected after modifications.
Why it matters: Test debt becomes expensive when every release requires extensive manual verification or teams avoid improving code because they cannot predict what might break.
Unauthorized AI applications
Unauthorized AI applications are internal apps, automations, workflows, or integrations created with AI-assisted tools outside the organization's normal review or approval process.
Why it matters: The software may be useful, but the company can still lack visibility into data flows, dependencies, credentials, ownership, maintenance, and continuity.
Vendor dependency
Vendor dependency is reliance on an external provider, service, platform, API, or product that is important to the operation or evolution of software.
Why it matters: The dependency becomes risky when replacement is difficult, ownership is unclear, the business lacks an exit path, or the vendor controls critical data or operating knowledge.
Vibe coding
Vibe coding is a loose term for building software through conversational or iterative interaction with AI coding tools, often by describing desired behavior and refining generated results through prompts.
Why it matters: Inside a business, the management issue begins when the resulting software becomes important enough to require ownership, review, documentation, security, maintenance, and continuity.
Vulnerability scan
A vulnerability scan is an automated or semi-automated examination of software, systems, or dependencies for known security weaknesses and other detectable security conditions.
Why it matters: A clean vulnerability scan does not answer whether software is maintainable, well owned, documented, architecturally sound, or recoverable.
Know what the terms mean. Then find out which ones matter to the business.
A focused Technical Debt Audit connects software evidence to business consequence across architecture, codebase health, dependencies, AI-assisted development, security, documentation, ownership, deployment, maintainability, and continuity.