Fine-Tuning for Code Review
Where can fine-tuning LLMs improve AI code review? We reviewed research and engineering reports from Meta, Google, and others to understand where the evidence supports investing in fine-tuning.
TL;DR: trained models have shown useful results in comment resolution, and research also reports improvements in review-comment generation. Evidence that fine-tuning improves real-world bug detection remains limited in the sources reviewed here.
AI code review still has clear gaps
Independent research shows how much room for improvement remains. A study of more than 31,000 review comments found that developers rejected 56.3% of them on the pull requests they were reviewing [1]. SWE-PRBench found that tested models detected only 15–31% of human-flagged issues in its diff-only setting [2]. These findings point to ongoing challenges in producing useful feedback and detecting issues.
These gaps raise an important question for review products: which aspects of review quality can improve through learning from repository history and verified outcomes? Fine-tuning is one approach worth testing, and it is becoming cheaper to try.
Training is becoming more accessible
Recent experiments show that adapting open-weight models can take surprisingly few resources. None of them involves code review, and their costs do not reflect the full cost of building a production reviewer, but they show that small-scale adaptation is now practical.
Recent experiments show that adapting open-weight models can require fewer resources than full fine-tuning. Thinking Machines showed that LoRA, which updates a small fraction of a model’s parameters, can match full fine-tuning under the right post-training conditions [3]. Researchers at USC improved a 1.5B reasoning model using reinforcement learning (RL) for about $9 in training and evaluation costs [4], and Meta FAIR demonstrated that just 13 trainable parameters could substantially raised a 7B model’s accuracy on the GSM8K math benchmark from 76% to 91% [5].
Distillation offers another route: training a smaller model using a stronger teacher. In one Qwen3 experiment, this required roughly one-tenth the GPU-hours of direct RL and raised its AIME 2025 math score to 65.5% versus 55.5% [6].
Where fine-tuning has worked: resolving comments
The clearest production evidence assessed here comes from a specific task: given a review comment, propose a code change that addresses it.
Meta fine-tuned Llama models using 64,000 internal review-comment and patch pairs. In offline evaluation, its best model achieved a 68% exact-match rate against human-written fixes, 9 percentage points above GPT-4o. In production, AI-generated patches were applied for 19.7% of comments classified as actionable [7].
In an offline evaluation, Google’s internally trained system proposed fixes for 52% of review comments, with the threshold targeting 50%. That precision target means half of the suggested edits were correct on the evaluation dataset [8].
Meta and Google trained on review comments paired with the changes engineers made to address them, giving their models concrete examples of how to turn a request into a fix. Finding bugs requires the model to decide what needs attention in the first place, and the sources reviewed here do not establish whether fine-tuning improves that ability.
Where fine-tuning could take code review next
The comment-resolution results show what training on review history can do for a well-defined task. Three directions could extend that approach within review products.
1. Repository-specific adaptation
Review history captures a team’s conventions through the comments engineers leave and the patches that follow. The Meta and Google results show how valuable that history can be for comment resolution.
Review products could use similar data to adapt suggestions to a repository’s conventions and internal coding rules. Comment resolution provides a foundation for that direction; extending it to other review tasks would need its own evidence.
2. Learning from verified feedback
Review products also capture whether developers act on suggestions, dismiss them, or change the code. Those signals could help a reviewer learn which findings are useful to a team, and could help reduce unhelpful suggestions. Acceptance alone, however, is not a reliable reward: developers can dismiss valid findings or accept incorrect ones.
Combining developer behavior with code changes, automated checks, and verified outcomes could provide a stronger basis for learning. CRScore++ reports improvements in the relevance and comprehensiveness of generated review comments after supervised training and preference optimization using static-analysis signals and AI feedback. In the same study, models trained directly on historical comments from the CodeReviewer dataset scored below the zero-shot baseline, with comprehensiveness falling to 0.12 [9].
Figure 1. A proposed learning loop: developer feedback and verification signals inform training, followed by independent evaluation of correct findings and missed issues on held-out pull requests before deployment.
Evaluation would need to track the correctness and usefulness of findings on new pull requests, alongside acceptance. It should also measure missed issues using independently reviewed pull requests, since feedback on posted suggestions captures only the findings the reviewer surfaced, not the issues it missed. In SWE-PRBench’s diff-only evaluation, the tested models missed most human-flagged issues [2].
3. Smaller, specialized models
Distillation and lightweight adapters could let vendors use smaller models for specific review tasks, such as resolving comments or applying repository conventions. These models could become components inside broader agentic review systems, rather than replacing them.
If they maintain review quality at lower operating costs, specialized models could make private deployments more economical and give vendors more flexibility in how they serve customers. The training experiments discussed earlier motivate this direction, while its value for code review remains to be demonstrated.
Conclusion
Training pays off where review history supplies clean pairs of request and outcome. Comment resolution has that structure, and Meta and Google turned it into production results. Issue detection doesn’t yet. Training on raw historical comments can even make models worse, so progress there depends on verified signals, not just more data.
At Qodo, our reviewer already learns a team’s coding standards from its codebase and past PR reviews, and uses them when reviewing new changes. Fine-tuning is a direction we’re exploring to take that learning further.
The goal is to turn a team’s review history into more accurate findings and more useful fixes.
References
- Lin et al., Is Agentic Code Review Helpful? (2026)
- Kumar, SWE-PRBench (2026)
- Thinking Machines, LoRA Without Regret (2025)
- Wang et al., Tina: Tiny Reasoning Models via LoRA (2025)
- Morris et al., Learning to Reason in 13 Parameters (2026)
- Qwen Team, Qwen3 Technical Report (2025)
- Maddila et al., AI-Assisted Fixes to Code Review Comments at Scale (2025)
- Google Research, Resolving Code Review Comments with ML (2023)
- Kapadnis et al., CRScore++ (2025)
About the author
