Pith. sign in

REVIEW 3 major objections 7 minor 40 references

BitsAI-Fix: LLM-Driven Approach for Automated Lint Error Resolution in Practice

T0 review · 3 major / 7 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 This paper claims that an RL-trained 32B code model, using lint re-verification and redundancy-penalized rewards, fixes Go lint errors at 84.68% accuracy with 1.72% redundancy, and that the production system has resolved over 12,000…

desk verdict A credible industrial systems report whose headline accuracy is a real engineering metric but shares its signal with the RL reward, so treat 84.68% as in-loop system performance, not a semantic-correctness bound. read the letter →

arxiv 2508.03487 v1 pith:R5XSOBMS submitted 2025-08-05 cs.SE cs.AIcs.LG

Yuanpeng Li , Qi Long , Zhiyuan Yao , Jian Xu , Lintao Xie , Xu He , Lu Geng , Xin Han
show 2 more authors
Yueyan Chen Wenbo Duan
This is my paper
classification cs.SEcs.AIcs.LG
keywords linterrorrepairautomatedprogramlargelanguagemodelsreinforcementlearningGRPOrule-basedrewardscodediffmatchingindustrialsoftwareengineering
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

BitsAI-Fix claims that a 32B-parameter code model, trained with reinforcement learning on progressively collected verifiable lint-fix data and rewards that penalize redundant edits, reaches 84.68% fix accuracy on Go lint errors while cutting redundant patches to 1.72%. The paper argues this makes a lightweight, non-agent workflow practical for the lint-debt problem, where warning volume vastly exceeds what engineers can fix by hand. In production the system has resolved more than 12,000 static-analysis issues for over 5,000 developers with roughly 1,000 weekly active adopters, so the authors position it as evidence that LLM-based lint repair can work at enterprise scale. The contribution is the whole loop: cold-start semi-synthetic data, GRPO training with rule-based rewards, deployment, feedback gathered by code-diff matching, and iterative retraining.

What carries the argument

The central machinery is a GRPO reinforcement-learning loop with a three-part rule-based reward. Format reward penalizes output that is not a search-and-replace unified diff and penalizes extra blocks; correctness reward gives 0.3 for compiling and 0.7 for a fail-to-pass result on cold-start data or a similarity match on user-feedback data; the redundancy penalty subtracts 0.1 for each extra search-and-replace block. Two data mechanisms carry the training: minimal-dependency construction, which turns large-project lint samples into small compilable units by keeping real AST-derived dependencies and simulating third-party package dependencies, and code-diff matching, which derives ground-truth accepted patches from developer-committed changes instead of UI clicks.

What would settle it

Take a random sample of the 2,271 test-case patches, have senior developers judge whether each patch truly fixes the underlying defect rather than merely satisfying the linter, and compare the judged acceptance rate with the reported 84.68%; a material gap would show that lint-pass verification overstates repair quality.

Watch

Extended reading notes

Core claim

The central claim is that a short, direct generation-and-verification loop, rather than an agent with many tool calls, can reach deployment-grade lint repair once the model is trained on the right data and reward signal. Starting from Qwen2.5-Coder-32B at 53.76% accuracy, supervised fine-tuning reaches 65.48%, and the paper's RL training reaches 84.68% accuracy with 1.72% redundancy. The key to that jump is a two-phase data strategy: a cold-start set of semi-synthetic, compilable samples built by keeping only the minimal dependencies needed to reproduce each lint warning, followed by golden-patch samples collected from real developer feedback after deployment. Reward design matters as much as data: a binary pass/fail reward gives 82.78% accuracy with 6.21% redundancy, a graded reward gives 84.02% and 7.62%, and adding a penalty for redundant search-and-replace blocks gives 84.68% and 1.72%. The paper also claims that measuring adoption by matching system-generated diffs against developers' actual committed diffs yields a more reliable feedback signal than tracking clicks on an adopt button.

Load-bearing premise

The load-bearing premise is that a patch is a correct fix if it compiles and passes the original lint scan; the paper's offline accuracy metric and its cold-start reward both rely on that condition, and the authors acknowledge it cannot guarantee absolute correctness.

