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, Di Huang, Zidong Du, Xing Hu, Qi Guo, Yunji Chen
Organizations: State Key Lab of Processors, Institute of Computing Technology, CAS · University of Chinese Academy of Sciences · Institute of Microelectronics, CAS
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 fix1@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.
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
pass@k
fix1@k
fix1.5@k
fix2@k
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 pass@k and fixp@k results with k∈{1,5,10} and p∈{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 pass@1 and fix1@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.
α
β
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 α and β , 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×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
Excess logic
31
O/V Misuse
Value misuse
44
Operator misuse
25
Wrong Logic
Variable misuse
23
Function misuse
8
Appendix
Table 5: Statistics of bug types in the Python and Verilog code repair benchmarks.
Method
line-level
token-level
fix1@1
fix1.5@1
fix2@1
fix1@1
fix1.5@1
fix2@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 fixp@1 with p∈{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.
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.
Reinforcement learning (RL) from unit tests is the common recipe for post-training code models, but a unit test only asks whether the final program passes. We analyze what this unit-test-only reward teaches a model during debugging and find that, while it raises pass rates, it also teaches the model to edit more and to hallucinate bugs in code that is already correct. We introduce PreciseCoder, a training algorithm that augments the unit-test reward with a signal for semantically verified, localized edits, which correlates with smaller edits and higher pass rates. On 4B, 9B, and 27B models, PreciseCoder reduces the average number of edit lines from 7-15to 3 at a pass rate on par with unit-test-only training. Trained only on single-line bugs, PreciseCoder can generalize to repository-level program repair, where it resolves more issues with smaller patches. Its precision also transfers from weaker to stronger models: given the reasoning trace of a 9B PreciseCoder model, frontier models such as GPT-5.6 Sol and Qwen3.8-Max gain 4.6-12.4 points in edit precision with no additional training. Linguistic analysis of the thinking traces shows that our reward encourages the model to reason about individual lines, name the buggy ones, and form consistent bug hypotheses.
Yunkai Zhan, Miaosen Chai, Shangshang Wang +5
University of Southern California · University of Chicago · Google +1
Large language models (LLMs) are increasingly used to edit existing code, but correctness alone is not enough: useful repairs should also be minimal, reviewable, and faithful to the original implementation. We study over-editing, the tendency of a model to rewrite code beyond what is required to fix a bug. We construct an evaluation framework from 400 BigCodeBench problems by injecting controlled AST-level corruptions into reference solutions, giving each repair task a known minimal patch. Across frontier LLMs, over-editing is widespread even among strong models like GPT-5.5: high Pass@1 can coexist with unnecessarily large edits and added cognitive complexity. A preservation instruction substantially reduces this behavior, lowering average excess Levenshtein distance from 0.195 to 0.131, reducing added cognitive complexity by 26.6%, and increasing Pass@1 by 2.3 points. However, these gains do not simply follow from a larger reasoning budget or larger models. We next ask whether minimal editing can be learned directly during post-training. We observe that supervised fine-tuning overfits to seen corruption patterns, whereas reinforcement learning gives the best out-of-domain edit-fidelity and performance-retention trade-off. These results position edit fidelity as a distinct axis of code-repair quality and show that it can be measured and learned.