Pith. sign in

REVIEW 4 major objections 4 minor 32 references

Training Language Models to Generate Quality Code with Program Analysis Feedback

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

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

Pith's one-line read Program analysis rewards train LLMs to write secure, correct code

desk verdict The idea is new but the quality signal is circular; still worth refereeing. read the letter →

arxiv 2505.22704 v1 pith:CO7ETHFG submitted 2025-05-28 cs.CL cs.AI

Feng Yao , Zilong Wang , Liyuan Liu , Junxia Cui , Li Zhong , Xiaohan Fu , Haohui Mai , Vish Krishnan
show 2 more authors
Jianfeng Gao Jingbo Shang
This is my paper
classification cs.CLcs.AI
keywords codegenerationreinforcementlearningprogramanalysissecurityvulnerabilitiesmaintainabilityrewardshapingtaintLLMalignment
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

This paper is trying to establish that reinforcement learning with automated program-analysis feedback can train code-generating language models to be both functionally correct and production-safe—secure against common vulnerabilities and maintainable—without human-written reference solutions. It proposes REAL, which feeds a binary vulnerability-detector signal (covering 18 CWEs plus maintainability checks via MyPy) and a unit-test pass rate into a PPO training loop. The authors argue this hybrid reward fixes the failure modes of single-objective training: quality-only rewards cause reward hacking (empty or trivial code), while functionality-only rewards ignore security. Experiments across SecCodePLT+, SafeSQL, and APPS+ at 0.5B, 3B, and 7B scales show REAL matching or beating supervised fine-tuning and decoding-time filtering baselines on joint functionality-quality metrics. If true, this makes scalable, reference-free training signals available for production-oriented code generation.

What carries the argument

The load-bearing object is the hybrid reward $r_{\text{hybrid}} = \alpha\, r_{\text{quality}} + (1-\alpha)\, r_{\text{function}}$, computed from two automated verifiers. The vulnerability detector implements information-flow analysis: it parses generated code into a control-flow graph in SSA form, marks user inputs and database or OS APIs as sources and sinks, and conservatively propagates taint, treating a path from source to sink without recognized sanitization as a vulnerability. Maintainability is scored by MyPy's static type checker, which reports missing annotations and type errors. The same detector is used as both the RL reward and the evaluation metric, which makes the training signal cheap and reference-free but also means that evaluation and reward share the same blind spots.

What would settle it

Take code that REAL-trained models generate on SafeSQL and SecCodePLT+, run the detector, and then have independent security analysts or a different tool (for example, a real SQL injection exploit attempt) assess the same code; if a substantial fraction of detector-passing programs is exploitable, the quality claim is an artifact of the detector's heuristics.

Watch

Extended reading notes

Core claim

The central claim is that program analysis—the same static-analysis technique used to audit code—can serve as a training-time reward signal that steers LLMs away from security and maintainability defects without sacrificing functional correctness. REAL's reward is $r_{\text{hybrid}} = \alpha\, r_{\text{quality}} + (1-\alpha)\, r_{\text{function}}$, where $r_{\text{quality}}$ comes from a purpose-built detector that converts generated code to static single assignment (SSA) form and traverses a control-flow graph to find data flows from untrusted user inputs to sensitive sinks (for security) and runs MyPy to flag missing type annotations, unreachable code, or inconsistent function signatures (for maintainability). $r_{\text{function}}$ is the fraction of unit tests passed, and non-runnable code gets a $-1$ penalty. Trained with PPO, the policy learns to emit parameterized queries, proper input conversion, and type-annotated functions. The paper reports that REAL achieves the best joint functionality-quality pass rate on all three benchmarks at 3B and 7B, and on SafeSQL at all scales, outperforming SFT baselines and decoding-time filters.

Load-bearing premise

The detector's verdict that code is vulnerability-free is never validated against independent ground truth, so the reported quality gains presuppose that 'passes the detector' genuinely means 'secure and maintainable in production.'

Editorial extensions

If this is right

  • REAL's training recipe yields the best joint functionality-quality pass rates on SafeSQL at all three model scales, and on SecCodePLT+ and APPS+ at 3B and 7B.
  • Code quality can be optimized from program-analysis feedback alone (plus functional tests), eliminating the need for human-authored reference solutions for security and maintainability.
  • The same RL setup, retargeted with detectors for other CWE classes, should generalize to more vulnerability types because the detector machinery is shared.
  • Joint quality-functionality benchmarks (SecCodePLT+, SafeSQL, APPS+) provide a unified assessment protocol for production-oriented code generation.