Editorial extensions

If this is right

  • Direct single-call repair with verification can reach production accuracy for well-scoped error types, avoiding the latency and cost of agent frameworks.
  • Reinforcement learning with an explicit redundancy penalty produces patches that developers find less intrusive, which is likely necessary for adoption.
  • Semi-synthetic compilable data can bootstrap RL training before any golden patches exist, solving the cold-start problem for new static-analysis rules.
  • A 32B model trained this way can outperform much larger untrained models, so targeted post-training can substitute for raw scale on narrow repair tasks.
  • Diff-matching against real commits turns ordinary developer workflow into a continuous feedback source for iterative model improvement.

Reading between the lines

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

  • Because a fix is scored as correct when it compiles and passes the original lint scan, the reported 84.68% likely overstates true semantic correctness; a manual review of sampled patches would probably find lint-clean edits that still mishandle the underlying defect.
  • The same data-and-reward recipe should transfer to other languages and lint rules that have mechanical verifiability, but for rules that require semantic judgment the reward signal weakens and accuracy should be expected to drop.
  • The diff-matching metric counts any user commit that contains the generated patch as adoption, so partial or heavily edited adoptions may inflate the reported success; a stricter equivalence check would give a more conservative number.
  • A direct testable extension would be to compare lint-pass rate against human-accepted rate on the same test set; a large gap would expose how much of the accuracy claim rests on the chosen verification proxy.
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.

Referee Report

3 major / 7 minor

Summary. The paper presents BitsAI-Fix, an LLM-based workflow for automatically repairing lint errors in Go codebases at ByteDance. The system uses tree-sitter for context expansion, generates search-and-replace patches with a fine-tuned Qwen2.5-Coder-32B model, validates patches via compilation and lint scanning, and employs GRPO-based reinforcement learning with progressive data collection: a cold-start phase using semi-synthetic samples with simulated dependencies, followed by an online feedback phase using a code-diff-matching rule to label user acceptances. The authors report 84.68% fix accuracy on a private 2,271-sample test set, 1.72% redundancy, and production adoption by over 5,000 developers resolving more than 12,000 issues, with about 1,000 weekly active adopters. The paper also describes lessons learned from the industrial deployment.

Significance. If the empirical claims are valid, this is a valuable industrial case study showing that a lightweight, non-agent workflow with progressive verifiable data and redundancy-penalized rewards can make LLM-based lint repair practical at enterprise scale. The real deployment, the scale of the training data, and the explicit discussion of production pitfalls are strengths, as is the honest acknowledgment in §III.B.2 that compilation and lint scanning cannot guarantee semantic correctness. However, the central quantitative claim rests on an evaluation metric that is essentially the same predicate as the RL reward, so the reported accuracy is not an independent measure of repair quality. An independent human evaluation or external benchmark is needed before the 84.68% figure can be fully credited. The paper is a useful contribution to the industrial APR literature, but the evaluation methodology currently overstates the strength of the evidence.

