---
title: Self-Admitted Technical Debt (SATD)
url: https://www.emergentmind.com/topics/self-admitted-technical-debt-satd-bb7d79c7-1099-46ca-b845-433b73771c5a
type: topic
---

# Self-Admitted Technical Debt (SATD)

Searching arXiv for recent SATD papers to ground the article in the provided literature and related work.
Self-admitted technical debt (SATD) is the explicit acknowledgment by developers of technical debt in software artifacts, most classically in source code comments, but also in commit messages, pull requests, and issue trackers. In operational terms, SATD denotes developer-authored statements that a current implementation is temporary, incomplete, suboptimal, brittle, or in need of later cleanup, such as workarounds, postponed refactorings, missing tests, missing documentation, or partially implemented requirements. SATD research has moved from comment-centric identification toward a broader view in which the documentary location of the admission, the debt subtype, the surrounding code or artifact context, and the later maintenance consequences are all analytically significant [2202.02387][2003.09418].

## 1. Concept and documentary scope

The classical SATD setting is comment-based: developers leave inline notes such as `TODO`, `FIXME`, or equivalent reminders near code they regard as compromised or unfinished. This remains the dominant operationalization in much of the literature, but later work has shown that SATD is not confined to source code comments. Issue trackers, commit messages, and pull requests are also used to explicitly document debt, often with broader rationale, richer discussion, and stronger project-management affordances than comments alone [2202.02387].

A major extension is the distinction between **SATD-C**, documented in source code comments, and **SATD-I**, documented in issue trackers. The issue-based perspective matters because only **28.7%** of analyzed SATD-I cases in one study could be traced to comment-based SATD in deleted code comments associated with repayment, implying that comment-only mining misses a large share of explicitly documented debt [2003.09418]. This suggests that SATD is better understood as a multi-artifact socio-technical phenomenon than as a purely lexical property of comments.

The choice of documentary medium is not neutral. Later evidence indicates that comments are typically used when debt is local, low-priority, small-effort, or primarily useful as immediate code-reading context, whereas issues are preferred when debt requires discussion, tracking, visibility, or spans multiple code locations [2408.15109]. A plausible implication is that documentary location itself carries information about scope, urgency, and governance.

## 2. Taxonomies and domain specializations

Across studies, recurring SATD classes include **code/design debt**, **requirement debt**, **documentation debt**, **test debt**, and, in some taxonomies, **defect debt** [2202.02387][2309.06020]. However, the literature increasingly shows that these broad categories are insufficient for some artifacts and domains. Specialized settings expose debt forms that are hard to capture with a generic taxonomy.

| Context | Distinctive characterization | Citation |
|---|---|---|
| On-hold SATD | Debt whose removal is blocked by an external event; defined as debt “due to a waiting condition for an external event to happen before the technical debt can be removed” | [2009.13113] |
| Maven build systems | Rationale organized by **location**, **reason**, and **purpose**; limitations in tools/libraries account for **50%**, dependency issues for **24%** | [2102.09775] |
| Data-access code | Taxonomy extended with **15 new SATD categories**, **11** specific to database access operations such as query construction, transactions, indexes, and synchronization | [2201.02180] |
| ML software | Two new categories identified: **configuration debt** and **inadequate tests** | [2311.12019] |
| Test code | **15** categories, including **7** new test-specific ones such as **How to**, **Skip test**, **Subset test**, **Superficial test**, and **Dependency** | [2510.22409] |
| C++ comments with code context | Five-class scheme: **Design/Code**, **Requirement**, **Defect**, **Test**, **Documentation**, plus **NON-SATD** | [2505.01136] |

These domain-specific taxonomies refine rather than replace the generic SATD view. Build systems foreground tooling and dependency-management constraints; data-access code foregrounds persistence, transactions, and schema coupling; ML code foregrounds configuration and testing adequacy; test code foregrounds coverage, skipped execution, impractical scenarios, and uncertainty about how to test correctly. This suggests that SATD is artifact-sensitive and domain-sensitive: a stable core notion exists, but its concrete empirical shape depends strongly on the software artifact under study.

## 3. Detection, datasets, and tracking

SATD detection spans simple unsupervised baselines, supervised text classifiers, multi-source deep models, and comment-plus-code approaches. A notable baseline is **MAT**, which identifies SATD by fuzzy matching the task tags `TODO`, `FIXME`, `XXX`, and `HACK`. On 10 open-source Java projects, MAT achieved average **precision 0.888**, **recall 0.650**, and **F1 0.722** under many-to-one prediction, making it a strong low-complexity baseline for comment-level SATD identification [1910.13238].