Reading between the lines

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

  • Because REAL uses the same detector for training and evaluation, its reported gains may partly reflect overfitting to the detector's specific heuristics; an independent validation against human-annotated vulnerabilities would test how much of the gain transfers to real-world security.
  • The hybrid reward's $\alpha$ could be annealed over training, starting with a low quality weight to let functionality stabilize and then increasing it; the case study's observation that quality saturates first suggests this could improve sample efficiency without hurting the joint metric.
  • The detector is context-insensitive and flow-sensitive, so long, multi-file, or library-heavy code may defeat its taint analysis; applying REAL to repository-scale generation tasks may require a scalable interprocedural analysis.
  • SafeSQL is evolved from seed programs with GPT-4.1, so its distribution may reflect LLM biases; a purely human-collected SQL benchmark would test whether REAL's advantage holds on more realistic query tasks.
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

4 major / 4 minor

Summary. The paper proposes REAL, a reinforcement learning framework for code generation that combines two automated reward signals: a program-analysis-based detector that flags security and maintainability defects, and unit-test pass rate for functional correctness. The two signals are combined into a hybrid reward and used to fine-tune Qwen2.5-Coder-Instruct models at 0.5B, 3B, and 7B scales via PPO. The authors introduce or extend three datasets (SecCodePLT+, SafeSQL, APPS+) and report improvements over supervised fine-tuning, decoding-time filtering, and prompt-based baselines on functionality, quality, and a joint functionality-quality metric.

Significance. If the reported gains are real, REAL would be a valuable contribution: it is prompt-agnostic and reference-free, avoids manual annotation of vulnerable code, and demonstrates that program analysis can serve as a scalable RL reward. The datasets and holistic evaluation protocol are also potentially useful to the community. However, the central evaluation rests on a circular design: the same detector provides the quality reward in Eq. (1) and defines the quality columns in Tables 2, 3, and 4, and that detector is never validated against independent ground truth. The paper's own quality-only ablation in Table 4 shows that the detector signal can be trivially gamed (empty or minimal programs receive near-perfect quality scores), which reinforces the need for independent validation before the comparative claim is accepted.

major comments (4)
  1. [§3.1, §3.2 Eq. (1), §4.1] The vulnerability detector is used both as the RL reward (r_quality in Eq. (1)) and as the evaluation metric for the 'Quality' and 'Func.-Qual.' columns in Tables 2, 3, and 4. This circularity means that improvements in quality may reflect overfitting to the detector's specific heuristics rather than genuine security or maintainability. The manuscript states in §3.1 that the detector prioritizes soundness over precision and uses 'heuristics to conservatively identify sanitation,' and §6 concedes that detectors are heuristic and incomplete, but no precision/recall numbers, no comparison against independent ground truth, and no manual audit are reported. To support the abstract's claim of improved code quality, the authors should validate the detector on a labeled set of vulnerable and clean programs, report its false-positive and false-negative rates, compare it with existing tools such as CodeQL or Bandit, and independently assess a sample of REAL-generated code (e.g., through manual review or a held-out oracle not used in training).
  2. [§3.2, Eq. (2)] The hybrid reward in Eq. (2) is r_hybrid = alpha * r_quality + (1-alpha) * r_function, but the value of alpha is never disclosed, and no sensitivity analysis is provided. Since the balance between quality and functionality is the key design choice, the reported results are only meaningful for a single unreported setting. The authors should report alpha for each dataset and include an ablation over alpha values to show that the conclusions are not an artifact of one particular weighting.
  3. [§4.2, Tables 2 and 3] The comparative results are reported as single point estimates with no variance, confidence intervals, or significance tests. This is especially important for SafeSQL, which has only 85 test tasks (Table 1); for example, the 3B SafeSQL Quality score of 1.0000 for REAL versus 0.9176 for SFT corresponds to a difference of about 7 tasks, which may not be statistically meaningful. The authors should run multiple training seeds and report means and standard deviations, or at least provide per-task breakdowns and a statistical test such as bootstrap or McNemar's test.
  4. [§4.1, SafeSQL and APPS+ construction] SafeSQL is constructed by evolving seed programs with GPT-4.1, and APPS+ is created by 'filtering and verifying a subset of APPS,' but the verification process is not described. If the ground-truth safe solutions and the CWE labels are themselves generated by LLMs or by the same detector family used for training and evaluation, then the benchmarks could inherit systematic biases. The authors should specify how each task's expected solution and vulnerability label were verified, ideally with human annotation or an independent tool, and report inter-annotator agreement where applicable.