major comments (3)
  1. [§IV.B (Eq. 7) and §III.B.3 (Eq. 5)] The Fix Accuracy metric in Eq. (7) is defined as the proportion of patches that compile and pass the original lint scan, which is exactly the same condition used as the correctness reward for cold-start data in Eq. (5), together with the compilation precheck in Eq. (4). The RL objective therefore directly optimizes the same binary predicate that is later reported as accuracy. The improvement from 53.76% to 84.68% demonstrates that the model learned to satisfy the lint-pass condition, not that it produces semantically correct fixes. The authors acknowledge this in §III.B.2, where they state that compilation and lint scanning 'cannot truly guarantee the absolute correctness of the generated code fixes'. To support the accuracy claim, please provide an independent evaluation, such as human annotation of a random sample, execution of existing test suites, or comparison against ground-truth patches on a public benchmark.
  2. [§III.C and §V.C] The 'code diff matching' methodology is used both to label the online feedback training data (§III.B.2) and to measure online adoption (§III.C), so the production metrics are not independent of the training loop. A patch that is contained in the user's final diff may be accepted for reasons other than semantic correctness; containment does not verify that the fix preserves behavior or is the fix the developer would have written. The paper mentions in §V.C that senior engineers manually annotated real-production fixes (Figure 4), but it does not report the annotation sample size, selection procedure, or inter-rater agreement. Please provide these details, or an equivalent independent human evaluation, to support the online accuracy claims.
  3. [§IV.A and §IV.D (Table I)] The reported gains are based on a private test set with no confidence intervals and no comparison against existing automated program repair (APR) systems or public lint-repair benchmarks on the same data. The comparison in Table I is against base models and one SFT variant, not against prior fine-tuned or RL-trained APR methods. Furthermore, the paper does not state whether the 2,271 test samples are real production code or semi-synthetic samples generated with the same LLM-simulated dependencies used for the cold-start data; this distinction is essential because if the test set comes from the same semi-synthetic pipeline, the reported accuracy could partly reflect artifacts of that pipeline. Please add significance tests, confidence intervals, or an evaluation on a publicly available dataset, and clarify the provenance of the test set.
minor comments (7)
  1. [§I] The sentence 'we propose an streamlined LLM-based workflow' should use 'a streamlined'.
  2. [§III.B.3, Eq. (6)] The symbol π in Eq. (6) is used as an indicator function but is never defined; please define it explicitly as an indicator that r_p(C) > 0.
  3. [§III.B.3, Eq. (5)] The F_β term in Eq. (5) is not defined in the text; please provide the formula or a precise reference to its definition in [37].
  4. [§IV.E, Table II] The 'Graded Reward' row description says '0 points for compilation failure, 0.3 points for successful compilation, 1 point for complete fix', which is inconsistent with the reward decomposition in Eqs. (4)-(5); please clarify whether the correctness component is included in the 'Graded Reward' row or only in the full reward with redundancy penalty.
  5. [§V.C, Figure 4] The caption of Figure 4 appears to contain garbled text (a sequence of '/uni00000039/...' tokens); this should be cleaned up in the published version.
  6. [§V.B] The phases 'Before May' and 'After May' lack a year, which makes the timeline ambiguous; please specify the year or the exact dates.
  7. [References [39]] Reference [39] is titled 'HybridFlow', but the text in §IV.C says the model was trained using the 'verl' framework; please verify that this reference correctly corresponds to verl or update the citation.

Circularity Check

2 steps flagged · score 5.0 of 10

Offline Fix Accuracy is the same compile-plus-lint-pass condition as the RL reward, so the reported 84.68% is an in-loop optimization result rather than an independent correctness measure.

  1. fitted input called prediction [Section III.B.3 (Eqs. 4-5) and Section IV.B (Eq. 7)]
    "Fix Accuracy. Defined as the proportion of model-generated patches that successfully compile and pass the original lint error scanning when applied to the problematic code. ... rc(C) = ( +0.7, if C is cold-start data and fail-to-pass ... )"

    The offline Fix Accuracy metric (Eq. 7) is the boolean condition 'compiles and passes the original lint scan.' The cold-start RL reward (Eqs. 4-5) is exactly the same verifier: a compilable precheck plus a fail-to-pass lint condition. The model is therefore trained to maximize the same signal that is later reported as accuracy, so the jump from 53.76% to 84.68% is substantially a measure of reward optimization, not an independent check of semantic repair correctness. The paper itself concedes in Section III.B.2 that compilation and lint scanning 'cannot truly guarantee the absolute correctness of the generated code fixes.'

  2. fitted input called prediction [Section III.C and Section V.C]
    "When the LLM-generated diff patch is completely encompassed within the user’s actual submitted diff, we classify the fix as adopted. ... Through training our reinforcement learning loop based on this feedback mechanism over a two-month iteration period, we generated patches that more closely aligned with developers’ authentic coding and remediation practices."

    The same code-diff containment rule that labels user-feedback training data is also the rule used to measure online adoption and to count the 12,000 'resolved' issues. The model is trained to produce patches that are contained in the user's final diff, and the deployment metrics are then computed with that same containment criterion. Thus the online effectiveness numbers are not measured against an independent standard: a user can accept a patch that silences the lint warning but changes behavior, and containment in the final diff does not verify semantic safety.

