Repair-R1: Better Test Before Repair

Haichuan Hu; Quanjun Zhang; Xiaochen Xie

REVIEW 4 major objections 5 minor 3 cited by

Repair-R1: Better Test Before Repair

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Repair-R1 claims that automated program repair improves when models are trained, via reinforcement learning, to write tests that expose a bug before patching it.

desk verdict A genuinely new RL training recipe for test-before-repair code repair, with honest code release, but the causal claim about ordering is underdetermined by the experiments and the abstract's coverage range is contradicted by its own table. read the letter →

arxiv 2507.22853 v1 pith:H5ZOSK2C submitted 2025-07-30 cs.SE cs.AI

Haichuan Hu , Xiaochen Xie , Quanjun Zhang This is my paper

classification cs.SEcs.AI

keywords AutomatedProgramRepairTestGenerationReinforcementLearningGRPOLargeLanguageModelsDiscriminativeTestsBenchmarks

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Repair-R1 claims that automated program repair improves when the model is trained, via reinforcement learning, to generate tests that expose the bug before it generates the patch. The paper treats a test that passes the correct code and fails the buggy code as a signal for the latent cause of the defect, turning test generation into a guiding step for repair. Across four benchmarks and three backbone models, the method reports gains of 2.68% to 48.29% in repair success rate, 16.38% to 53.28% in test generation success rate, and 0.78% to 53.96% in test coverage over vanilla models. The authors argue this beats both supervised fine-tuning and single-objective reinforcement learning. If the claim holds, test generation becomes a training-time reasoning scaffold for repair models rather than just a validation step.

What carries the argument

The load-bearing object is the 'discriminative test case', defined by validity $V_t = f(t,G) \cdot (1 - f(t,B))$: it passes the ground-truth code $G$ and fails the buggy code $B$ (Eq. 8). The test generation reward $R_t = \frac{1}{n}(1-F)P^\top$ is the fraction of generated tests that are valid. The two-stage GRPO pipeline jointly optimizes a code repair reward (patch pass rate on oracle tests) and the test generation reward, with a format reward enforcing the '<test> then <patch>' output order. The ELBO derivation in Eq. (4) supplies the formal justification: test generation acts as a variational posterior $q_\phi(z|p,b)$ over the latent bug cause, and the KL term keeps the optimized policy close to the reference model.

What would settle it

Train Repair-R1 with the same rewards but reverse the generation order (patch first, then tests) and compare repair success on the four benchmarks; if the reversed-order model matches Repair-R1, the benefit comes from the joint RL objective rather than the test-before-repair ordering. Alternatively, withhold generated tests from the patch prompt during inference; if the model still repairs at the same rate, the repair step does not actually use the tests as information.

Watch

Extended reading notes

Core claim

The central discovery is that jointly optimizing test generation and repair with a two-stage reinforcement learning objective produces a model whose repair and test generation abilities improve together, with the order of operations playing a key role: the model is prompted to produce discriminative tests first, then the patch. The paper formalizes this by introducing a latent bug cause $z$, rewriting repair as marginalizing over $z$, and modelling test generation as an approximate posterior over that cause. The discriminative test, defined as one that passes the ground-truth code and fails the buggy code, is the operational proxy for discovering $z$. Using GRPO with separate rewards for test generation, code repair, and output format, Repair-R1 reports consistent improvements on HumanEval, MBPP, CodeForces, and CodeContests, with a repair success rate gain over vanilla models and superiority over SFT and single-objective reinforcement learning baselines.

Load-bearing premise

The claim rests on the assumption that a test which fails the buggy code and passes the fixed code reveals the underlying cause of the defect, so that test-first training genuinely builds understanding rather than just symptom-matching behavior.

Editorial extensions

If this is right

If the ordering claim is right, test generation becomes a first-class training target for program repair rather than a post-hoc validator.
The method shows that RL with rule-based rewards avoids the forgetting effect that fine-tuning exhibits on underrepresented benchmarks, allowing repair training to generalize across heterogeneous bug datasets.
Repair success continues to improve with test-time sampling up to the tested size of 8, suggesting the trained policy scales with additional compute.
The simultaneous gain in test coverage and test generation success means a single trained model can serve both test-writing and patching roles.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A direct test of the causal ordering claim would reverse the two stages (patch first, then tests) under identical rewards; the paper does not run this ablation, so a competing explanation remains that the joint RL objective alone drives the gains.
The discriminative-test proxy equates symptom exposure with root cause; if a bug has multiple independent causes, tests may expose symptoms without isolating which cause is being fixed, suggesting fault-localization metadata as an additional training signal.
The same two-stage scheme could transfer to test-driven code generation or test-driven refactoring, where the 'buggy' input is a specification gap rather than a defect.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

