ai-research-survey

scan.json (33769B)

---

 {
   "paper": {
     "title": "Input Reduction Enhanced LLM-based Program Repair",
     "authors": [
       "Boyang Yang",
       "Luyao Ren",
       "Xin Yin",
       "Jiadong Ren",
       "Haoye Tian",
       "Shunfu Jin"
     ],
     "year": 2025,
     "venue": "ICSE'26",
     "arxiv_id": "2507.15251",
     "doi": "10.48550/arXiv.2507.15251"
   },
   "scan_version": 3,
   "active_modules": [
     "experimental_rigor",
     "data_leakage"
   ],
   "methodology_tags": [
     "benchmark-eval"
   ],
   "key_findings": "ReduceFix combines LLM-generated test input reducers with the classical ddmin algorithm to shrink failure-inducing inputs by 89.1% on average, improving LLM-based program repair pass@10 by up to 53.8% on the authors' LFTBench benchmark. Full failing test inputs often hurt repair accuracy compared to no-test baselines, confirming the 'lost-in-the-middle' effect in APR prompts. The approach transfers as a drop-in plugin to ChatRepair (+21.3%) and CREF (+2.6%), and shows improvements on 12 OSS-Fuzz crash instances.",
   "checklist": {
     "artifacts": {
       "code_released": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.4 states 'the full artifact is published at https://github.com/GLEAM-Lab/ReduceFix' with an explicit URL."
       },
       "data_released": {
         "applies": true,
         "answer": true,
         "justification": "LFTBench and LFTBench-Py are described as part of the published artifact at the GitHub repository. The benchmark is constructed from publicly available AtCoder contest data."
       },
       "environment_specified": {
         "applies": true,
         "answer": false,
         "justification": "No requirements.txt, Dockerfile, conda environment file, or detailed environment setup listing library versions is mentioned in the paper. Only model names and hyperparameters are provided."
       },
       "reproduction_instructions": {
         "applies": true,
         "answer": false,
         "justification": "The paper provides a GitHub URL for the artifact but does not include step-by-step reproduction instructions, README commands, or a 'Reproducing Results' section within the paper itself."
       }
     },
     "statistical_methodology": {
       "confidence_intervals_or_error_bars": {
         "applies": true,
         "answer": false,
         "justification": "All results in Tables 3–13 are point estimates (pass@k percentages, compression rates) with no confidence intervals, error bars, or ± notation."
       },
       "significance_tests": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.3 states 'we leverage MWW tests to further confirm the improvement based on 4 LLMs, returning a two-sided p-value with < 0.05' to test significance of ReduceFix vs Origin Test and ReduceFix vs ddmin-only."
       },
       "effect_sizes_reported": {
         "applies": true,
         "answer": true,
         "justification": "Throughout the paper, results are reported with both absolute differences and relative improvements with baseline context (e.g., 'pass@10 climbs from 20% to 25.5%', '53.8% relative', '21.3% relative gain'). This provides sufficient context for effect size interpretation."
       },
       "sample_size_justified": {
         "applies": true,
         "answer": false,
         "justification": "No justification for why 200 bugs across 20 tasks, or 12 OSS-Fuzz instances, were chosen. No power analysis is discussed. The OSS-Fuzz evaluation uses only 12 instances, which is very small."
       },
       "variance_reported": {
         "applies": true,
         "answer": false,
         "justification": "No standard deviation, IQR, or variance across experimental repetitions is reported. Results are from a single run of each configuration. The pass@k statistic aggregates over sampling but no spread measure across independent runs is given."
       }
     },
     "evaluation_design": {
       "baselines_included": {
         "applies": true,
         "answer": true,
         "justification": "Multiple baselines are compared: Baseline (no test input), Origin Test (full failing input), ddmin-only, and pure-LLM reduction. Additionally, ChatRepair and CREF are used as baselines for plug-in evaluation."
       },
       "baselines_contemporary": {
         "applies": true,
         "answer": true,
         "justification": "ChatRepair (2024) and CREF (2024) are contemporary APR systems. The evaluated LLMs (DeepSeek-V3, Qwen2.5-Plus) are current models. The ddmin algorithm is a classical but still-relevant baseline for input reduction."
       },
       "ablation_study": {
         "applies": true,
         "answer": true,
         "justification": "RQ-3 (Section 5.4) is an ablation study testing five prompt variants (Baseline, Diff Lines, Reduced Test, Origin Test, Reduced + Origin) to isolate the contributions of length reduction vs. information selection. RQ-1 also ablates the reducer components (LLM+ddmin vs ddmin-only vs pure-LLM)."
       },
       "multiple_metrics": {
         "applies": true,
         "answer": true,
         "justification": "Multiple metrics are reported: pass@1, pass@5, pass@10 for repair; success rate and compression rate (mean and median) for reduction; and token cost in Table 5."
       },
       "human_evaluation": {
         "applies": true,
         "answer": false,
         "justification": "All evaluation is automated via test suite pass/fail. No human evaluation of patch quality, correctness, or readability is performed."
       },
       "held_out_test_set": {
         "applies": true,
         "answer": true,
         "justification": "Patches are validated against the full official AtCoder hidden test suite, which is not used for any tuning or selection. Section 3.4 states 'each candidate... is executed against the full hidden suite I.' For OSS-Fuzz, Docker-grounded validation is used."
       },
       "per_category_breakdown": {
         "applies": true,
         "answer": true,
         "justification": "Results are broken down by difficulty level (C, D, E&F) in Tables 3, 6, 7, 9–11, by input format category in Table 4, and per-project for OSS-Fuzz in Tables 12–13."
       },
       "failure_cases_discussed": {
         "applies": true,
         "answer": true,
         "justification": "Section 5.2 includes a detailed 'Failed Case Study' analyzing submission 62869553 of task ABC372E, explaining why the reducer failed (renumbering masked the defect) and proposing a fix."
       },
       "negative_results_reported": {
         "applies": true,
         "answer": true,
         "justification": "Multiple negative results are reported: Origin Test often hurts performance (e.g., GLM-4-9B-chat drops from 8.5% to 6.5% pass@10); 10/200 reductions failed; CREF improvement is only 2.6% relative; ImageMagick remained unsolved on OSS-Fuzz."
       }
     },
     "claims_and_evidence": {
       "abstract_claims_supported": {
         "applies": true,
         "answer": true,
         "justification": "Abstract claims are supported: 89.1% average compression (Table 3), up to 53.8% pass@10 improvement (Table 6, Qwen2.5-Coder-7B from 19.0% to 25.5% = 34.2%, but GLM-4-9B-chat from 6.5% to 10.0% = 53.8%), 21.3% ChatRepair improvement (Table 10), 2.6% CREF improvement (Table 11). All verifiable in the results tables."
       },
       "causal_claims_justified": {
         "applies": true,
         "answer": true,
         "justification": "Causal claims ('ReduceFix improves repair') are supported by controlled experiments: same bugs, same LLMs, same hyperparameters, varying only the prompt condition. RQ-3 ablation isolates length reduction vs. information content through controlled single-variable manipulation. MWW significance tests confirm the differences."
       },
       "generalization_bounded": {
         "applies": true,
         "answer": false,
         "justification": "The title claims 'LLM-based Program Repair' broadly, and the abstract says 'a practical and powerful complement to LLM-based APR.' However, evaluation is primarily on 200 competitive programming bugs from AtCoder (C++ and 20 Python) and only 12 OSS-Fuzz instances. Competitive programming is a narrow domain; the generalization to real-world software bugs is not bounded."
       },
       "alternative_explanations_discussed": {
         "applies": true,
         "answer": true,
         "justification": "RQ-3 explicitly tests the alternative explanation that gains come from length reduction alone (Diff Lines variant) vs. information content, showing both are needed. Section 6 discusses LLM stochasticity as a confound and addresses it via MWW tests and controlled decoding temperature."
       },
       "proxy_outcome_distinction": {
         "applies": true,
         "answer": true,
         "justification": "The paper measures pass@k (patches passing test suites) and frames results as 'repair accuracy.' Pass@k is the standard, directly relevant metric for APR — no proxy gap exists. The metric is formally defined in Section 4.3."
       }
     },
     "setup_transparency": {
       "model_versions_specified": {
         "applies": true,
         "answer": false,
         "justification": "Open-source models are identified by specific names (GLM-4-9B-chat, Qwen2.5-Coder-7B-instruct). However, Qwen2.5-Plus is a closed-weight hosted API service with no snapshot date or API version specified — the paper notes 'the provider does not disclose an exact parameter count.' DeepSeek-V3 is identified by its technical report but no API snapshot date is given."
       },
       "prompts_provided": {
         "applies": true,
         "answer": false,
         "justification": "Listing 1 shows the reducer generation prompt as a template with placeholders ({EXAMPLE_PROBLEM_ID_STR}, {example_problem_title}, etc.) whose fill values are not provided. The repair prompt in Section 3.4 is described only conceptually ('concatenates the task description P, the buggy submission sw and the reduced input i∗') without the actual text."
       },
       "hyperparameters_reported": {
         "applies": true,
         "answer": true,
         "justification": "Table 2 comprehensively lists all hyperparameters: decoding temperature (0.0 for reducer, 0.8 for repair), wall-clock limit (60s), number of samples per bug (10), compilation timeout (10s), execution timeout (5s per test case)."
       },
       "scaffolding_described": {
         "applies": true,
         "answer": true,
         "justification": "The three-stage pipeline (reducer generation, input reduction, patch generation) is described in detail through Algorithm 1 (full pseudocode), Figure 2 (overview diagram), and Sections 3.2–3.4 explaining each stage's mechanics including time limits, fallback logic, and truncation handling."
       },
       "data_preprocessing_documented": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 documents the benchmark construction pipeline: contest selection (ABC 361–377), difficulty filter (C–F), input size filter (≥4KB), submission collection method (10 C++ and 1 Python per task, manually collected before July 1 2025), resulting in 200+20 bugs. Input format categorization is given in Table 1."
       }
     },
     "limitations_and_scope": {
       "limitations_section_present": {
         "applies": true,
         "answer": true,
         "justification": "Section 6 'Threats to Validity' provides substantial discussion organized into internal validity, construct validity, and external validity subsections."
       },
       "threats_to_validity_specific": {
         "applies": true,
         "answer": true,
         "justification": "Section 6 discusses specific threats: LLM stochasticity mitigated by temperature=0 for reducer generation and pass@k sampling for repair; compression ratio reaching 100% hiding variation (addressed by reporting both mean and median); dataset bias mitigated by including all qualifying AtCoder problems without cherry-picking."
       },
       "scope_boundaries_stated": {
         "applies": true,
         "answer": false,
         "justification": "Section 6 discusses what the authors DID to mitigate external validity concerns (tested on ChatRepair/CREF, OSS-Fuzz, LFTBench-Py) but does not explicitly state what the results do NOT show — e.g., no explicit acknowledgment that results may not apply to non-competitive-programming domains, languages beyond C++/Python, or bugs without long inputs."
       }
     },
     "data_integrity": {
       "raw_data_available": {
         "applies": true,
         "answer": true,
         "justification": "The full artifact is published at https://github.com/GLEAM-Lab/ReduceFix (Section 4.4), which should include LFTBench data, reducer scripts, and experimental results for independent verification."
       },
       "data_collection_described": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 describes the data collection in detail: AtCoder contests 361–377, difficulty C–F, input size ≥4KB, 10 C++ and 1 Python wrong-answer submissions per task manually collected before July 1 2025, with median input size over 1MB."
       },
       "recruitment_methods_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. Data is sourced from AtCoder public contest submissions and OSS-Fuzz public crash instances — both standard public sources."
       },
       "data_pipeline_documented": {
         "applies": true,
         "answer": true,
         "justification": "The pipeline is documented: select ABC 361–377 → filter by test size ≥4KB and difficulty C–F → yields 20 tasks → collect 10 C++ and 1 Python submission per task → 200 C++ and 20 Python bugs. For OSS-Fuzz, the pipeline is: filter ARVO instances to single-file patches with inputs >1KB → select 12 smallest patches from 5 projects."
       }
     },
     "conflicts_of_interest": {
       "funding_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "The Acknowledgments section discloses National Natural Science Foundation of China (Grant 62273292), Central Leading Local Science and Technology Development Project of Hebei Province (Grant 246Z0804G), and Innovation Capability Improvement Plan Project of Hebei Province (22567626H)."
       },
       "affiliations_disclosed": {
         "applies": true,
         "answer": true,
         "justification": "Author affiliations are listed: Yanshan University, Peking University, Zhejiang University, and Aalto University. None of the authors are affiliated with the evaluated model providers (Qwen/Alibaba, DeepSeek, GLM/Zhipu)."
       },
       "funder_independent_of_outcome": {
         "applies": true,
         "answer": true,
         "justification": "Funding is from Chinese national and provincial science foundations (NSFC, Hebei Province grants) with no apparent financial stake in whether ReduceFix outperforms baselines."
       },
       "financial_interests_declared": {
         "applies": true,
         "answer": false,
         "justification": "No competing interests statement or financial disclosure is present in the paper. Absence of a disclosure statement does not equal absence of conflicts."
       }
     },
     "contamination": {
       "training_cutoff_stated": {
         "applies": true,
         "answer": false,
         "justification": "The paper states LFTBench tasks are 'entirely after the knowledge cut-offs of the 4 LLMs we evaluate' but does not state the actual training cutoff dates for any of the four models. The reader cannot verify the claim without looking up each model's cutoff independently."
       },
       "train_test_overlap_discussed": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.2 explicitly discusses overlap risk: 'most of those benchmarks were released years ago and are drawn from popular open-source projects that large language models have almost certainly seen.' They chose post-cutoff AtCoder tasks to avoid this. For OSS-Fuzz, they acknowledge 'some OSS-Fuzz repositories may overlap with LLM pretraining corpora' but argue relative comparisons remain valid."
       },
       "benchmark_contamination_addressed": {
         "applies": true,
         "answer": true,
         "justification": "The primary mitigation is temporal: LFTBench uses AtCoder contests 361–377, stated to be after all evaluated models' training cutoffs. For OSS-Fuzz, they acknowledge potential contamination and note that holding evaluation conditions fixed ensures relative differences remain valid despite potential leakage."
       }
     },
     "human_studies": {
       "pre_registered": {
         "applies": false,
         "answer": false,
         "justification": "No human participants in this study. It is a benchmark evaluation of automated program repair systems."
       },
       "irb_or_ethics_approval": {
         "applies": false,
         "answer": false,
         "justification": "No human participants. The study uses publicly available code submissions and automated testing."
       },
       "demographics_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants involved."
       },
       "inclusion_exclusion_criteria": {
         "applies": false,
         "answer": false,
         "justification": "No human participants involved."
       },
       "randomization_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants involved."
       },
       "blinding_described": {
         "applies": false,
         "answer": false,
         "justification": "No human participants involved."
       },
       "attrition_reported": {
         "applies": false,
         "answer": false,
         "justification": "No human participants involved."
       }
     },
     "cost_and_practicality": {
       "inference_cost_reported": {
         "applies": true,
         "answer": true,
         "justification": "Table 5 reports token consumption and USD costs for reduction ($0.017 for ReduceFix vs $0.632 for pure-LLM on 20 problems). Section 4.1 lists per-token API pricing for Qwen2.5-Plus ($0.11/M input, $0.27/M output) and DeepSeek-V3 ($0.27/M input, $1.11/M output)."
       },
       "compute_budget_stated": {
         "applies": true,
         "answer": false,
         "justification": "No total computational budget is stated. Table 5 covers only the reduction phase for 20 problems. Total GPU hours for locally-deployed models (GLM-4-9B, Qwen2.5-Coder-7B), total API spend for the full experiment, and hardware specifications are not reported."
       }
     },
     "experimental_rigor": {
       "seed_sensitivity_reported": {
         "applies": true,
         "answer": false,
         "justification": "No mention of multiple random seeds or seed sensitivity analysis. Results appear to be from single experimental configurations with temperature 0.8 sampling."
       },
       "number_of_runs_stated": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.3 and Table 2 state '10 candidate patches per bug' for repair inference. Section 3.2 states reducer generation uses greedy decoding (deterministic single run). The sampling protocol is explicitly defined."
       },
       "hyperparameter_search_budget": {
         "applies": true,
         "answer": false,
         "justification": "Section 4.4 states 'All values were chosen with small pilot runs on tasks outside the benchmark' but does not report how many configurations were tried, what search method was used, or the compute spent on hyperparameter selection."
       },
       "best_config_selection_justified": {
         "applies": true,
         "answer": true,
         "justification": "Section 4.4 states hyperparameters were 'chosen with small pilot runs on tasks outside the benchmark and kept unchanged throughout the study,' avoiding test-set snooping by using out-of-benchmark data for tuning."
       },
       "multiple_comparison_correction": {
         "applies": true,
         "answer": false,
         "justification": "MWW tests are run across multiple LLMs and prompt conditions (at least 8 comparisons) but no Bonferroni, Holm, or other family-wise error rate correction is mentioned."
       },
       "self_comparison_bias_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The authors compare their ReduceFix system against their own implementations of ddmin-only and pure-LLM baselines without acknowledging or discussing author-evaluation bias. No independent evaluation is performed."
       },
       "compute_budget_vs_performance": {
         "applies": true,
         "answer": false,
         "justification": "ReduceFix adds an extra LLM call for reducer generation and a ddmin execution phase, but the total compute cost of the full pipeline is not compared against baselines. Table 5 only covers the reduction phase cost, not the complete pipeline including repair inference."
       },
       "benchmark_construct_validity": {
         "applies": true,
         "answer": false,
         "justification": "The paper motivates why long-input benchmarks are needed (Section 4.2) but does not discuss whether LFTBench's competitive programming bugs are a valid proxy for real-world APR scenarios. The construct validity gap between AtCoder tasks and industrial software bugs is not addressed."
       },
       "scaffold_confound_addressed": {
         "applies": true,
         "answer": true,
         "justification": "All model comparisons in Tables 6 use the identical ReduceFix pipeline, varying only the model. For ChatRepair and CREF integration (Tables 10–11), only the input is changed (reduced vs original) while keeping all other logic identical, properly isolating the reduction effect."
       }
     },
     "data_leakage": {
       "temporal_leakage_addressed": {
         "applies": true,
         "answer": true,
         "justification": "The paper specifically uses AtCoder contests 361–377 'entirely after the knowledge cut-offs of the 4 LLMs we evaluate' (Section 4.2) as a temporal leakage prevention measure."
       },
       "feature_leakage_addressed": {
         "applies": true,
         "answer": false,
         "justification": "No discussion of whether the evaluation setup leaks information not available in real APR usage. For instance, ReduceFix requires a correct reference solution A to drive the reducer's interestingness predicate, which is not available in real-world repair scenarios. This evaluation-setup feature leak is not discussed."
       },
       "non_independence_addressed": {
         "applies": true,
         "answer": false,
         "justification": "The 200 bugs comprise 10 submissions per task across 20 tasks, meaning bugs from the same task share the same test inputs, problem description, and likely similar bug patterns. This structural non-independence is not discussed."
       },
       "leakage_detection_method": {
         "applies": true,
         "answer": true,
         "justification": "Temporal splitting is applied as a concrete leakage prevention method: selecting AtCoder contests after training cutoffs ensures benchmark problems did not appear in training data. This is a prevention method rather than detection, but the schema lists 'temporal splits' as a qualifying method."
       }
     }
   },
   "claims": [
     {
       "claim": "ReduceFix generates syntactically correct reducers for all 200 bugs, with 95% successfully reducing inputs by an average of 89.1%.",
       "evidence": "Tables 3 and 4 show 95.0% success rate across 200 bugs. Mean compression rates are 84.5% (C), 97.0% (D), 83.0% (E&F). All 200 reducer scripts passed syntax checks (Section 5.2).",
       "supported": "strong"
     },
     {
       "claim": "ReduceFix improves overall pass@10 by up to 53.8% relative to prompts that include the original test input.",
       "evidence": "Table 6 shows GLM-4-9B-chat pass@10 rises from 6.5% (Origin Test) to 10.0% (Reduced Test), a 53.8% relative gain. Similar improvements are shown for all four LLMs.",
       "supported": "strong"
     },
     {
       "claim": "Supplying the full failing test input often hurts repair accuracy compared to the no-test baseline.",
       "evidence": "Table 6 shows GLM-4-9B-chat pass@10 drops from 8.5% (Baseline) to 6.5% (Origin Test); DeepSeek-V3 drops from 66.5% to 63.0%. This is consistent across multiple LLMs.",
       "supported": "strong"
     },
     {
       "claim": "Adding ReduceFix as a plug-in to ChatRepair increases pass@10 by 21.3% relative.",
       "evidence": "Table 10 shows ChatRepair overall pass@10 rises from 30.5% to 37.0% (6.5pp absolute, 21.3% relative). Gains hold across all difficulty levels.",
       "supported": "strong"
     },
     {
       "claim": "Adding ReduceFix to CREF increases pass@10 by 2.6% relative.",
       "evidence": "Table 11 shows CREF overall pass@10 rises from 39.0% to 40.0% (1.0pp absolute, 2.6% relative).",
       "supported": "moderate"
     },
     {
       "claim": "On OSS-Fuzz, reduced inputs raise pass@10 from 16.7% (Origin Test) to 41.7%.",
       "evidence": "Table 13 shows micro-average pass@10 across 12 instances: 16.7% for Origin Test, 41.7% for Reduced Test. However, this is based on only 12 instances across 5 projects.",
       "supported": "weak"
     },
     {
       "claim": "The benefit comes from the combination of brevity and complete failure evidence, not length reduction alone.",
       "evidence": "Table 9 (RQ-3) shows Reduced Test (25.5% pass@10) outperforms both Diff Lines (20.0%, same length but different info) and Reduced+Origin (19.0%, more info but longer), demonstrating both factors are needed.",
       "supported": "moderate"
     }
   ],
   "red_flags": [
     {
       "flag": "Very small OSS-Fuzz evaluation",
       "detail": "The OSS-Fuzz evaluation uses only 12 instances across 5 projects, which is too small for reliable generalization to industrial-scale repair scenarios. The paper selects the 12 instances with the smallest patches, which may bias toward easier bugs."
     },
     {
       "flag": "No variance across experimental repetitions",
       "detail": "All results are from single experimental runs with stochastic LLMs (temperature 0.8). No standard deviation, IQR, or variance across repetitions is reported. The pass@k computation aggregates sampling noise within a run but does not capture run-to-run variability."
     },
     {
       "flag": "Narrow evaluation domain",
       "detail": "200 of 212 total bugs are from AtCoder competitive programming contests — a narrow domain with well-defined input/output specifications, reference solutions, and clear test oracles. Real-world APR scenarios rarely have these properties. The generalizability to industrial software bugs is unclear."
     },
     {
       "flag": "Multiple comparison issue",
       "detail": "MWW significance tests are run across multiple LLMs and prompt conditions without correction for multiple comparisons (no Bonferroni, Holm, etc.), inflating the risk of Type I errors."
     },
     {
       "flag": "Reference solution requirement not prominently disclosed",
       "detail": "ReduceFix's reducer requires a correct reference solution A to determine if the reduced input still triggers the bug (A(i) ≠ sw(i)). This is available in competitive programming but rarely in real-world repair scenarios. This strong assumption is not prominently discussed as a limitation."
     }
   ],
   "cited_papers": [
     {
       "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": "Foundational conversational LLM-based APR system that ReduceFix extends and evaluates against."
     },
     {
       "title": "Cref: An llm-based conversational software repair framework for programming tutors",
       "authors": ["Boyang Yang", "Haoye Tian", "Weiguo Pian", "Haoran Yu", "Haitao Wang", "Jacques Klein", "Tegawendé F Bissyandé", "Shunfu Jin"],
       "year": 2024,
       "relevance": "Conversational LLM-based APR for tutoring that identified the test-input-hurts-repair phenomenon and is used as a baseline."
     },
     {
       "title": "Less training, more repairing please: revisiting automated program repair via zero-shot learning",
       "authors": ["Chunqiu Steven Xia", "Lingming Zhang"],
       "year": 2022,
       "relevance": "Pioneering work on zero-shot LLM-based APR that demonstrated LLMs can repair without task-specific training."
     },
     {
       "title": "ThinkRepair: Self-Directed Automated Program Repair",
       "authors": ["Xin Yin", "Chao Ni", "Shaohua Wang", "Zhenhao Li", "Limin Zeng", "Xiaohu Yang"],
       "year": 2024,
       "doi": "10.1145/3650212.3680359",
       "relevance": "Self-directed LLM APR approach that uses multi-step reasoning for patch generation."
     },
     {
       "title": "Automated repair of programs from large language models",
       "authors": ["Zhiyu Fan", "Xiang Gao", "Martin Mirchev", "Abhik Roychoudhury", "Shin Hwei Tan"],
       "year": 2023,
       "relevance": "Early work on LLM-based program repair demonstrating strong results on standard benchmarks."
     },
     {
       "title": "Agentless: Demystifying llm-based software engineering agents",
       "authors": ["Chunqiu Steven Xia", "Yinlin Deng", "Soren Dunn", "Lingming Zhang"],
       "year": 2024,
       "relevance": "LLM-based SE agent framework using SEARCH/REPLACE blocks for repository-level repair, whose format ReduceFix adopts for OSS-Fuzz evaluation."
     },
     {
       "title": "A Survey of LLM-based Automated Program Repair: Taxonomies, Design Paradigms, and Applications",
       "authors": ["Boyang Yang", "Zijian Cai", "Fengling Liu", "Bach Le", "Lingming Zhang", "Tegawendé F. Bissyandé", "Yang Liu", "Haoye Tian"],
       "year": 2025,
       "arxiv_id": "2506.23749",
       "relevance": "Comprehensive survey of LLM-based APR providing taxonomy and landscape of the field ReduceFix contributes to."
     },
     {
       "title": "Lost in the middle: How language models use long contexts",
       "authors": ["Nelson F Liu", "Kevin Lin", "John Hewitt", "Ashwin Paranjape", "Michele Bevilacqua", "Fabio Petroni", "Percy Liang"],
       "year": 2023,
       "relevance": "Key empirical finding that LLMs attend less to information in the middle of long contexts, motivating ReduceFix's input reduction approach."
     },
     {
       "title": "Simplifying and Isolating Failure-Inducing Input",
       "authors": ["Andreas Zeller", "Ralf Hildebrandt"],
       "year": 2002,
       "doi": "10.1109/32.988498",
       "relevance": "Original ddmin algorithm that forms the algorithmic foundation of ReduceFix's input reduction strategy."
     },
     {
       "title": "ContrastRepair: Enhancing conversation-based automated program repair via contrastive test case pairs",
       "authors": ["Jiaolong Kong", "Mingfei Cheng", "Xiaofei Xie", "Shangqing Liu", "Xiaoning Du", "Qi Guo"],
       "year": 2024,
       "relevance": "Conversation-based APR that uses contrastive test pairs to guide repair, related to ReduceFix's use of test evidence in prompts."
     },
     {
       "title": "Code repair with llms gives an exploration-exploitation tradeoff",
       "authors": ["Hao Tang", "Keya Hu", "Jin Zhou", "Si Cheng Zhong", "Wei-Long Zheng", "Xujie Si", "Kevin Ellis"],
       "year": 2024,
       "relevance": "Analysis of the exploration-exploitation tradeoff in LLM-based code repair, another approach embedding test cases in repair prompts."
     },
     {
       "title": "Arvo: Atlas of reproducible vulnerabilities for open source software",
       "authors": ["Xiang Mei", "Pulkit Singh Singaria", "Jordi Del Castillo", "Haoran Xi", "Tiffany Bao", "Ruoyu Wang", "Yan Shoshitaishvili", "Adam Doupé", "Hammond Pearce", "Brendan Dolan-Gavitt"],
       "year": 2024,
       "relevance": "Provides the OSS-Fuzz evaluation infrastructure (Docker images, ground-truth patches) used for ReduceFix's repository-level evaluation."
     },
     {
       "title": "MORepair: Teaching LLMs to Repair Code via Multi-Objective Fine-Tuning",
       "authors": ["Boyang Yang", "Haoye Tian", "Jiadong Ren", "Hongyu Zhang", "Jacques Klein", "Tegawende Bissyande", "Claire Le Goues", "Shunfu Jin"],
       "year": 2025,
       "relevance": "Multi-objective fine-tuning approach for LLM-based code repair, representing fine-tuning-based APR paradigm."
     }
   ],
   "engagement_factors": {
     "practical_relevance": {
       "score": 2,
       "justification": "ReduceFix is a practical tool with released code that can be plugged into existing APR pipelines, though it requires competitive-programming-style reference solutions to work."
     },
     "surprise_contrarian": {
       "score": 1,
       "justification": "The finding that including full test inputs can hurt LLM repair accuracy is somewhat counter-intuitive but aligns with known lost-in-the-middle effects."
     },
     "fear_safety": {
       "score": 0,
       "justification": "No AI safety or security implications; this is a program repair technique."
     },
     "drama_conflict": {
       "score": 0,
       "justification": "No controversy or conflict angle; straightforward benchmark evaluation paper."
     },
     "demo_ability": {
       "score": 2,
       "justification": "Code is released on GitHub (GLEAM-Lab/ReduceFix) and the benchmark is published, though setting up the evaluation requires AtCoder infrastructure."
     },
     "brand_recognition": {
       "score": 0,
       "justification": "Authors are from Yanshan University, Peking University, Zhejiang University, and Aalto University — respected institutions but not famous AI labs."
     }
   }
 }