full rationale

The paper contains no mathematical derivation whose conclusion is its premise; it is an industrial deployment report. However, two evaluation loops reduce to their own training signals. First, the headline offline Fix Accuracy (Eq. 7) is defined as the share of patches that compile and pass the original lint scan, which is precisely the verifier used as the cold-start RL reward (Eqs. 4-5). The reported improvement therefore shows that the model learned to optimize the reward, not that the patches are semantically correct; the authors explicitly acknowledge this limitation. Second, the online 'adoption' metric is defined by containment of the generated diff in the user's final diff, and the same containment rule is used to label feedback data for RL training. The production counts are thus generated by the same criterion the model was trained to satisfy. These are validity and evaluation-circularity concerns rather than formal self-citation or uniqueness-theorem issues, and the paper is self-contained against its own workflow; but because the central quantitative claims are defined by the training objectives, the result is partially forced by construction. Score 5 reflects that partial circularity without escalating to full definitional equivalence.

Assumptions & free parameters 6 free parameters · 5 assumptions · 1 invented entities

The central empirical result depends on several hand-set reward weights, selection thresholds, and two domain assumptions: that lint-pass verification approximates correctness, and that LLM-simulated dependencies behave like real packages. These are not fitted or externally validated, so the headline 84.68% accuracy is not independently anchored.

free parameters (6)
  • reward weights in Eqs. 3-5 (0.3 compile, 0.7 correctness, 0.1 format/redundancy) = 0.3, 0.7, 0.1
    Hand-set in §III.B.3; the paper provides no sensitivity analysis, and these weights directly determine the RL gradient.
  • redundancy penalty per extra patch = 0.1
    In Eq. 3; chosen by hand; the ablation only tests presence or absence of the penalty, not different magnitudes.
  • difficulty-filter threshold: number of repair attempts per sample = 8
    In §III.B.1; samples where all eight repair attempts succeed are excluded as too simple; no sensitivity analysis.
  • per-category sample cap for cold-start data = 30
    In §III.B.1; balancing heuristic, no analysis of the optimal cap.
  • maximum retries for failed patch validations = 3
    In §III.A; default value, no ablation.
  • F_beta coefficient in feedback-data reward = not specified
    Eq. 5 uses F_beta per [37], but the beta value and matching threshold are not stated; they affect feedback-data rewards.
assumptions (5)
  • domain assumption A patch that compiles and passes the original lint scan is treated as a correct fix in both offline accuracy and cold-start rewards.
    Stated in §IV.B (Eq. 7) and §III.B.3; the authors note in §III.B.2 that compilation and lint scanning cannot guarantee absolute correctness.
  • domain assumption Function-level tree-sitter context plus one layer of dependencies is sufficient for generating correct lint fixes.
    Assumed in §III.A Context Extraction; the conclusion itself notes that the current context scope is limited to single-layer function nesting.
  • ad hoc to paper LLM-simulated virtual dependencies for third-party packages preserve enough semantic information for verifiable cold-start samples.
    In §III.B.1 Minimal Dependencies Construction; no validation of simulated dependencies against real dependencies is reported.
  • domain assumption A user fix is considered adopted iff the LLM-generated diff is completely contained in the user's final committed diff.
    In §III.C; this proxy can overcount (independent identical edits) and undercount (partial adoption or IDE modifications) true acceptance.
  • standard math GRPO with the stated rule-based rewards improves code repair behavior as expected from prior work.
    Eq. 1 uses GRPO from [10] and [39]; the paper does not re-derive convergence or stability properties.
invented entities (1)
  • LLM-simulated virtual dependencies for third-party packages
    purpose: Used in cold-start sample construction to make small examples executable without fetching real package code.
    No experiment validates that fixes trained on samples with simulated dependencies transfer to code with real dependencies; the paper only reports overall system accuracy.