Issue-tracker SATD requires different modeling choices because the unit of analysis is not the whole issue but the **issue section**. A dedicated issue-tracker study built a dataset of **23,180 issue sections** from **4,200 issues** across seven projects and optimized a Text CNN that achieved **precision 0.685**, **recall 0.689**, and **F1 0.686**; with transfer from a Jira sentiment dataset, the F1 rose slightly to **0.691** [2202.02180]. A broader multi-source study then integrated **source code comments, commit messages, pull requests, and issue tracking systems** with a multitask CNN and reported a final average **F1-score of 0.611** for four SATD types across the four sources [2202.02387].

Narrower semantic subclasses have also proven detectable. For **On-hold SATD**, a pipeline combining issue-reference detection, preprocessing, n-gram IDF features, and auto-sklearn achieved **Precision = 0.79**, **Recall = 0.70**, **F1-score = 0.73**, and **AUC = 0.97** on issue-referring comments [2009.13113]. This result is important because it shows that finer-grained, semantically coherent SATD subtypes can be modeled more directly than a single coarse SATD/non-SATD dichotomy.

Dataset construction has also become a research contribution in its own right. **TESORO** pairs SATD comments with the associated source code and shows that adding code context improves SATD detection, while code-only technical-debt detection remains difficult; the dataset contains **4,981** labeled comments and **1,255** code samples from **974** Java repositories [2411.05457]. Cross-language expansion is represented by **CppSATD**, which contains **531,367** annotated C++ comments with surrounding code context, including **13,069** SATD comments [2505.01136]. For longitudinal analyses, **SATDBailiff** shifts the problem from snapshot detection to history reconstruction, reporting **0.99** precision for SATD removals and **0.96** precision for SATD changes while tracking events such as `SATD_ADDED`, `SATD_REMOVED`, `SATD_CHANGED`, `FILE_PATH_CHANGED`, and `CLASS_OR_METHOD_CHANGED` across Git histories [2107.00073].

## 4. Maintenance impact and empirical consequences

A longstanding question in SATD research is whether SATD merely documents debt or whether it predicts measurable maintenance burden. The strongest evidence in the supplied literature comes from a method-level study of **774,051** Java methods from **49** open-source projects, including **33,711** SATD methods. Using a binary method-level SATD label and 14 method-level metrics, the study found that SATD-bearing methods are larger, more complex, more dependent, less readable, and less maintainable than methods that never contain SATD. The maintainability metric is reported as
\[
171 - 5.2 * \ln(Halstead\, V) - 0.23 * (McCabe) - 16.2 * \ln(Size).
\]
All 14 code-metric comparisons were statistically significant, and several effect sizes were large. Distributionally, **60%** of SATD methods had more than **10 LOC**, versus **20%** of non-SATD methods; the Maintainability Index exceeded **100** for **80%** of NOT-SATD methods but only **40%** of SATD methods [2411.13777].

The same study also found strong maintenance-outcome differences. For change proneness, more than **45%** of SATD methods were revised at least once, compared with only **20%** of NOT-SATD methods. For bug proneness, SATD methods had higher bug ratios under all three labeling schemes, including **0.396** versus **0.213** in the HighRecall dataset. For persistence, after excluding SATD methods younger than two years, more than **61%** of SATDs were never removed; among removed SATDs, **60%** took at least **100 days** and **20%** took more than **1000 days** to resolve [2411.13777]. Within the conditions studied, SATD is therefore not a benign annotation but a statistically strong marker of lower maintainability.

Issue-based debt shows a related pattern. In a study of **286** SATD-I instances, SATD-I issues took longer to close than other issues, with median closure time **16.7 days** versus **4.0 days**, and accumulated more comments (**5** versus **3**) and more labels (**3** versus **2**), although they did not require significantly larger code churn (**18** versus **20** added/deleted LOC) [2003.09418]. A separate large-scale repayment-effort study of **341,740** SATD items from **1,060** Apache repositories found that SATD repayment and non-SATD changes have similar direct effort, but SATD repayment produces more ripple-effect changes across all significance levels; **requirement debt**, **test debt**, and **code/design debt** require higher repayment effort than non-SATD items, whereas **documentation debt** requires less [2309.06020].

## 5. Repayment and management practices

SATD management research increasingly distinguishes between identification, prioritization, repayment timing, and the documentary medium chosen for debt. Persistence results already suggest why this matters: unresolved SATD often survives for months or years [2411.13777]. More specialized studies refine the picture. For **On-hold SATD**, the maintenance question is not only whether a comment exists, but whether the external blocking condition has already been satisfied. The operational rule is explicit: if the referred issue is **resolved**, **closed**, or **verified**, and the resolution is **fixed**, the On-hold SATD is considered ready for removal [2009.13113]. In build systems, a similar “ready-to-be-addressed” logic identified **16** actionable SATD instances; after notification, **3 of the 7 pull requests were merged** and **5 of the 9 issue-reported SATD instances were resolved within 20 days** [2102.09775].

