QiMeng-PRepair: Precise Code Repair via Edit-Aware Reward Optimization

Changxin Ke; Rui Zhang; Jiaming Guo; Yuanbo Wen; Li Ding; Shuo Wang; Xuyuan Zhu; Xiong Peng

cs.SEApr 7, 2026

QiMeng-PRepair: Precise Code Repair via Edit-Aware Reward Optimization

Authors: Changxin Ke, Rui Zhang, Jiaming Guo, Yuanbo Wen, Li Ding, Shuo Wang, Xuyuan Zhu, Xiong Peng,

Organizations: State Key Lab of Processors, Institute of Computing Technology, CAS · University of Chinese Academy of Sciences · Institute of Microelectronics, CAS

Abstract

Large Language Models (LLMs) achieve strong program repair performance but often suffer from over-editing, where excessive modifications overwrite correct code and hinder bug localization. We systematically quantify its impact and introduce precise repair task, which maximizes reuse of correct code while fixing only buggy parts. Building on this insight, we propose PRepair, a framework that mitigates over-editing and improves repair accuracy. PRepair has two components: Self-Breaking, which generates diverse buggy programs via controlled bug injection and min-max sampling, and Self-Repairing, which trains models with Edit-Aware Group Relative Policy Optimization (EA-GRPO) using an edit-aware reward to encourage minimal yet correct edits. Experiments show that PRepair improves repair precision by up to 31.4% under $\mathrm{fix}_1@1$ , a metric that jointly considers repair correctness and extent, and significantly increases decoding throughput when combined with speculative editing, demonstrating its potential for precise and practical code repair.

Figures & tables

Figure 1: Existing models suffer from over-editing , which not only reduces repair accuracy but also significantly increases the review burden for developers. In comparison, PRepair improves both repair accuracy and maintainability in practice.

Panel of Figure 2 — Figure 2: GRPO training with correctness-only rewards. For both Python and Verilog code repair tasks, although performance improves during training, the edit cost increases substantially, leading to a more severe over-editing phenomenon.

Figure 3: Overview of the PRepair framework. It consists of two stages: Self-Breaking, where the model injects diverse bugs into golden programs to construct high-quality buggy inputs, and Self-Repairing, where the model learns to precise repair these buggy programs via EA-GRPO which uses a dynamic edit-aware reward to encourage minimal yet correct edits.

Language	Method	$\mathrm{pass}@k$			$\mathrm{fix}_{1}\!@\!k$			$\mathrm{fix}_{1.5}\!@\!k$			$\mathrm{fix}_{2}\!@\!k$
Language	Method	1	5	10	1	5	10	1	5	10	1	5	10
Python	GPT4	84.51	94.68	96.95	52.20	71.50	76.83	53.29	72.81	78.66	60.73	79.85	84.76
	+ Prompt	86.89	95.90	96.95	62.56	80.28	85.98	63.90	81.36	86.59	72.44	87.72	90.24
	Gemini2.0-flash	90.73	91.94	92.07	44.88	47.71	48.78	47.38	49.98	51.22	55.12	58.60	60.37
	+ Prompt	92.20	93.28	93.29	63.78	66.45	67.07	64.70	67.67	68.29	71.71	74.95	75.61
	Qwen2.5-Coder-3B	53.78	82.22	86.48	33.72	55.91	60.93	34.18	56.68	62.16	38.78	63.99	69.74

Table 1: Main results. We report

\mathrm{pass}@k

and

\mathrm{fix}_{p}@k

results with

k\in\{1,5,10\}

and

p\in\{1,1.5,2\}

. We evaluate GPT4 and Gemini2.0-flash with prompt engineering, as well as Qwen2.5-Coder-3B and Qwen2.5-Coder-7B under prompt engineering, GRPO, and our EA-GRPO. Bold indicates the best result, and underline indicates the second best in the same model.

Figure 4: Code repair performance of in-domain and cross-domain. We plot the changes of

\mathrm{pass}@1

and

\mathrm{fix}_{1}@1

across training steps, reporting both in-domain and cross-domain performance. (a) In-domain: models are trained on Python data and evaluated on Python code repair; similarly for Verilog. (b) Cross-domain: models trained on Python data are evaluated on Verilog code repair, and vice versa.

Figure 5: Decoding Performance with Speculative Edits. Throughput and acceptance rates of Origin (before training), GRPO, and EA-GRPO on Python and Verilog benchmarks, using buggy code as draft.

$\alpha$	$\beta$	pass@1	pass@5	fix 1 @1	fix 1.5 @1	fix 2 @1
0	0.05	90.73	92.66	81.74	82.35	88.93
0.5	0.2	85.06	85.36	80.27	80.27	84.09
0.8	0.05	91.19	92.90	81.62	82.13	89.54
0.8	0.25	88.78	91.22	77.93	78.54	86.62
1.1	/	89.82	91.70	47.44	48.20	60.88

Table 2: Ablation results of EA-GRPO on Qwen2.5-Coder-7B for Python code repair with varying

\alpha

and

\beta

, reporting pass@1, pass@5, and fix p @1 metrics.

Appendix figures & tables6 assets

Supplementary material from the paper’s appendix.

Appendix

Figure 6: Comparison of attention scores in code repair. The top figure shows the PRepair model trained with EA-GRPO, and the bottom figure shows the model trained with GRPO using correctness-only rewards. The vertical axis corresponds to output tokens, the horizontal axis corresponds to input tokens, and the color intensity indicates the relative magnitude of the attention score.