how reviews work

0 comments
Cite this review

Pith. "Pith review of BitsAI-Fix: LLM-Driven Approach for Automated Lint Error Resolution in Practice." pith.science (2026). https://pith.science/paper/R5XSOBMS

@misc{pith2026250803487,
  author       = {Pith},
  title        = {Pith review of: BitsAI-Fix: LLM-Driven Approach for Automated Lint Error Resolution in Practice},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/R5XSOBMS}},
  note         = {Machine review of arXiv:2508.03487}
}
read the original abstract

As enterprise codebases continue to grow in scale and complexity, the volume of lint errors far exceeds engineers' manual remediation capacity, leading to continuous accumulation of technical debt and hindered development efficiency. This paper presents BitsAI-Fix, an automated lint error remediation workflow based on Large Language Models (LLMs), designed to address this critical challenge in industrial-scale environments. BitsAI-Fix employs tree-sitter for context expansion and generates search-and-replace format patches through specially trained LLMs, followed by lint scan re-verification to output final remediation results. Additionally, our approach introduces an innovative progressive reinforcement learning (RL) training strategy that can automatically acquire verifiable training data during the project cold-start phase and continuously iterate the model by collecting online samples through feedback after system deployment. Furthermore, we designed a targeted rule-based reward mechanism that combines format rewards and correctness rewards while penalizing redundant modifications. We also propose a "code diff matching" methodology to continuously track online effectiveness. In production deployment at ByteDance, our solution has supported over 5,000 engineers, resolved more than 12,000 static analysis issues, achieved approximately 85% remediation accuracy, with around 1,000 weekly active adopters. This work demonstrates the practical feasibility of LLM-based code remediation solutions in enterprise environments and serves as a reference for automated code fix in large-scale industrial scenarios.

Figures

Figures reproduced from arXiv: 2508.03487 by the authors.