Repayment estimation has also become a separate line of work. Text-based models trained on commit-message SATD descriptions show that repayment effort is not uniform across debt types. In the same large Apache study, **BERT** and **TextCNN** outperformed linear regression, random forest, support vector regression, and a naive baseline in predicting line-based, file-based, and significance-based repayment effort from SATD text [2309.06020]. This suggests that the natural-language description of debt carries usable signals about both local repair effort and ripple effects.

Where SATD should be documented is now treated as a management question rather than a mere data-source choice. Survey evidence over a large corpus of **74K SATD-C** and **20K SATD-I** instances yields **13 guidelines**: comments are preferred when debt provides context to the reader, has low priority, has local scope, requires small effort to fix, will be addressed soon, or appears in code that is frequently revisited; issues are preferred when the debt requires discussion, needs tracking, spans multiple places, requires visibility, has high priority, requires medium or large effort, or is suitable as a good first issue [2408.15109]. Many developers recommend using both, with traceability between TODO-like comments and the issue that tracks them.

An industrial embedded-systems case study reinforces this multi-source view. In that setting, **2.6%** of comments, **16.3%** of issues, and **12.7%** of commits were classified as SATD. Practitioners largely recognized automatically identified SATD as genuine, but emphasized that documentary location shapes visibility and actionability: issues support planning, prioritization, and cross-team visibility, while comments preserve code-local rationale and commits preserve change rationale. The same study reports practitioner demand for SATD traceability, prioritization, fixed-versus-unfixed differentiation, and repayment support rather than detection alone [2205.13872].

## 6. Limitations and research frontiers

A central limitation across the literature is observability. SATD is only the subset of technical debt that developers explicitly document. Debt may exist with no comment at all, may be mentioned only in commit messages or issues, or may remain as a stale comment after the underlying problem has disappeared [2411.13777]. This limitation motivates a broader shift from “debt in comments” to “debt in code and artifacts.” **TESORO** is an explicit response to this problem, pairing comments with the source code they refer to and showing that code context improves prediction; at the same time, code-only technical-debt detection remains far from solved [2411.05457]. **SATDID** pushes further by recommending whether hidden debt in conditional statements should be self-admitted and then generating a descriptive SATD comment, shifting the task from recognizing admissions to proposing them [2012.12466].

Generalizability is another recurring concern. Many large empirical studies are restricted to open-source Java systems. Cross-language work is therefore significant: **CppSATD** provides a C++ corpus with comment labels and surrounding code context, directly addressing the Java-centric bias of earlier SATD datasets [2505.01136]. Domain-specific research also shows that generic SATD assumptions do not transfer cleanly. In test code, a first dedicated study identified **615** SATD comments in **47,994** filtered test comments and built a taxonomy of **15** categories, **7** of them test-specific; existing detectors transferred only partially, with **MAT** the strongest traditional baseline at **F1 = 0.75** on the original dataset, while open-source and proprietary LLMs showed poor detection accuracy primarily because of low precision [2510.22409].

Several newer fronts show SATD broadening into adjacent research questions. A security-oriented mixed-methods study identified **201** security-related SATD instances out of **8,812** SATD items and mapped them to **25** CWE types, **8** of which appear in MITRE’s Top-25 most dangerous weaknesses, suggesting that SATD artifacts can also function as publicly visible security pointers [2401.12768]. Another study showed that SATD comments are often relational rather than isolated: **3,520** duplicate and near-duplicate SATD comments were found in **1,141** groups, and **484** of **500** sampled groups referred to the same root cause, implying that SATD management may require group-wise rather than comment-wise reasoning [2203.15979].

Taken together, these lines of work suggest that SATD is no longer adequately described as a niche problem of TODO-like comment classification. It has become a broader research area concerning explicit debt documentation across artifacts, domain-specific debt taxonomies, code-and-text multimodality, longitudinal tracking, repayment effort estimation, maintenance prediction, security exposure, and cross-language generalization. Within that broader frame, the consistent core insight remains that explicit developer admissions are empirically informative signals of future maintenance burden, but only when interpreted in the context of artifact type, code context, domain, and project workflow.

Source: https://www.emergentmind.com/topics/self-admitted-technical-debt-satd-bb7d79c7-1099-46ca-b845-433b73771c5a