Category	Parameter	Value	Parameter	Value
Algorithm	Advantage Estimator	GRPO	Normalize Advantage	True
	Use KL in Reward	False	KL Penalty Type	fixed
	KL Coefficient	0.001	Target KL	0.1
Policy Optimization	Learning Rate	$1\times 10^{-6}$	PPO Epochs	1
	Clip Ratio	0.2	Loss Aggregation	token-mean
	Entropy Coefficient	0.0	Use KL Loss	True

Appendix

Table 3: RL Parameter Setting. For both the correctness-only reward setting and our PRepair method, we use the same RL hyperparameters to ensure a fair comparison.

Max tokens	Temperature	Top- $p$	Top- $k$	Min- $p$
2048	0.7	0.8	20	0

Appendix

Table 4: Inference sampling parameters used for local models.

Language	Bug Category	Subtype	Count
Python	Missing Logic	Missing logic	33
	Missing Logic	Excess logic	31
	O/V Misuse	Value misuse	44
	O/V Misuse	Operator misuse	25
	Wrong Logic	Variable misuse	23
	Wrong Logic	Function misuse	8

Appendix

Table 5: Statistics of bug types in the Python and Verilog code repair benchmarks.

Method	line-level			token-level
Method	$\mathrm{fix}_{1}\!@\!1$	$\mathrm{fix}_{1.5}\!@\!1$	$\mathrm{fix}_{2}\!@\!1$	$\mathrm{fix}_{1}\!@\!1$	$\mathrm{fix}_{1.5}\!@\!1$	$\mathrm{fix}_{2}\!@\!1$
GPT4	2.30	3.84	5.77	4.83	7.95	13.18
+ Prompt	22.13	28.04	33.92	24.94	33.15	38.01
Gemini2.0-flash	19.06	24.01	30.57	19.72	31.28	35.34
+ Prompt	42.33	48.44	53.49	45.14	54.26	57.27
Qwen2.5-Coder-7B	36.70	42.86	48.98	43.49	47.23	49.69

Appendix

Table 6: Line-level vs. token-level edit distance on Verilog. We report

\mathrm{fix}_{p}@1

with

p\in\{1,1.5,2\}

under both granularities. Bold indicates the best result, and underline indicates the second best in the same model. The ranking of methods is fully consistent across the two granularities.

Lang	Method	TPS	Draft	Acc.	AR
Verilog	Origin	24.34	229,650	114,467	0.498
	EA-GRPO	28.15	214,404	128,752	0.601
	GRPO	15.87	295,744	76,786	0.260
Python	Origin	29.70	13,404	7,735	0.577
	EA-GRPO	31.51	13,065	8,847	0.677
	GRPO	28.22	14,105	6,751	0.479

Appendix

Table 7: Decoding performance with N-gram speculative decoding. TPS denotes throughput (tokens/s), Acc. denotes accepted tokens, and AR denotes acceptance rate.

Automated Program Repair

Automated program repair develops methods that locate software faults and produce validated fixes with limited human effort.

See all 153 papers

Make Every Expansion Count: Learning to Search Efficiently in LLM Code Repair
Oct 11, 2026Elad Sharony, Ido Greenberg, Jialin Song +3Automated Program Repair
Technion · NVIDIA
PreciseCoder: Faithful and Generalizable Debugging Beyond Unit-Test Rewards
Oct 13, 2026Yunkai Zhan, Miaosen Chai, Shangshang Wang +5Automated Program Repair RL Post-Training
University of Southern California · University of Chicago · Google +1
When Models Edit Too Much: On the Fidelity of Minimal Code Edits
Sep 3, 2026Tongyao Zhu, Wei Hern Lim, Min-Yen KanAutomated Program Repair Language Model Editing
National University of Singapore

Oct 11, 2026J/K move · Enter open · S save

Make Every Expansion Count: Learning to Search Efficiently in LLM Code Repair

Elad Sharony, Ido Greenberg, Jialin Song, Shie Mannor+2

Technion · NVIDIA

Automated Program Repair

Open paper AskPDF arXiv

Large language model (LLM) code-repair systems fix faulty programs by repeatedly generating and testing revisions. Each revision is costly, making the choice of which repair to pursue important for efficiency. Existing search policies rely on test pass rates and search statistics, ignoring the details of test failures and proposed edits. We introduce CodeTriage, a learned policy that prioritizes edits before their revised programs are generated and tested. Its 0.6B-parameter model reads the test output, failure diagnosis, and proposed edit, then predicts a distribution over the number of repair steps needed to reach a fix through that edit. These predictions prioritize all pending edits across programs before generating and testing the revised code. On held-out repair tasks, CodeTriage finds fixes with 21% fewer program revisions and 12% fewer output tokens than the strongest baseline on each metric. Without retraining, it achieves the highest average success across search budgets for each of 11 unseen repair LLMs. Ablations show that both the failure context and edit text, as well as comparisons across programs, improve search. We also release a corpus of 12.2 million program versions from four LLMs, organized into repair trees with proposed edits and test results.

Abstract

Automated Program Repair

Explore similar work

Make Every Expansion Count: Learning to Search Efficiently in LLM Code Repair

PreciseCoder: Faithful and Generalizable Debugging Beyond Unit-Test Rewards

When Models Edit Too Much: On the Fidelity of Minimal Code Edits