minor comments (4)
  1. [§1 and §3.1] The introduction states that the detector covers 17 CWEs, while §3.1 says 'a total of 18 CWEs' and Appendix A.1 lists 18 entries; this discrepancy should be fixed.
  2. [Table 4] The notation 'w/rFunction' and 'w/rquality' is inconsistent with the body text's r_function and r_quality; use uniform notation and define the abbreviations in the table caption.
  3. [Eq. (1)] The indicator notation in the functionality reward is missing a closing parenthesis in '1 {fˆy(inpi) =outi}'; the expression should be cleaned up for clarity.
  4. [References] The reference 'Frank Xu et al. Windsurf: Empowering developers with AI-assisted code completion' appears to be incomplete or misattributed; please verify the author list and venue.

Circularity Check

1 steps flagged · score 6.0 of 10

The quality axis of the central claim reduces by construction: the same program-analysis detector provides the RL reward and the evaluation metric, so 'quality' gains are measured on the exact signal the model was trained to maximize, without independent validation.

  1. fitted input called prediction [Section 3.2 (Quality Reward) and Section 4.1 (Evaluation)]
    "We pass the generated candidate program ŷ through our curated vulnerability detector to check whether it is safe in terms of security or maintainability. We denote the reward provided by the detector as rquality = Detector(ŷ) = 1, if no vulnerabilities are detected, 0 otherwise ... For each dimension, we report the Pass Rate as the metric, representing the percentage of tasks that pass all the unit tests or pass the vulnerability detector, respectively."

    The detector is both the training objective and the evaluation instrument: r_quality is exactly the binary detector output, and the reported 'Quality' and 'Func.-Qual.' metrics are computed by running that same detector on generated code. Since REAL is trained with PPO to maximize r_quality, its high quality scores are by construction high detector-pass rates.

full rationale

The main comparative claim—REAL improves functionality and code quality jointly—is partially circular on the quality axis. Section 3.2 defines r_quality = Detector(ŷ), and Section 4.1 defines the reported quality Pass Rate as the fraction of programs that 'pass the vulnerability detector.' Because PPO training maximizes exactly this binary detector signal, the quality results in Tables 2 and 3 (e.g., SafeSQL 3B Quality 1.000) are the optimized objective, not an independent measurement. The detector is self-built, soundness-prioritized, and never precision/recall-validated against ground truth; the paper's own Section 6 acknowledges heuristic approximations and incomplete CWE coverage. Functionality, by contrast, is evaluated by held-out unit tests independent of the training reward, so the functionality axis is not circular. The joint metric inherits the detector circularity on the quality component. There is no self-citation chain here; the issue is the identity of the training objective and the evaluation instrument. This warrants a 6 rather than 0-2 because the central quality claim reduces by construction to detector optimization, though the hybrid design and independent unit tests give the work independent content on functionality.

Assumptions & free parameters 2 free parameters · 3 assumptions · 1 invented entities

The central claim relies on the validity of the program analysis detector, which is both the training reward and the evaluation metric. The reward weight alpha is undisclosed. The functionality improvement is more trustworthy because it is based on unit tests, but the quality dimension is circular.

free parameters (2)
  • alpha (hybrid reward weight)
    Coefficient blending quality and functionality rewards; value not reported, likely tuned on validation sets. It controls the trade-off and directly affects the final policy.
  • Detector sanitation heuristics
    Hand-crafted rules for recognizing sanitization (e.g., parameterized queries) that determine whether a data path is flagged. These thresholds are not described in detail and influence the quality reward.