Here's my read on Repair-R1. The genuinely new thing is the training recipe: RL (GRPO) that co-optimizes test generation and repair, requiring the model to output tests before patches. They ablate against RL on each task alone and show joint training wins on most cells. They also release code and weights, which puts the empirical claims on reproducible ground. That alone makes the paper worth a serious referee.

The paper does something else well: it shows RL avoids the catastrophic forgetting that SFT exhibits on underrepresented benchmarks. That's a real, somewhat non-obvious observation.

Now the soft spots, in order of importance. The headline causal claim—'better test before repair'—is not actually tested. RL-Both differs from RL-Repair in three ways at once: it adds the test-generation reward, imposes a test-then-patch output format, and feeds the generated tests into the repair prompt. Any one of those could explain the gain. The ablation the paper needs is a reversed-order condition: same rewards and format, but patch before tests. Without it, the title overclaims. The ELBO-to-GRPO framing does not close this gap; it's expository and the identification of a discriminative test with the latent bug cause is asserted, not shown.

Second, the abstract's test-coverage improvement range (0.78% to 53.96%) is contradicted by Table I. Qwen3-4B on HumanEval goes from 81.25% Tcov vanilla to 73.21% RL-Both. That's a concrete factual error that has to be fixed.

Third, there's real circularity in the metrics: Test, Tcov, and Bugfix are (or approximate) the reward functions themselves, so improvement on them is partly by construction. That's not disqualifying—it's common in code RL—but the external comparisons are only against vanilla and SFT; no published APR baseline is run.

No error bars either, though with 60 experiments that's less damning.

Overall: the recipe is useful and the code release is a plus. The paper needs a reversed-order ablation, a corrected coverage claim, and ideally a comparison to one or two existing APR systems. I'd send it to peer review with major-revision expectations, not desk reject. For a reading group it would prompt a good discussion about reward design and causal claims in LLM training.

Referee Report

4 major / 5 minor

Summary. Repair-R1 is an RL-based automated program repair method that trains LLMs to first generate discriminative test cases (tests that pass the ground-truth code and fail the buggy code) and then generate a patch. Training uses GRPO with three rule-based rewards: format, code repair (oracle pass rate), and test generation (validity/discriminativeness). The paper constructs a mutant dataset from HumanEval, MBPP, CodeForces, and CodeContests, and evaluates three Qwen backbones under five configurations (Vanilla, SFT, RL-Test, RL-Repair, RL-Both) using Bugfix, Test, and Tcov metrics. The main empirical claim is that RL-Both improves all three metrics over vanilla models, and the mechanism claim is that requiring tests before repair improves defect localization and root-cause understanding.

Significance. Strengths: the paper ships code and weights, performs a broad 60-experiment comparison, and reports consistent gains of RL-Both over vanilla and single-objective RL in many settings. The idea of co-optimizing test generation and repair via RL is interesting and could be practically useful. However, the central 'test-before-repair' mechanism is not isolated by any experiment, and one headline coverage number is contradicted by Table I. The theoretical ELBO framing does not bridge to the GRPO objective. If the missing reversed-order ablation confirms the ordering effect, this would be a solid empirical contribution; as is, the evidence supports a multi-task reward-shaping benefit rather than a specifically test-first benefit.

major comments (4)

