Self-Admitted Technical Debt (SATD)
- Self-admitted technical debt (SATD) is the explicit documentation by developers of temporary, suboptimal implementations in code comments, issues, and commits.
- Detection methodologies range from simple fuzzy matching to sophisticated multi-source deep models, with studies reporting metrics like precision (up to 0.888) and recall (around 0.65).
- Empirical findings strongly link SATD with increased maintenance challenges, including higher bug rates, reduced readability, and extended resolution times.
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 (Li et al., 2022, Xavier et al., 2020).
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 (Li et al., 2022).
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 (Xavier et al., 2020). 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 (Xavier et al., 2024). 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 (Li et al., 2022, Li et al., 2023). 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” | (Maipradit et al., 2020) |
| Maven build systems | Rationale organized by location, reason, and purpose; limitations in tools/libraries account for 50%, dependency issues for 24% | (Xiao et al., 2021) |
| Data-access code | Taxonomy extended with 15 new SATD categories, 11 specific to database access operations such as query construction, transactions, indexes, and synchronization | (Muse et al., 2022) |
| ML software | Two new categories identified: configuration debt and inadequate tests | (Bhatia et al., 2023) |
| Test code | 15 categories, including 7 new test-specific ones such as How to, Skip test, Subset test, Superficial test, and Dependency | (Islam et al., 25 Oct 2025) |
| C++ comments with code context | Five-class scheme: Design/Code, Requirement, Defect, Test, Documentation, plus NON-SATD | (Pham et al., 2 May 2025) |
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 (Guo et al., 2019).
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 (Li et al., 2022). 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 (Li et al., 2022).
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 (Maipradit et al., 2020). 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 (Hai et al., 2024). Cross-language expansion is represented by CppSATD, which contains 531,367 annotated C++ comments with surrounding code context, including 13,069 SATD comments (Pham et al., 2 May 2025). 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 (AlOmar et al., 2021).
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
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 (Chowdhury et al., 2024).
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 (Chowdhury et al., 2024). 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) (Xavier et al., 2020). 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 (Li et al., 2023).
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 (Chowdhury et al., 2024). 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 (Maipradit et al., 2020). 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 (Xiao et al., 2021).
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 (Li et al., 2023). 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 (Xavier et al., 2024). 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 (Li et al., 2022).
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 (Chowdhury et al., 2024). 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 (Hai et al., 2024). 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 (Alhefdhi et al., 2020).
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 (Pham et al., 2 May 2025). 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 (Islam et al., 25 Oct 2025).
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 (Ferreyra et al., 2024). 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 (Yasmin et al., 2022).
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.