assumptions (3)
  • domain assumption Detector soundness: the program analysis flags all real security/maintainability defects and does not falsely flag safe code
    Invoked in §3.1; the detector is used both as reward and eval metric, so any false negatives or positives bias the training and reported quality.
  • domain assumption Unit tests are correct and exhaustive for functional correctness
    Used in §3.2 as rfunction; if tests are incomplete, the functionality reward may not reflect true correctness.
  • domain assumption The LLM-evolved SafeSQL seed programs preserve task semantics and SQL vulnerability patterns
    SafeSQL is constructed with GPT-4.1 mutations (A.2); errors in this process would propagate into training and evaluation.
invented entities (1)
  • REAL vulnerability detector
    purpose: Program analysis tool for 18 CWEs and maintainability issues, used as reward signal and evaluation metric
    No external validation is provided; the paper relies on its own implementation and the same detector appears on both sides of training and evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Training Language Models to Generate Quality Code with Program Analysis Feedback." pith.science (2026). https://pith.science/paper/CO7ETHFG

@misc{pith2026250522704,
  author       = {Pith},
  title        = {Pith review of: Training Language Models to Generate Quality Code with Program Analysis Feedback},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CO7ETHFG}},
  note         = {Machine review of arXiv:2505.22704}
}
read the original abstract

Code generation with large language models (LLMs), often termed vibe coding, is increasingly adopted in production but fails to ensure code quality, particularly in security (e.g., SQL injection vulnerabilities) and maintainability (e.g., missing type annotations). Existing methods, such as supervised fine-tuning and rule-based post-processing, rely on labor-intensive annotations or brittle heuristics, limiting their scalability and effectiveness. We propose REAL, a reinforcement learning framework that incentivizes LLMs to generate production-quality code using program analysis-guided feedback. Specifically, REAL integrates two automated signals: (1) program analysis detecting security or maintainability defects and (2) unit tests ensuring functional correctness. Unlike prior work, our framework is prompt-agnostic and reference-free, enabling scalable supervision without manual intervention. Experiments across multiple datasets and model scales demonstrate that REAL outperforms state-of-the-art methods in simultaneous assessments of functionality and code quality. Our work bridges the gap between rapid prototyping and production-ready code, enabling LLMs to deliver both speed and quality.

Figures

Figures reproduced from arXiv: 2505.22704 by the authors.

Figure 1
Figure 1. Overview of the REAL framework. Given a coding task, the LLM policy generates a candidate program, which is then evaluated along two automated axes: (1) Vulnerability Detector applies program analysis to flag security and maintainability defects, (2) Functionality Verifier runs unit tests to assess correctness. The two reward signals are averaged and fed into a policy-gradient update, steering the LLM toward high-qu… view at source ↗
Figure 2
Figure 2. Maintainability issues detected by MyPy Maintainability Vulnerability. Beyond secu￾rity vulnerabilities, we also address maintain￾ability requirements essential to modern soft￾ware development, where generated code must follow strict standards to ensure long-term reli￾ability. Such requirements include, but are not limited to, enforcing proper type annotations throughout the codebase, eliminating unused or redundant… view at source ↗
Figure 3
Figure 3. Examples of code generated by REAL 0.5B at different training stages on SafeSQL with hybrid rewards. Initially, the model produces incorrect and insecure code, misinterpreting "or" as AND and directly incorporating unsanitized user inputs. Later on, it adopts parameterized execution (using ? placeholders in the query with separate parameter binding) to implicitly address vulnerabilities. Finally, it corrects the que… view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