[Table I / Abstract] The claim that 'test coverage improves by 0.78% to 53.96%' is not supported by the data. In the Qwen3-4B row for HumanEval, Tcov drops from 81.25% (Vanilla) to 73.21% (RL-Both), a decrease of 8.04 percentage points. The range 0.78% to 53.96% is the range of positive deltas, but it excludes this negative result. The abstract and Section V-A must be corrected to state the actual range including the decrease, or the claim must be qualified per model/benchmark.
[Section V-C / Figure 4] The paper credits RL-Both's repair gain over RL-Repair (0.24% to 6.25%) to generating tests before repair, but the two conditions differ in at least three coupled ways: RL-Both adds a test-generation reward, requires a test-then-patch output format, and feeds the generated tests into the repair prompt. No experiment varies the order alone (e.g., repair-then-test with both rewards, or test-then-repair with only the repair reward), so the title claim 'Better Test Before Repair' is not tested. Figure 4 is correlational: after RL, successful repairs and effective tests co-occur, but this co-occurrence is also consistent with a shared underlying repair-skill improvement.
[Section III-B / III-C] The theoretical justification does not close the gap. Equation (4) is a generic ELBO with a latent variable z and an approximate posterior q_phi(z|p,b), but Equation (5) is the GRPO objective with a KL(pi_theta || pi_ref) term and no q_phi; the paper never derives Eq. (5) from Eq. (4). The assertion that a discriminative test 'effectively corresponds to pinpointing the underlying bug cause' is stated without proof or empirical support. The ELBO framing therefore does not provide evidence for the test-first ordering; it is at most an analogy.
[Section III-D / Section IV-B] The reported metrics are the same functions as the RL rewards. 'Test' is exactly the averaged per-test validity V_t of Eq. (8); 'Tcov' is the thresholded version of that reward (at least one valid test); and 'Bugfix' is a thresholded version of the code-repair reward R_r in Eq. (7). Consequently, optimizing the rewards directly optimizes the metrics, so gains on these metrics are partly by construction. The comparisons to Vanilla and SFT remain informative as external baselines, but the claim that test generation 'helps' repair should be supported with additional held-out analyses or metrics not isomorphic to the training rewards.

minor comments (5)

[Table I] The label 'RL-Code' appears for Qwen2.5-Coder-3B-Instruct and Qwen3-4B rows, while the text and other rows use 'RL-Repair'; please standardize.
[Section III-D] After Eq. (8), 'In n all other cases' should read 'In all other cases'.
[Figure 3] The 'faulty function' shown for fib is only a docstring with no function body, so the example is not a clear illustration of a bug; please show the actual defective code.
[Section V-B / Figure 5] The text and figure refer to 'Qwen-4B' although the model is introduced as Qwen3-4B; please use consistent naming.
[Figure 1] The fourth test uses 'valid_email_format' instead of 'check_email_format' and contains a curly apostrophe; please fix.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: reward-aligned metrics are evaluated on held-out benchmarks, and the main method comparison is external; the confounded order ablation is a validity concern, not a circular step.

full rationale

The claimed predictions do not reduce to the inputs by construction. Although the Test metric (Section IV-B) is the same function as the test-generation reward Rt (Eq. 9), and Bugfix is the oracle pass rate used as Rr (Eq. 7), the paper evaluates on a held-out test set (Section IV-A: 4:1 split, no original sample in both sets), so the reported improvements are generalization results rather than enforced identities. The central evidence is a comparison against vanilla, SFT, RL-Test, and RL-Repair on four external benchmarks, which is non-circular. The Section III-B latent-variable argument contains an asserted identification between a discriminative test and the latent bug cause z, and the GRPO objective in Eq. (5) does not literally implement the ELBO KL term in Eq. (4); these are unproven derivation steps, not circular reductions. The RL-Both vs RL-Repair comparison changes reward composition, output format, and ordering simultaneously, so the specific 'test-before-repair' mechanism is underdetermined; this is a confound and experimental-design limitation, not a circularity. The only self-citation (Gamma, Ref. [8]) appears in related work and is not load-bearing. No fitted parameter is renamed as a prediction, and no uniqueness theorem is imported from the authors' prior work.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

No new physical or external entities are introduced. The latent variable z is a formal device in the ELBO derivation rather than an independently claimed entity.

free parameters (1)

GRPO hyperparameters (clip epsilon, KL coefficient beta, group size) = not specified numerically
The RL loss in Eq. (5) depends on epsilon, beta, and group size G, but the paper does not report values or sensitivity analysis; these hand-chosen settings could affect the magnitude of improvements.

assumptions (4)

domain assumption A test that passes the ground-truth code and fails the buggy code corresponds to the latent bug cause z in Eq. (2).
Asserted in Section III-B after Eq. (4); the whole test-first mechanism depends on this identification, which is not proven.
domain assumption GPT-4o-mutated defective variants from HumanEval, MBPP, CodeForces, and CodeContests are representative of realistic bugs.
Dataset construction in Section IV-A uses synthetic mutants; no evidence is provided that they match real-world defect distributions.
domain assumption Oracle test suites in the four benchmarks are complete enough to measure patch correctness.
Both the repair reward and the Bugfix metric evaluate patches only against these tests; overfitting to the tests while changing behavior elsewhere would not be detected.
ad hoc to paper GRPO's objective is a valid surrogate for the ELBO in Eq. (4).
Section III-C claims alignment with the ELBO but gives only a qualitative mapping, not a proof; the ELBO derivation introduces q_phi without experimental implementation.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Repair-R1: Better Test Before Repair." pith.science (2026). https://pith.science/paper/H5ZOSK2C

