ai-research-survey

scan.json (32623B)

---

 {
   "paper": {
     "title": "DynaFix: Iterative Automated Program Repair Driven by Execution-Level Dynamic Information",
     "authors": [
       "Zhili Huang",
       "Ling Xu",
       "Chao Liu",
       "Weifeng Sun",
       "Xu Zhang",
       "Yan Lei",
       "Meng Yan",
       "Hongyu Zhang"
     ],
     "year": 2025,
     "venue": "arXiv preprint",
     "arxiv_id": "2512.24635",
     "doi": "10.48550/arXiv.2512.24635"
   },
   "scan_version": 3,
   "active_modules": ["experimental_rigor", "data_leakage"],
   "methodology_tags": ["benchmark-eval"],
   "key_findings": "DynaFix integrates execution-level dynamic information (variable states, control-flow paths, call stacks) into an iterative LLM-based program repair workflow, repairing 186 single-function bugs on Defects4J — 17 more than the next-best baseline (GIANTREPAIR) and 38 uniquely fixed bugs. The Layered Progressive Repair (LPR) strategy reduces maximum patch attempts to 35 per bug (70% fewer than the most efficient baseline), while ablation shows LPR contributes the most (−21.9% fix rate without it) and execution-level info adds complementary value over coarse exception messages.",
   "checklist": {
     "artifacts": {
       "code_released": {
         "applies": true,
         "answer": false,
         "justification": "The paper states 'we will release a replication package including the DynaFix framework, the ByteTrace tool, and all experimental datasets upon acceptance' and 'will be made publicly available upon acceptance of the paper.' This is a promise of future release, not an actual release."
       },
       "data_released": {
         "applies": true,
         "answer": true,
         "justification": "The evaluation uses the publicly available Defects4J benchmark (v1.2, v2.0, and v3.0), which is a standard public dataset that was not modified by the authors."
       },
       "environment_specified": {
         "applies": true,
         "answer": false,
         "justification": "The paper mentions ByteTrace is implemented in Java and the core repair logic in Python, but provides no requirements.txt, Dockerfile, library versions, or environment setup details."
       },
       "reproduction_instructions": {
         "applies": true,
         "answer": false,
         "justification": "No step-by-step reproduction instructions are provided. The replication package is promised upon acceptance but not available."
       }
     },
     "statistical_methodology": {
       "confidence_intervals_or_error_bars": {
         "applies": true,
         "answer": false,
         "justification": "All results are reported as point estimates (e.g., '186 bugs', '42.6%') with no confidence intervals, error bars, or uncertainty quantification."
       },
       "significance_tests": {
         "applies": true,
         "answer": false,
         "justification": "The paper claims DynaFix 'outperforms' 11 baselines based solely on comparing raw counts of fixed bugs. No statistical significance tests (t-tests, Mann-Whitney U, etc.) are performed for any comparison."
       },
       "effect_sizes_reported": {
         "applies": true,
         "answer": true,
         "justification": "The paper reports improvements with baseline context throughout: '14 more than GIANTREPAIR', '39 more bugs than RepairAgent (an improvement of 26.5%)', '+27.7% improvement over Pure LLM', and similar contextual comparisons in Tables 1-3."
       },
       "sample_size_justified": {
         "applies": true,
         "answer": false,
         "justification": "No justification for the sample size (483 single-function bugs). The paper adopts the Defects4J benchmark as given without discussing whether the bug count is sufficient for the comparative claims made."
       },
       "variance_reported": {
         "applies": true,
         "answer": false,
         "justification": "No variance, standard deviation, or spread measures are reported across experimental runs. Results appear to be from a single run despite using temperature=1.0, which produces non-deterministic outputs."
       }
     },
     "evaluation_design": {
       "baselines_included": {
         "applies": true,
         "answer": true,
         "justification": "The paper compares against 11 SOTA APR systems covering 4 paradigms: 5 LLM-based (FitRepair, Repilot, GAMMA, AlphaRepair, GIANTREPAIR), 4 deep learning-based (ITER, SelfAPR, Tare, KNOD), 1 template-based (TBar), and 1 agent-based (RepairAgent)."
       },
       "baselines_contemporary": {
         "applies": true,
         "answer": true,
         "justification": "Baselines include recent work: RepairAgent (ICSE 2025), GIANTREPAIR (TOSEM 2025), FitRepair (ASE 2023), GAMMA (ASE 2023), Tare (ICSE 2023), and KNOD (ICSE 2023). These represent the current state of the art in APR."
       },
       "ablation_study": {
         "applies": true,
         "answer": true,
         "justification": "RQ4 (Section 5.4, Table 3) presents a systematic ablation study removing individual components: local variables, control flow, method calls, and the LPR strategy, showing each component's contribution."
       },
       "multiple_metrics": {
         "applies": true,
         "answer": true,
         "justification": "The paper uses multiple metrics: number of correct patches (manually verified), number of plausible patches (test-passing), fix rate, unique fixes, and maximum patch attempts per bug (efficiency metric)."
       },
       "human_evaluation": {
         "applies": true,
         "answer": true,
         "justification": "Section 3.3 states 'we further conduct manual inspection of test-passing patches to assess whether they are semantically equivalent to the developer's fix.' RQ1 results are based on manually verified correct patches."
       },
       "held_out_test_set": {
         "applies": true,
         "answer": false,
         "justification": "RQ3 tunes hyperparameters (breadth=7, depth=5) on 255 single-function bugs from Defects4J v1.2, but the final RQ1 results include these same v1.2 bugs. The hyperparameter selection data is not held out from the evaluation."
       },
       "per_category_breakdown": {
         "applies": true,
         "answer": true,
         "justification": "Table 1 provides per-project breakdowns (Chart, Closure, Lang, Math, Time, Mockito) and separate results for v1.2 and v2.0. Table 2 breaks down by single-function vs multi-function bugs."
       },
       "failure_cases_discussed": {
         "applies": true,
         "answer": false,
         "justification": "The paper shows examples where DynaFix succeeds (Listings 1-3) and discusses motivation cases, but provides no systematic analysis of where DynaFix fails or what bug types it cannot handle."
       },
       "negative_results_reported": {
         "applies": true,
         "answer": true,
         "justification": "Table 2 reports that for multi-function bugs, exception messages (18 fixes) outperform execution-level information alone (15 fixes). RQ3 reports diminishing returns beyond breadth 7 and depth 5. These are honestly reported negative findings."
       }
     },
     "claims_and_evidence": {
       "abstract_claims_supported": {
         "applies": true,
         "answer": true,
         "justification": "Abstract claims are supported: '186 single-function bugs' (Table 1), '10% improvement' (186 vs 169 GIANTREPAIR = 10.1%), '38 bugs previously unrepaired' (Figure 4b), 'at most 35 attempts' (Figure 7), '70% reduction' (35 vs 117 = 70.1%). All numbers check out."
       },
       "causal_claims_justified": {
         "applies": true,
         "answer": true,
         "justification": "The paper makes causal claims ('DynaFix enables more effective bug localization', 'removing LPR reduces fix rate'). The ablation study (RQ4) uses controlled single-variable manipulation, and RQ2 isolates the effect of dynamic information from iteration by comparing four conditions with the same LLM."
       },
       "generalization_bounded": {
         "applies": true,
         "answer": false,
         "justification": "The title 'Iterative Automated Program Repair' and conclusion claim 'integrating execution-level feedback into automated repair can better align with real-world debugging practices' frame results broadly, but evaluation is limited to Java bugs in Defects4J only. The threats section acknowledges 'our evaluation is limited to Java programs' but this caveat doesn't appear in the title, abstract, or conclusion."
       },
       "alternative_explanations_discussed": {
         "applies": true,
         "answer": true,
         "justification": "RQ2 controls for the LLM (same GPT-4o across all conditions) to separate the effect of dynamic info from iteration. The threats section discusses data leakage as an alternative explanation, and the paper tests robustness with DeepSeek to address model-specific bias. They also note GIANTREPAIR uses 4 models while DynaFix uses 1."
       },
       "proxy_outcome_distinction": {
         "applies": true,
         "answer": true,
         "justification": "The paper measures plausible patches (test-passing) and correct patches (manually verified semantic equivalence to developer fix). It clearly distinguishes between these two levels and explains why both are needed (Section 3.3, Section 4.3). Claims match measurement granularity."
       }
     },
     "setup_transparency": {
       "model_versions_specified": {
         "applies": true,
         "answer": false,
         "justification": "The paper states 'We used GPT-4o as the underlying LLM, accessed via the OpenAI API' without specifying a snapshot date or API version (e.g., 'gpt-4o-2024-05-13'). For the robustness check, only 'DeepSeek model' is named without version."
       },
       "prompts_provided": {
         "applies": true,
         "answer": false,
         "justification": "Figure 3 shows the 'Structure of the hierarchical prompt template' but states 'code details are omitted.' The actual prompt text is described in natural language (Section 3.2) without providing the full prompts used in experiments."
       },
       "hyperparameters_reported": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.4 reports: temperature=1.0, max 35 candidate patches per bug, breadth=7, depth=5, 30-minute timeout per repair attempt. Key hyperparameters are documented."
       },
       "scaffolding_described": {
         "applies": true,
         "answer": true,
         "justification": "The iterative repair scaffolding is described in detail: ByteTrace instrumentation (Section 3.1), structured prompt construction (Section 3.2), automated patch validation (Section 3.3), and the LPR strategy with Algorithm 1 (Section 3.4). Figure 2 provides an architectural overview."
       },
       "data_preprocessing_documented": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 documents the bug selection: 835 bugs in Defects4J v2.0, 5 removed leaving 830, classified into 483 single-function and 347 multi-function bugs following prior work. Section 5.1.1 describes normalization: 'retaining only the 483 single-function bugs selected in this study.'"
       }
     },
     "limitations_and_scope": {
       "limitations_section_present": {
         "applies": true,
         "answer": true,
         "justification": "Section 6 'Threats to Validity' is a dedicated section discussing internal and external validity threats across multiple paragraphs."
       },
       "threats_to_validity_specific": {
         "applies": true,
         "answer": true,
         "justification": "The threats section discusses study-specific issues: manual patch evaluation subjectivity, potential data leakage from GPT-4o training overlap with Defects4J, using reported baselines instead of re-running, reliance on a single LLM, and Java-only evaluation."
       },
       "scope_boundaries_stated": {
         "applies": true,
         "answer": true,
         "justification": "The paper states specific scope boundaries: 'our evaluation is limited to Java programs' and 'Extending evaluation to multiple programming languages is a promising direction.' It also acknowledges reliance on a single LLM and provides a DeepSeek robustness check."
       }
     },
     "data_integrity": {
       "raw_data_available": {
         "applies": true,
         "answer": false,
         "justification": "All experimental data (patches, execution traces, validation results) are promised 'upon acceptance' but not currently available. Only aggregated results in tables and figures are provided."
       },
       "data_collection_described": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 describes the Defects4J benchmark in detail: 835 real-world bugs from 17 open-source repositories, latest update removes 5 bugs, classification into single-function (483) and multi-function (347) bugs."
       },
       "recruitment_methods_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. The data source is Defects4J, a standard benchmark."
       },
       "data_pipeline_documented": {
         "applies": true,
         "answer": true,
         "justification": "The pipeline from bug selection to results is documented: Defects4J bugs → perfect fault localization → ByteTrace instrumentation → LLM patch generation → test validation → manual inspection. Each stage is described in Sections 3.1-3.4 and 4.2-4.4."
       }
     },
     "conflicts_of_interest": {
       "funding_disclosed": {
         "applies": true,
         "answer": false,
         "justification": "No funding sources, grants, or acknowledgments section appears in the paper. University researchers typically receive some form of funding, but none is disclosed."
       },
       "affiliations_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "All authors list their affiliation as Chongqing University, China. They are not evaluating a product from their own institution, so no conflict arises from the affiliations."
       },
       "funder_independent_of_outcome": {
         "applies": true,
         "answer": false,
         "justification": "No funding is disclosed, so independence of the funder cannot be assessed. The paper evaluates GPT-4o (OpenAI product) but the authors have no disclosed relationship with OpenAI."
       },
       "financial_interests_declared": {
         "applies": true,
         "answer": false,
         "justification": "No competing interests statement or financial disclosure appears in the paper."
       }
     },
     "contamination": {
       "training_cutoff_stated": {
         "applies": true,
         "answer": false,
         "justification": "The paper does not state GPT-4o's training data cutoff date. They discuss data leakage in the threats section but never specify when the model's training data was collected."
       },
       "train_test_overlap_discussed": {
         "applies": true,
         "answer": true,
         "justification": "Section 6 discusses overlap: 'the LLM may have been trained on open-source repositories partially overlapping with Defects4J.' They cite prior work [18] suggesting limited impact and evaluate on 24 Defects4J v3.0 bugs as mitigation."
       },
       "benchmark_contamination_addressed": {
         "applies": true,
         "answer": true,
         "justification": "The paper discusses contamination risk: 'Prior work [18] suggests such overlap has limited impact on APR, since training corpora rarely contain complete bug–fix pairs.' They evaluate on Defects4J v3.0 bugs 'which were not included in prior benchmarks' as concrete mitigation, finding DynaFix fixes 9/24 vs 2/24 for pure LLM."
       }
     },
     "human_studies": {
       "pre_registered": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. This is a benchmark evaluation of an automated program repair tool."
       },
       "irb_or_ethics_approval": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. The study evaluates software on public benchmarks."
       },
       "demographics_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants."
       },
       "inclusion_exclusion_criteria": {
         "applies": false,
         "answer": false,
         "justification": "No human participants."
       },
       "randomization_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants."
       },
       "blinding_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants."
       },
       "attrition_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants."
       }
     },
     "cost_and_practicality": {
       "inference_cost_reported": {
         "applies": true,
         "answer": false,
         "justification": "The paper reports maximum patch attempts (35 per bug) and 30-minute timeouts, and discusses 'token-based billing model' as a concern, but never reports actual API costs, tokens consumed, or dollar amounts per bug repair."
       },
       "compute_budget_stated": {
         "applies": true,
         "answer": false,
         "justification": "No total computational budget is stated. The paper mentions 30-minute per-attempt limits but does not report total GPU hours, total API spend, or hardware used for the experiments."
       }
     },
     "experimental_rigor": {
       "seed_sensitivity_reported": {
         "applies": true,
         "answer": false,
         "justification": "No mention of multiple random seeds or seed sensitivity analysis. The temperature is set to 1.0 (non-deterministic), but all results appear to be from a single run."
       },
       "number_of_runs_stated": {
         "applies": true,
         "answer": false,
         "justification": "The number of experimental runs is never stated. It appears results are from a single run, but this is not explicitly confirmed."
       },
       "hyperparameter_search_budget": {
         "applies": true,
         "answer": false,
         "justification": "RQ3 explores different breadth (1-10) and depth (1-10) configurations in Figure 6, but does not report the total compute spent on this hyperparameter search. Only the resulting performance curves are shown."
       },
       "best_config_selection_justified": {
         "applies": true,
         "answer": true,
         "justification": "RQ3 (Section 5.3, Figure 6) shows performance and cost trade-offs across configurations. The paper transparently selects breadth=7 and depth=5 based on diminishing returns analysis: 'Beyond breadth 7 or depth 5, the search has already covered most high-quality patches.'"
       },
       "multiple_comparison_correction": {
         "applies": true,
         "answer": false,
         "justification": "The paper compares against 11 baselines but performs no statistical tests at all, let alone corrections for multiple comparisons. All claims of superiority are based on raw count comparisons."
       },
       "self_comparison_bias_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The paper uses reported baseline results rather than re-implementing them, which they acknowledge in threats. However, they do not discuss the bias of evaluating their own system or the systematic advantage that authors have in tuning their own approach."
       },
       "compute_budget_vs_performance": {
         "applies": true,
         "answer": false,
         "justification": "Figure 7 compares maximum patch attempts across methods but does not report performance as a function of matched compute budgets. DynaFix's 35 attempts involve richer per-attempt computation (ByteTrace instrumentation + longer prompts) than baselines' simpler attempts, making the comparison non-equivalent."
       },
       "benchmark_construct_validity": {
         "applies": true,
         "answer": false,
         "justification": "The paper uses Defects4J as a standard benchmark without discussing whether it measures real-world bug repair capability. No discussion of construct validity, benchmark limitations, or comparison with alternative benchmarks."
       },
       "scaffold_confound_addressed": {
         "applies": true,
         "answer": false,
         "justification": "Cross-system comparisons pit DynaFix (GPT-4o + ByteTrace + LPR) against baselines using different models and scaffolds (e.g., GIANTREPAIR uses 4 LLMs). While the ablation (RQ4) separates internal components, the main comparison conflates scaffold and model differences across systems."
       }
     },
     "data_leakage": {
       "temporal_leakage_addressed": {
         "applies": true,
         "answer": true,
         "justification": "The paper discusses that GPT-4o may have been trained on Defects4J code and evaluates on 24 Defects4J v3.0 bugs 'newly introduced' and 'not included in prior benchmarks' as a temporal mitigation. DynaFix repaired 9/24 vs 2/24 for pure LLM."
       },
       "feature_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The paper uses perfect fault localization (Section 4.4) but does not discuss whether this or other evaluation features (e.g., test suite information provided to the model) constitute feature leakage relative to real-world usage."
       },
       "non_independence_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether bugs from the same Defects4J project share structural similarities that could violate independence assumptions. Bugs from the same repository may have correlated patterns."
       },
       "leakage_detection_method": {
         "applies": true,
         "answer": false,
         "justification": "No concrete leakage detection method (canary strings, membership inference, n-gram overlap) is applied. The v3.0 evaluation provides some temporal mitigation but is not a systematic detection method and covers only 24 bugs."
       }
     }
   },
   "claims": [
     {
       "claim": "DynaFix repairs 186 single-function bugs on Defects4J, exceeding all 11 SOTA baselines including 38 bugs uniquely fixed.",
       "evidence": "Table 1 shows 186 total (100 on v1.2, 86 on v2.0). Figure 4(b) shows 38 unique fixes across all baselines. GIANTREPAIR is next at 169.",
       "supported": "moderate"
     },
     {
       "claim": "Execution-level dynamic information provides greater benefit than exception messages for single-function bugs when used without iteration.",
       "evidence": "Table 2 shows 24.2% fix rate with execution-level info vs 18.6% with exception info for single-function bugs. However, for multi-function bugs, exception info (5.2%) outperforms execution-level (4.3%).",
       "supported": "moderate"
     },
     {
       "claim": "The iterative mechanism is crucial for exploiting the value of dynamic information, more than doubling performance.",
       "evidence": "Table 2: DynaFix (iterative + dynamic info) achieves 42.6% vs execution-level info alone at 24.2% for single-function bugs. For multi-function: 8.9% vs 4.3%. Single-run results without statistical testing.",
       "supported": "moderate"
     },
     {
       "claim": "DynaFix requires only 35 patch attempts per bug, reducing the search space by over 70% compared to the most efficient baseline.",
       "evidence": "Figure 7 shows DynaFix at 35 attempts vs RepairAgent at 117 (70.1% reduction). Most baselines require 500-5,000 attempts. The comparison is straightforward as the metric is clearly defined.",
       "supported": "strong"
     },
     {
       "claim": "The LPR strategy contributes the most to DynaFix's effectiveness, with the largest ablation impact.",
       "evidence": "Table 3 ablation study: removing LPR drops fix rate by 21.9% (111→55 plausible patches), far more than removing any single dynamic info type (3.5-5.5% drop each).",
       "supported": "moderate"
     },
     {
       "claim": "DynaFix generalizes to previously unseen bugs on Defects4J v3.0.",
       "evidence": "Section 6 reports DynaFix repairs 9/24 multi-function v3.0 bugs vs 2/24 for pure LLM. Very small sample size (24 bugs), no baselines compared on this set, and 9/24 is a modest rate.",
       "supported": "weak"
     }
   ],
   "red_flags": [
     {
       "flag": "No statistical testing across 11 baseline comparisons",
       "detail": "All claims of superiority are based on comparing raw counts without significance tests, error bars, or multiple runs. With temperature=1.0 and non-deterministic outputs, single-run results may not be stable. A difference of 17 bugs (186 vs 169) over 483 could be within random variation."
     },
     {
       "flag": "Baseline results adopted from publications rather than re-run",
       "detail": "Section 4.4 states 'For all baseline APR systems, we directly adopt the official experimental results reported in their respective publications.' Different baselines may have been run under different conditions, model versions, and infrastructure, making direct comparison questionable."
     },
     {
       "flag": "Hyperparameters tuned on test data",
       "detail": "RQ3 selects optimal LPR parameters (breadth=7, depth=5) on Defects4J v1.2 (255 bugs), which are then included in the main RQ1 evaluation. The tuning set and the evaluation set overlap."
     },
     {
       "flag": "No model version specified for GPT-4o",
       "detail": "Only 'GPT-4o' is stated without a snapshot date. GPT-4o behavior changes across versions, and the specific version used could significantly affect results."
     },
     {
       "flag": "Single-run non-deterministic results",
       "detail": "Temperature is set to 1.0 for diversity, but no evidence of multiple runs. Non-deterministic LLM outputs at high temperature could produce substantially different results across runs."
     },
     {
       "flag": "Editing artifact in paper text",
       "detail": "Section 3.1 contains the text 'please say that which experimental result approves the balance' — an apparent instruction left from the drafting process, suggesting incomplete review before submission."
     },
     {
       "flag": "Non-equivalent patch attempt comparison",
       "detail": "Figure 7 compares DynaFix's 35 attempts against baselines' 117-5000 attempts, but DynaFix's per-attempt cost is higher (ByteTrace instrumentation + longer prompts with execution traces). The comparison of attempt counts does not equate to a fair compute-cost comparison."
     }
   ],
   "cited_papers": [
     {
       "title": "RepairAgent: An Autonomous, LLM-Based Agent for Program Repair",
       "authors": ["Islem Bouzenia", "Premkumar Devanbu", "Michael Pradel"],
       "year": 2025,
       "relevance": "Autonomous LLM agent for iterative program repair using dynamic prompts and a state machine, a direct baseline."
     },
     {
       "title": "Tracefixer: Execution trace-driven program repair",
       "authors": ["Islem Bouzenia", "Yangruibo Ding", "Kexin Pei", "Baishakhi Ray", "Michael Pradel"],
       "year": 2023,
       "arxiv_id": "2304.12743",
       "relevance": "Incorporates execution traces (local variable values, expected states) into APR during CodeT5 fine-tuning, a key related approach for dynamic information in repair."
     },
     {
       "title": "Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt",
       "authors": ["Chunqiu Steven Xia", "Lingming Zhang"],
       "year": 2024,
       "relevance": "Dialogue-driven iterative LLM repair (ChatRepair) using test failure feedback, a prominent baseline for conversational APR."
     },
     {
       "title": "The plastic surgery hypothesis in the era of large language models",
       "authors": ["Chunqiu Steven Xia", "Yifeng Ding", "Lingming Zhang"],
       "year": 2023,
       "relevance": "FitRepair: LLM-based APR with repair-oriented fine-tuning, one of the 11 baselines compared."
     },
     {
       "title": "Less training, more repairing please: revisiting automated program repair via zero-shot learning",
       "authors": ["Chunqiu Steven Xia", "Lingming Zhang"],
       "year": 2022,
       "relevance": "AlphaRepair: zero-shot LLM-based program repair baseline demonstrating LLMs' repair capabilities without fine-tuning."
     },
     {
       "title": "Teaching large language models to self-debug",
       "authors": ["Xinyun Chen", "Maxwell Lin", "Nathanael Schärli", "Denny Zhou"],
       "year": 2023,
       "arxiv_id": "2304.05128",
       "relevance": "Self-Debug: LLM self-debugging via chain-of-thought code explanations, relevant to iterative LLM-based repair approaches."
     },
     {
       "title": "Selfapr: Self-supervised program repair with test execution diagnostics",
       "authors": ["He Ye", "Matias Martinez", "Xiapu Luo", "Tao Zhang", "Martin Monperrus"],
       "year": 2022,
       "relevance": "Uses compiler and test diagnostics during self-supervised LLM training for APR, a baseline approach using dynamic signals in training."
     },
     {
       "title": "Hybrid Automated Program Repair by Combining Large Language Models and Program Analysis",
       "authors": ["Fengjie Li", "Jiajun Jiang", "Jiajun Sun", "Hongyu Zhang"],
       "year": 2025,
       "doi": "10.1145/3715004",
       "relevance": "GIANTREPAIR: strongest baseline, aggregates 4 LLM outputs with program analysis to reduce search space."
     },
     {
       "title": "Thinkrepair: Self-directed automated program repair",
       "authors": ["Xin Yin", "Chao Ni", "Shaohua Wang", "Zhenhao Li", "Limin Zeng", "Xiaohu Yang"],
       "year": 2024,
       "relevance": "Self-directed iterative APR approach using LLMs, representative of recent iterative repair strategies."
     },
     {
       "title": "Towards Effectively Leveraging Execution Traces for Program Repair with Code LLMs",
       "authors": ["Mirazul Haque", "Petr Babkin", "Farima Farmahinifarahani", "Manuela Veloso"],
       "year": 2025,
       "arxiv_id": "2505.04441",
       "relevance": "Systematically analyzes execution traces' potential in APR, demonstrating value for explaining failing test behaviors."
     },
     {
       "title": "Traced: Execution-aware pre-training for source code",
       "authors": ["Yangruibo Ding", "Benjamin Steenhoek", "Kexin Pei", "Gail Kaiser", "Wei Le", "Baishakhi Ray"],
       "year": 2024,
       "relevance": "Execution-aware pre-training that incorporates runtime traces into model training, related to dynamic information in code understanding."
     },
     {
       "title": "Impact of code language models on automated program repair",
       "authors": ["Nan Jiang", "Kevin Liu", "Thibaud Lutellier", "Lin Tan"],
       "year": 2023,
       "relevance": "Analyzes data leakage and overlap between LLM training data and APR benchmarks, cited for contamination discussion."
     },
     {
       "title": "Iter: Iterative neural repair for multi-location patches",
       "authors": ["He Ye", "Martin Monperrus"],
       "year": 2024,
       "relevance": "Iterative neural repair for multi-location bugs, a baseline approach for iterative program repair."
     },
     {
       "title": "Copiloting the copilots: Fusing large language models with completion engines for automated program repair",
       "authors": ["Yuxiang Wei", "Chunqiu Steven Xia", "Lingming Zhang"],
       "year": 2023,
       "relevance": "Repilot: combines LLMs with completion engines for APR, one of the 11 baselines compared."
     }
   ],
   "engagement_factors": {
     "practical_relevance": {
       "score": 2,
       "justification": "DynaFix proposes a usable APR approach for Java bugs, but requires ByteTrace setup, GPT-4o API access, and is not yet released."
     },
     "surprise_contrarian": {
       "score": 1,
       "justification": "Incremental improvement over existing APR methods; the insight that execution traces help is intuitive rather than surprising."
     },
     "fear_safety": {
       "score": 0,
       "justification": "No safety or security concerns — this is about fixing software bugs, not creating them."
     },
     "drama_conflict": {
       "score": 0,
       "justification": "No controversy or provocative claims; standard benchmark evaluation."
     },
     "demo_ability": {
       "score": 0,
       "justification": "No code, demo, or tool released; all artifacts are promised 'upon acceptance.'"
     },
     "brand_recognition": {
       "score": 1,
       "justification": "Uses GPT-4o (OpenAI) but the research lab (Chongqing University) is not widely known in the APR community."
     }
   }
 }