32 extracted references · 14 canonical work pages

  1. [1]

    Aho, Monica S

    Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman. Compilers: Principles, Techniques, and Tools (2nd Edition). Addison-Wesley Longman Publishing Co., Inc., USA, 2006. ISBN 0321486811

    work page 2006

  2. [2]

    Bearer: Static application security testing (sast) tool

    Bearer. Bearer: Static application security testing (sast) tool. https://github.com/Bearer/bearer, 2021. Accessed: 2025-05-15

    work page 2021

  3. [3]

    Purple llama cyberseceval: A secure coding benchmark for language models

    Manish Bhatt, Sahana Chennabasappa, Cyrus Nikolaidis, Shengye Wan, Ivan Evtimov, Dominik Gabi, Daniel Song, Faizan Ahmad, Cornelius Aschermann, Lorenzo Fontana, et al. Purple llama cyberseceval: A secure coding benchmark for language models. arXiv preprint arXiv:2312.04724, 2023

    arXiv 2023

  4. [4]

    A comprehensive study of llm secure code generation

    Shih-Chieh Dai, Jun Xu, and Guanhong Tao. A comprehensive study of llm secure code generation. arXiv preprint arXiv:2503.15554, 2025

    arXiv 2025

  5. [5]

    Stepcoder: Improve code generation with reinforcement learning from compiler feedback

    Shihan Dou, Yan Liu, Haoxiang Jia, Limao Xiong, Enyu Zhou, Wei Shen, Junjie Shan, Caishuang Huang, Xiao Wang, Xiaoran Fan, et al. Stepcoder: Improve code generation with reinforcement learning from compiler feedback. arXiv preprint arXiv:2402.01391, 2024

    arXiv 2024

  6. [6]

    Constrained decoding for secure code generation, 2024

    Yanjun Fu, Ethan Baker, Yu Ding, and Yizheng Chen. Constrained decoding for secure code generation, 2024. URL https://arxiv.org/abs/2405.00218

    arXiv 2024

  7. [7]

    Rlef: Grounding code llms in execution feedback with reinforcement learning, 2025

    Jonas Gehring, Kunhao Zheng, Jade Copet, Vegard Mella, Quentin Carbonneaux, Taco Cohen, and Gabriel Synnaeve. Rlef: Grounding code llms in execution feedback with reinforcement learning, 2025. URL https://arxiv.org/abs/2410.02089

    arXiv 2025

  8. [8]

    Codeql: Semantic code analysis engine

    GitHub. Codeql: Semantic code analysis engine. https://codeql.github.com/, 2019. Accessed: 2025-05-15

    work page 2019