Figure 1
Figure 1. Framework of BitAI-Fix, including Lint Error Fix Workflow and Model Training. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Search Replace format for patch generation [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Main interface of the automated code-fix tool embedded in the MR review page. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: Trend of Weekly Active Adopters and Weekly Adoption [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 4
Figure 4. Figure 4: Performance improvement of model optimized using [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 6
Figure 6. Figure 6: BitsAI-Fix Adding Panic Recovery Mechanism to Goroutine [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: BitsAI-Fix Converting Unsafe Type Assertion to Safe Checked Form [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: BitsAI-Fix Over-eager Patch with Excessive Modifications [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

40 extracted references · 16 canonical work pages

  1. [1]

    A survey of learning-based automated program repair,

    Q. Zhang, C. Fang, Y . Ma, W. Sun, and Z. Chen, “A survey of learning-based automated program repair,”ACM Trans. Softw. Eng. Methodol., vol. 33, no. 2, Dec. 2023. [Online]. Available: https://doi.org/10.1145/3631974

    doi:10.1145/3631974 2023

  2. [2]

    Shaping program repair space with existing patches and similar code,

    J. Jiang, Y . Xiong, H. Zhang, Q. Gao, and X. Chen, “Shaping program repair space with existing patches and similar code,” inProceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2018. New York, NY , USA: Association for Computing Machinery, 2018, p. 298–309. [Online]. Available: https://doi.org/10.1145/3...

    arXiv 2018

  3. [3]

    Crsearcher: Searching code database for repairing bugs,

    Y . Wang, Y . Chen, B. Shen, and H. Zhong, “Crsearcher: Searching code database for repairing bugs,” inProceedings of the 9th Asia-Pacific Symposium on Internetware, ser. Internetware ’17. New York, NY , USA: Association for Computing Machinery, 2017. [Online]. Available: https://doi.org/10.1145/3131704.3131720

    work page arXiv 2017

  4. [4]

    Automated program repair in the era of large pre-trained language models,

    C. S. Xia, Y . Wei, and L. Zhang, “Automated program repair in the era of large pre-trained language models,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), 2023, pp. 1482–1494

    work page 2023

  5. [5]

    Evaluating large language models in class-level code generation,

    X. Du, M. Liu, K. Wang, H. Wang, J. Liu, Y . Chen, J. Feng, C. Sha, X. Peng, and Y . Lou, “Evaluating large language models in class-level code generation,” in2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE), 2024, pp. 982–994

    work page 2024

  6. [6]

    Code llama: Open foundation models for code,

    B. Rozi `ere, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y . Adi, J. Liu, R. Sauvestre, T. Remez, J. Rapin, A. Kozhevnikov, I. Evtimov, J. Bitton, M. Bhatt, C. C. Ferrer, A. Grattafiori, W. Xiong, A. D ´efossez, J. Copet, F. Azhar, H. Touvron, L. Martin, N. Usunier, T. Scialom, and G. Synnaeve, “Code llama: Open foundation models for code,” 20...

    arXiv 2024

  7. [7]

    Codegen: An open large language model for code with multi-turn program synthesis,

    E. Nijkamp, B. Pang, H. Hayashi, L. Tu, H. Wang, Y . Zhou, S. Savarese, and C. Xiong, “Codegen: An open large language model for code with multi-turn program synthesis,” 2023. [Online]. Available: https://arxiv.org/abs/2203.13474

    arXiv 2023

  8. [8]

    Bitsai-cr: Automated code review via llm in practice,

    T. Sun, J. Xu, Y . Li, Z. Yan, G. Zhang, L. Xie, L. Geng, Z. Wang, Y . Chen, Q. Lin, W. Duan, and K. Sui, “Bitsai-cr: Automated code review via llm in practice,” 2025. [Online]. Available: https://arxiv.org/abs/2501.15134

    arXiv 2025

Show all 40 references
  1. [9]

    Pdc & dm-sft: A road for llm sql bug-fix enhancing,

    Y . Duan, Y . Yu, X. Zhao, Y . Wu, and W. Liu, “Pdc & dm-sft: A road for llm sql bug-fix enhancing,” 2024. [Online]. Available: https://arxiv.org/abs/2411.06767

    2024 arXiv

  2. [10]

    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 . K. Li, Y . Wu, and D. Guo, “Deepseekmath: Pushing the limits of mathematical reasoning in open language models,” 2024. [Online]. Available: https://arxiv.org/abs/2402.03300

    2024 arXiv

  3. [11]

    A unified debugging approach via llm-based multi-agent synergy,

    C. Lee, C. S. Xia, L. Yang, J. tse Huang, Z. Zhu, L. Zhang, and M. R. Lyu, “A unified debugging approach via llm-based multi-agent synergy,” 2024. [Online]. Available: https://arxiv.org/abs/2404.17153

    2024

  4. [12]

    Executable code actions elicit better llm agents,

    X. Wang, Y . Chen, L. Yuan, Y . Zhang, Y . Li, H. Peng, and H. Ji, “Executable code actions elicit better llm agents,” 2024. [Online]. Available: https://arxiv.org/abs/2402.01030

    2024 arXiv

  5. [13]

    Fixing function-level code generation errors for foundation large language models,

    H. Wen, Y . Zhu, C. Liu, X. Ren, W. Du, and M. Yan, “Fixing function-level code generation errors for foundation large language models,” 2025. [Online]. Available: https://arxiv.org/abs/2409.00676

    2025 arXiv

  6. [14]

    S3: syntax- and semantic-guided repair synthesis via programming by examples,

    X.-B. D. Le, D.-H. Chu, D. Lo, C. Le Goues, and W. Visser, “S3: syntax- and semantic-guided repair synthesis via programming by examples,” inProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ser. ESEC/FSE 2017. New York, NY , USA: Association f...

    2017

  7. [15]

    Enhancing automated program repair with deductive verification,

    X.-B. D. Le, Q. L. Le, D. Lo, and C. Le Goues, “Enhancing automated program repair with deductive verification,” in2016 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2016, pp. 428–432

    2016

  8. [16]

    Automatic patch generation learned from human-written patches,

    D. Kim, J. Nam, J. Song, and S. Kim, “Automatic patch generation learned from human-written patches,” inProceedings of the 2013 International Conference on Software Engineering, ser. ICSE ’13. IEEE Press, 2013, p. 802–811

    2013

  9. [17]

    History driven program repair,

    X. B. D. Le, D. Lo, and C. Le Goues, “History driven program repair,” in2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), vol. 1, 2016, pp. 213–224

    2016

  10. [18]

    Fixminer: Mining relevant fix patterns for automated program repair,

    A. Koyuncu, K. Liu, T. F. Bissyand ´e, D. Kim, J. Klein, M. Monperrus, and Y . Le Traon, “Fixminer: Mining relevant fix patterns for automated program repair,”Empirical Softw. Engg., vol. 25, no. 3, p. 1980–2024, May 2020. [Online]. Available: https://doi.org/10.1007/s10664-01...

    1980 doi

  11. [19]

    An empirical study on learning bug-fixing patches in the wild via neural machine translation,

    M. Tufano, C. Watson, G. Bavota, M. D. Penta, M. White, and D. Poshyvanyk, “An empirical study on learning bug-fixing patches in the wild via neural machine translation,”ACM Trans. Softw. Eng. Methodol., vol. 28, no. 4, Sep. 2019. [Online]. Available: https://doi.org/10.1145/3340544

    2019 doi

  12. [20]

    Sorting and transforming program repair ingredients via deep learning code similarities,

    M. White, M. Tufano, M. Mart ´ınez, M. Monperrus, and D. Poshyvanyk, “Sorting and transforming program repair ingredients via deep learning code similarities,” in2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2019, pp. 479–490

    2019

  13. [21]

    Dlfix: Context-based code trans- formation learning for automated program repair,

    Y . Li, S. Wang, and T. N. Nguyen, “Dlfix: Context-based code trans- formation learning for automated program repair,” in2020 IEEE/ACM 42nd International Conference on Software Engineering (ICSE), 2020, pp. 602–614

    2020

  14. [22]

    Coconut: combining context-aware neural translation models using ensemble for program repair,

    T. Lutellier, H. V . Pham, L. Pang, Y . Li, M. Wei, and L. Tan, “Coconut: combining context-aware neural translation models using ensemble for program repair,” inProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2020. New ...

    2020

  15. [23]

    Automated program repair in the era of large pre-trained language models,

    C. S. Xia, Y . Wei, and L. Zhang, “Automated program repair in the era of large pre-trained language models,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, May 2023, p. 1482–1494. [Online]. Available: http://dx.doi.org/10.1109/ICSE48619.2023.00129

    2023

  16. [24]

    Pre-trained model-based automated software vulnerability repair: How far are we?

    Q. Zhang, C. Fang, B. Yu, W. Sun, T. Zhang, and Z. Chen, “Pre-trained model-based automated software vulnerability repair: How far are we?” IEEE Transactions on Dependable and Secure Computing, vol. 21, no. 4, pp. 2507–2525, 2024

    2024

  17. [25]

    How effective are neural networks for fixing security vulnerabilities,

    Y . Wu, N. Jiang, H. V . Pham, T. Lutellier, J. Davis, L. Tan, P. Babkin, and S. Shah, “How effective are neural networks for fixing security vulnerabilities,” inProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2023. New ...

    2023

  18. [26]

    Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution,

    Y . Wei, O. Duchenne, J. Copet, Q. Carbonneaux, L. Zhang, D. Fried, G. Synnaeve, R. Singh, and S. I. Wang, “Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution,”

  19. [27]

    Code security vulnerability repair using reinforcement learning with large language models,

    N. T. Islam, M. B. Karkevandi, and P. Najafirad, “Code security vulnerability repair using reinforcement learning with large language models,” 2024. [Online]. Available: https://arxiv.org/abs/2401.07031

    2024 arXiv

  20. [28]

    Compilable neural code generation with compiler feedback,

    X. Wang, Y . Wang, Y . Wan, F. Mi, Y . Li, P. Zhou, J. Liu, H. Wu, X. Jiang, and Q. Liu, “Compilable neural code generation with compiler feedback,” inFindings of the Association for Computational Linguistics: ACL 2022, S. Muresan, P. Nakov, and A. Villavicencio, Eds. Dublin, ...

    2022

  21. [29]

    Rltf: Reinforcement learning from unit test feedback,

    J. Liu, Y . Zhu, K. Xiao, Q. Fu, X. Han, W. Yang, and D. Ye, “Rltf: Reinforcement learning from unit test feedback,” 2023. [Online]. Available: https://arxiv.org/abs/2307.04349

    2023 arXiv

  22. [30]

    SWE-bench: Can language models resolve real-world github issues?

    C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. R. Narasimhan, “SWE-bench: Can language models resolve real-world github issues?” inThe Twelfth International Conference on Learning Representations, 2024. [Online]. Available: https://openreview.net/forum?id=...

    2024

  23. [31]

    Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,

    J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated soft- ware engineering,”Advances in Neural Information Processing Systems, vol. 37, pp. 50 528–50 652, 2024

    2024

  24. [32]

    Agentless: De- mystifying llm-based software engineering agents,

    C. S. Xia, Y . Deng, S. Dunn, and L. Zhang, “Agentless: De- mystifying llm-based software engineering agents,”arXiv preprint arXiv:2407.01489, 2024

    2024 arXiv

  25. [33]

    Crashfixer: A crash resolution agent for the linux kernel,

    A. Mathai, C. Huang, S. Ma, J. Kim, H. Mitchell, A. Nogikh, P. Maniatis, F. Ivan ˇci´c, J. Yang, and B. Ray, “Crashfixer: A crash resolution agent for the linux kernel,” 2025. [Online]. Available: https://arxiv.org/abs/2504.20412

    2025 arXiv

  26. [34]

    Dr.fix: Automatically fixing data races at industry scale,

    F. Behrang, Z. Zhang, G.-V . Saioc, P. Liu, and M. Chabbi, “Dr.fix: Automatically fixing data races at industry scale,” 2025. [Online]. Available: https://arxiv.org/abs/2504.15637

    2025 arXiv

  27. [35]

    Migrating code at scale with llms at google,

    C. Ziftci, S. Nikolov, A. Sj ¨ovall, B. Kim, D. Codecasa, and M. Kim, “Migrating code at scale with llms at google,” 04 2025

    2025

  28. [36]

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

    DeepSeek-AI, “Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning,” 2025. [Online]. Available: https://arxiv.org/abs/2501.12948

    2025 arXiv

  29. [37]

    Sorft: Issue resolving with subtask-oriented reinforced fine-tuning,

    Z. Ma, C. Peng, P. Gao, X. Meng, Y . Zou, and B. Xie, “Sorft: Issue resolving with subtask-oriented reinforced fine-tuning,” 2025. [Online]. Available: https://arxiv.org/abs/2502.20127

    2025 arXiv

  30. [38]

    Qwen2.5-coder technical report,

    B. Hui, J. Yang, Z. Cui, J. Yang, D. Liu, L. Zhang, T. Liu, J. Zhang, B. Yu, K. Lu, K. Dang, Y . Fan, Y . Zhang, A. Yang, R. Men, F. Huang, B. Zheng, Y . Miao, S. Quan, Y . Feng, X. Ren, X. Ren, J. Zhou, and J. Lin, “Qwen2.5-coder technical report,” 2024. [Online]. Available: ...

    2024 arXiv

  31. [39]

    Hybridflow: A flexible and efficient rlhf framework,

    G. Sheng, C. Zhang, Z. Ye, X. Wu, W. Zhang, R. Zhang, Y . Peng, H. Lin, and C. Wu, “Hybridflow: A flexible and efficient rlhf framework,”arXiv preprint arXiv: 2409.19256, 2024

    2024 arXiv

  32. [2025]

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

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

    arXiv

Pith tools

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