@misc{pith2026250722853,
  author       = {Pith},
  title        = {Pith review of: Repair-R1: Better Test Before Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H5ZOSK2C}},
  note         = {Machine review of arXiv:2507.22853}
}

read the original abstract

APR (Automated Program Repair) aims to automatically locate program defects, generate patches and validate the repairs. Existing techniques for APR are often combined with LLMs (Large Language Models), which leverages the code-related knowledge of LLMs to improve repair effectiveness. Current LLM-based APR methods typically utilize test cases only during the inference stage, adopting an iterative approach that performs repair first and validates it through test execution afterward. This conventional paradigm neglects two important aspects: the potential contribution of test cases in the training phase, and the possibility of leveraging testing prior to repair. To address this, we propose Repair-R1, which introduces test cases into the model's training phase and shifts test generation to precede repair. The model is required to first generate discriminative test cases that can distinguish defective behaviors, and then perform repair based on these tests. This enables the model to better locate defects and understand the underlying causes of defects, thereby improving repair effectiveness. We implement Repair-R1 with three different backbone models, using RL (reinforcement learning) to co-optimize test generation and bug repair. Experimental results on four widely adopted benchmarks demonstrate the superiority of Repair-R1. Specially, compared to vanilla models, Repair-R1 improves repair success rate by 2.68\% to 48.29\%, test generation success rate by 16.38\% to 53.28\%, and test coverage by 0.78\% to 53.96\%. We publish the code and weights at https://github.com/Tomsawyerhu/APR-RL and https://huggingface.co/tomhu/Qwen3-4B-RL-5000-step.

Figures

Figures reproduced from arXiv: 2507.22853 by the authors.

**Figure 2.** The Optimization Process of Repair-R1 A. Motivation Given a bug, the bug repair model will attempt to fix it based on the code-related knowledge it has acquired from pre-trained datasets. The success of repairs may stem from one of two possibilities. (1) The model accurately identifies the underlying cause of the bug and applies a targeted fix. (2) The model recovers a similar solution by leveraging memorized patter… view at source ↗

**Figure 3.** The prompt used for optimizing Repair-R1. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: A comparison of test generation and repair correlation before and after RL [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]