Show all 32 references
  1. [9]

    Github copilot: Your ai pair programmer

    GitHub. Github copilot: Your ai pair programmer. https://github.blog/2021-06-29-github-copilot-ai-pair-programmer/, 2021

    2021

  2. [10]

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

    Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948, 2025

    2025 arXiv

  3. [11]

    Large language models for code: Security hardening and adversarial testing

    Jingxuan He and Martin Vechev. Large language models for code: Security hardening and adversarial testing. In ACM CCS, 2023. URL https://arxiv.org/abs/2302.05319

    2023 arXiv

  4. [12]

    Jingxuan He, Mark Vero, Gabriela Krasnopolska, and Martin T. Vechev. Instruction tuning for secure code generation. In Forty-first International Conference on Machine Learning, ICML 2024, Vienna, Austria, July 21-27, 2024 . OpenReview.net, 2024. URL https://openreview.net/foru...

    2024

  5. [13]

    Measuring coding challenge competence with apps

    Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, and Jacob Steinhardt. Measuring coding challenge competence with apps. NeurIPS, 2021

    2021

  6. [14]

    Binyuan Hui, Jian Yang, Zeyu Cui, Jiaxi Yang, Dayiheng Liu, Lei Zhang, Tianyu Liu, Jiajun Zhang, Bowen Yu, Kai Dang, et al. Qwen2. 5-coder technical report. arXiv preprint arXiv:2409.12186, 2024

    2024 arXiv

  7. [15]

    Code security vulnerability repair using reinforcement learning with large language models

    Nafis Tanveer Islam, Mohammad Bahrami Karkevandi, and Peyman Najafirad. Code security vulnerability repair using reinforcement learning with large language models. arXiv preprint arXiv:2401.07031, 2024

    2024 arXiv

  8. [16]

    Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven C. H. Hoi. Coderl: Mastering code generation through pretrained models and deep reinforcement learning, 2022. URL https://arxiv.org/abs/2207.01780

    2022 arXiv

  9. [17]

    Mypy: Optional static typing for python

    Jukka Lehtosalo. Mypy: Optional static typing for python. https://mypy-lang.org/, 2025. Version accessed: May 2025

    2025

  10. [18]

    Acecoder: An effective prompting technique specialized in code generation

    Jia Li, Yunfei Zhao, Yongmin Li, Ge Li, and Zhi Jin. Acecoder: An effective prompting technique specialized in code generation. ACM Transactions on Software Engineering and Methodology, 33 0 (8): 0 1--26, 2024

    2024

  11. [19]

    Wizardcoder: Empowering code large language models with evol-instruct

    Ziyang Luo, Can Xu, Pu Zhao, Qingfeng Sun, Xiubo Geng, Wenxiang Hu, Chongyang Tao, Jing Ma, Qingwei Lin, and Daxin Jiang. Wizardcoder: Empowering code large language models with evol-instruct. In The Twelfth International Conference on Learning Representations, 2024

    2024

  12. [20]

    Common weakness enumeration (cwe)

    MITRE . Common weakness enumeration (cwe). MITRE Corporation, 2024. URL https://cwe.mitre.org/index.html. Accessed: 2025-05-14. Version 2025a

    2024

  13. [21]

    Andrew C. Myers. Jflow: practical mostly-static information flow control. In Proceedings of the 26th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL '99, pages 228--241, New York, NY, USA, 1999. Association for Computing Machinery. ISBN 1581130953. do...

    1999

  14. [22]

    Promsec: Prompt optimization for secure generation of functional source code with large language models (llms)

    Mahmoud Nazzal, Issa Khalil, Abdallah Khreishah, and NhatHai Phan. Promsec: Prompt optimization for secure generation of functional source code with large language models (llms). In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, CCS '...

    2024

  15. [23]

    Gpt-4.1, 2025

    OpenAI. Gpt-4.1, 2025. https://openai.com/index/gpt-4-1/

    2025

  16. [24]

    Bandit: Security linter for python source code

    PyCQA. Bandit: Security linter for python source code. https://github.com/PyCQA/bandit, 2014. Accessed: 2025-05-15

    2014

  17. [25]

    Proximal policy optimization algorithms

    John Schulman, Filip Wolski, Prafulla Dhariwal, Alec Radford, and Oleg Klimov. Proximal policy optimization algorithms. arXiv preprint arXiv:1707.06347, 2017

    2017 arXiv

  18. [26]

    Cyberseceval 3: Advancing the evaluation of cybersecurity risks and capabilities in large language models, 2024

    Shengye Wan, Cyrus Nikolaidis, Daniel Song, David Molnar, James Crnkovich, Jayson Grace, Manish Bhatt, Sahana Chennabasappa, Spencer Whitman, Stephanie Ding, Vlad Ionescu, Yue Li, and Joshua Saxe. Cyberseceval 3: Advancing the evaluation of cybersecurity risks and capabilities...

    2024 arXiv

  19. [27]

    Yuxiang Wei, Olivier Duchenne, Jade Copet, Quentin Carbonneaux, Lingming Zhang, Daniel Fried, Gabriel Synnaeve, Rishabh Singh, and Sida I. Wang. Swe-rl: Advancing llm reasoning via reinforcement learning on open software evolution, 2025. URL https://arxiv.org/abs/2502.18449

    2025 arXiv

  20. [28]

    Teaching language models to critique via reinforcement learning

    Zhihui Xie, Liyu Chen, Weichao Mao, Jingjing Xu, Lingpeng Kong, et al. Teaching language models to critique via reinforcement learning. arXiv preprint arXiv:2502.03492, 2025

    2025

  21. [29]

    Windsurf: Empowering developers with ai-assisted code completion

    Frank Xu et al. Windsurf: Empowering developers with ai-assisted code completion. arXiv preprint arXiv:2212.10943, 2022

    2022 arXiv

  22. [30]

    Seccodeplt: A unified platform for evaluating the security of code genai, 2024

    Yu Yang, Yuzhou Nie, Zhun Wang, Yuheng Tang, Wenbo Guo, Bo Li, and Dawn Song. Seccodeplt: A unified platform for evaluating the security of code genai, 2024. URL https://arxiv.org/abs/2410.11096

    2024

  23. [31]

    B -coder: Value-based deep reinforcement learning for program synthesis, 2024

    Zishun Yu, Yunzhe Tao, Liyu Chen, Tao Sun, and Hongxia Yang. B -coder: Value-based deep reinforcement learning for program synthesis, 2024. URL https://arxiv.org/abs/2310.03173

    2024 arXiv

  24. [32]

    Seccoder: Towards generalizable and robust secure code generation

    Boyu Zhang, Tianyu Du, Junkai Tong, Xuhong Zhang, Kingsum Chow, Sheng Cheng, Xun Wang, and Jianwei Yin. Seccoder: Towards generalizable and robust secure code generation. arXiv preprint arXiv:2410.01488, 2024

    2024 arXiv

Pith tools

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