Themis improves software repairs by tracing requirement changes visibly
Externalizing Requirement-to-Repair Artifacts as Observable Traces for LLM-Based Program Repair
Artificial IntelligenceSoftware Engineering
Summary
Fixing software bugs is easier when the reasons for changes and the changes themselves can be clearly seen and checked. The authors created a system called THEMIS that captures the entire process of turning bug reports into code fixes as a clear story. This helps developers understand why changes were made and review them at each step to catch mistakes. Their tests showed that this approach made it easier to track how decisions evolved and improved the repair process compared to simpler methods.
What this means in practice
- •For software development teams: Track and review code changes with clear explanations from issue report to patch during bug fixes.
- •For quality assurance engineers: Audit and verify software repairs with detailed records of requirements and code edits for better validation.
Authors
Zewen Tao, Shin-nosuke Ishikawa
Abstract
Repository-level repair requires not only correct patches but also inspectable records that explain how issue requirements are translated into code changes and post-edit evidence. We contribute THEMIS, a stage-aware repair workflow that externalizes this requirement-to-repair process through semantic interpretation, a runtime requirement-code graph, graph-derived Developer guidance, retained repair rationale and patches, and post-edit audit records. A retrospective audit of 300 SWE-bench Lite cases demonstrates that these artifacts provide broad support for cross-stage inspection: a complete Developer rationale is available for 288 cases, and 214 cases (71.3%) retain a complete audited field set connecting the selected stages. The retained records further enable systematic measurement of cross-stage correspondence: target symbols recur in 62.6% of Developer rationales and in 62.8% of patches, rising to 75.8% when related symbols are included. In a paired 100-case comparison, the relational workflow resolves 19 cases versus 9 for the direct same-input condition; because the two conditions also differ in Analyzer output, graph-derived distillation, and Judge records, we report this as preliminary, workflow-level evidence rather than a causal effect of the graph component. Together, these results show that THEMIS makes otherwise implicit requirement-to-repair transitions inspectable, enabling systematic examination of how repair decisions persist, align, and evolve across stages.