**Figure 5.** Figure 5: Bugfix@K performance of Repair-R1 on different benchmarks. [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

MultiFixer: A Coordinator-Proposer Based Multi-Agent Framework For Fixing Multi-Hunk Bugs
cs.SE 2026-07 conditional novelty 6.0 of 10

Coordinator-proposer multi-agent repair schedules hunks, proposes candidate patches in parallel, and selects/refines them, fixing 326/835 Defects4J bugs with GPT-3.5 and 420 with Claude-3.5-Sonnet.
SGAgent: Suggestion-Guided LLM-Based Multi-Agent Framework for Repository-Level Software Repair
cs.SE 2026-02 conditional novelty 6.0 of 10

A three-agent locate-suggest-fix framework with a knowledge-graph toolkit resolves 154/300 SWE-Bench-Lite issues with Claude-3.5, outperforming same-model baselines by 5-10 points.
PSearch: Search-based Patch Generation in the Era of LLM-based Automated Program Repair
cs.SE 2025-07 conditional novelty 6.0 of 10

PSearch applies Monte Carlo Tree Search to LLM patch generation with LLM and test-based rewards, fixing 201 Defects4J bugs and resolving 164 SWE-Bench-Lite issues.

Reference graph

Works this paper leans on

25 extracted references · 18 canonical work pages · cited by 3 Pith papers

[1]

Genprog: A generic method for automatic software repair,

C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “Genprog: A generic method for automatic software repair,” Ieee transactions on software engineering , vol. 38, no. 1, pp. 54–72, 2011

work page 2011
[2]

Astor: A program repair library for java,

M. Martinez and M. Monperrus, “Astor: A program repair library for java,” in Proceedings of the 25th international symposium on software testing and analysis , 2016, pp. 441–444

work page 2016
[3]

Arja: Automated repair of java programs via multi-objective genetic programming,

Y . Yuan and W. Banzhaf, “Arja: Automated repair of java programs via multi-objective genetic programming,” IEEE Transactions on software engineering , vol. 46, no. 10, pp. 1040–1067, 2018

work page 2018
[4]

Dynamoth: dynamic code synthesis for automatic program repair,

T. Durieux and M. Monperrus, “Dynamoth: dynamic code synthesis for automatic program repair,” inProceedings of the 11th International Workshop on Automation of Software Test , 2016, pp. 85–91

work page 2016
[5]

Ultra-large repair search space with automatically mined templates: The cardumen mode of astor,

M. Martinez and M. Monperrus, “Ultra-large repair search space with automatically mined templates: The cardumen mode of astor,” in International symposium on search based software engineering . Springer, 2018, pp. 65–86

work page 2018
[6]

Angelix: Scalable multiline program patch synthesis via symbolic analysis,

S. Mechtaev, J. Yi, and A. Roychoudhury, “Angelix: Scalable multiline program patch synthesis via symbolic analysis,” in Proceedings of the 38th international conference on software engineering , 2016, pp. 691–701

work page 2016
[7]

Tbar: Revisiting template-based automated program repair,

K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyand ´e, “Tbar: Revisiting template-based automated program repair,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis , 2019, pp. 31–42. 14

work page 2019
[8]

Gamma: Revisiting template-based automated program repair via mask prediction,

Q. Zhang, C. Fang, T. Zhang, B. Yu, W. Sun, and Z. Chen, “Gamma: Revisiting template-based automated program repair via mask prediction,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 535–547

work page 2023

Show all 25 references

[9]

Template-based neural program repair,

X. Meng, X. Wang, H. Zhang, H. Sun, X. Liu, and C. Hu, “Template-based neural program repair,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2023, pp. 1456–1468

2023
[10]

Tare: Type-aware neural program repair,

Q. Zhu, Z. Sun, W. Zhang, Y . Xiong, and L. Zhang, “Tare: Type-aware neural program repair,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) . IEEE, 2023, pp. 1443–1455

2023
[11]

Selfapr: Self-supervised program repair with test execution diagnostics,

H. Ye, M. Martinez, X. Luo, T. Zhang, and M. Monperrus, “Selfapr: Self-supervised program repair with test execution diagnostics,” in Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering, 2022, pp. 1–13

2022
[12]

Neural program repair with execution-based backpropagation,

H. Ye, M. Martinez, and M. Monperrus, “Neural program repair with execution-based backpropagation,” in Proceedings of the 44th international conference on software engineering , 2022, pp. 1506–1518

2022
[13]

Repairagent: An autonomous, llm-based agent for program repair,

I. Bouzenia, P. Devanbu, and M. Pradel, “Repairagent: An autonomous, llm-based agent for program repair,” arXiv preprint arXiv:2403.17134 , 2024

2024 arXiv
[14]

The use of large language models for program repair,

F. Zubair, M. Al-Hitmi, and C. Catal, “The use of large language models for program repair,” Computer Standards & Interfaces , vol. 93, p. 103951, 2025

2025
[15]

Cref: An llm-based conversational software repair framework for programming tutors,

B. Yang, H. Tian, W. Pian, H. Yu, H. Wang, J. Klein, T. F. Bissyand ´e, and S. Jin, “Cref: An llm-based conversational software repair framework for programming tutors,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis , 2024, pp. 882–894

2024
[16]

Proximal policy optimization algorithms,

J. Schulman, F. Wolski, P. Dhariwal, A. Radford, and O. Klimov, “Proximal policy optimization algorithms,”
[17]

Direct preference optimization: Your language model is secretly a reward model,

R. Rafailov, A. Sharma, E. Mitchell, C. D. Manning, S. Ermon, and C. Finn, “Direct preference optimization: Your language model is secretly a reward model,” Advances in neural information processing systems , vol. 36, pp. 53 728–53 741, 2023

2023
[18]

Ipo: Interior-point policy optimization under constraints,

Y . Liu, J. Ding, and X. Liu, “Ipo: Interior-point policy optimization under constraints,” in Proceedings of the AAAI conference on artificial intelligence , vol. 34, no. 04, 2020, pp. 4940–4947

2020
[19]

Value-incentivized preference optimization: A unified approach to online and offline rlhf,

S. Cen, J. Mei, K. Goshvadi, H. Dai, T. Yang, S. Yang, D. Schuurmans, Y . Chi, and B. Dai, “Value-incentivized preference optimization: A unified approach to online and offline rlhf,” arXiv preprint arXiv:2405.19320 , 2024

2024 arXiv
[20]

Simpo: Simple preference optimization with a reference-free reward,

Y . Meng, M. Xia, and D. Chen, “Simpo: Simple preference optimization with a reference-free reward,” Advances in Neural Information Processing Systems , vol. 37, pp. 124 198–124 235, 2024

2024
[21]

Deepseekmath: Pushing the limits of mathematical reasoning in open language models,

Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y . Li, Y . Wu et al., “Deepseekmath: Pushing the limits of mathematical reasoning in open language models,” arXiv preprint arXiv:2402.03300 , 2024

2024 arXiv
[22]

Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,

D. Guo, D. Yang, H. Zhang, J. Song, R. Zhang, R. Xu, Q. Zhu, S. Ma, P. Wang, X. Bi et al., “Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,” arXiv preprint arXiv:2501.12948 , 2025

2025 arXiv
[23]

Stepcoder: Improve code generation with reinforcement learning from compiler feedback,

S. Dou, Y . Liu, H. Jia, L. Xiong, E. Zhou, W. Shen, J. Shan, C. Huang, X. Wang, X. Fan et al., “Stepcoder: Improve code generation with reinforcement learning from compiler feedback,” arXiv preprint arXiv:2402.01391, 15 2024

2024 arXiv
[24]

Acecoder: An effective prompting technique specialized in code generation,

J. Li, Y . Zhao, Y . Li, G. Li, and Z. Jin, “Acecoder: An effective prompting technique specialized in code generation,” ACM Transactions on Software Engineering and Methodology , vol. 33, no. 8, pp. 1–26, 2024

2024
[2017]

Available: https://arxiv.org/abs/1707.06347

[Online]. Available: https://arxiv.org/abs/1707.06347

arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

Genprog: A generic method for automatic software repair,

C. Le Goues, T. Nguyen, S. Forrest, and W. Weimer, “Genprog: A generic method for automatic software repair,” Ieee transactions on software engineering , vol. 38, no. 1, pp. 54–72, 2011

work page 2011

[2] [2]

Astor: A program repair library for java,

M. Martinez and M. Monperrus, “Astor: A program repair library for java,” in Proceedings of the 25th international symposium on software testing and analysis , 2016, pp. 441–444

work page 2016

[3] [3]

Arja: Automated repair of java programs via multi-objective genetic programming,

Y . Yuan and W. Banzhaf, “Arja: Automated repair of java programs via multi-objective genetic programming,” IEEE Transactions on software engineering , vol. 46, no. 10, pp. 1040–1067, 2018

work page 2018

[4] [4]

Dynamoth: dynamic code synthesis for automatic program repair,

T. Durieux and M. Monperrus, “Dynamoth: dynamic code synthesis for automatic program repair,” inProceedings of the 11th International Workshop on Automation of Software Test , 2016, pp. 85–91

work page 2016

[5] [5]

Ultra-large repair search space with automatically mined templates: The cardumen mode of astor,

M. Martinez and M. Monperrus, “Ultra-large repair search space with automatically mined templates: The cardumen mode of astor,” in International symposium on search based software engineering . Springer, 2018, pp. 65–86

work page 2018

[6] [6]

Angelix: Scalable multiline program patch synthesis via symbolic analysis,

S. Mechtaev, J. Yi, and A. Roychoudhury, “Angelix: Scalable multiline program patch synthesis via symbolic analysis,” in Proceedings of the 38th international conference on software engineering , 2016, pp. 691–701

work page 2016

[7] [7]

Tbar: Revisiting template-based automated program repair,

K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyand ´e, “Tbar: Revisiting template-based automated program repair,” in Proceedings of the 28th ACM SIGSOFT international symposium on software testing and analysis , 2019, pp. 31–42. 14

work page 2019

[8] [8]

Gamma: Revisiting template-based automated program repair via mask prediction,

Q. Zhang, C. Fang, T. Zhang, B. Yu, W. Sun, and Z. Chen, “Gamma: Revisiting template-based automated program repair via mask prediction,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 535–547

work page 2023