Pith. sign in

REVIEW 5 major objections 7 minor 1 cited by

Code Review Automation Via Multi-task Federated LLM -- An Empirical Study

T0 review · 5 major / 7 minor · reviewed 2026-08-11 · deepseek-v4-flash

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

Pith's one-line read This paper claims that a single federated model fine-tuned cumulatively on review-comment generation and code refinement, with review-necessity prediction kept separate, performs as well as or better than three separate per-task federated…

desk verdict Worth reading for the forgetting evidence, but the headline claim overreaches: the best method is two separate models and the gains are selected from test metrics. read the letter →

arxiv 2412.15676 v1 pith:36DA4R7Y submitted 2024-12-20 cs.SE

Jahnavi Kumar , Sridhar Chimalakonda This is my paper · ORCID
classification cs.SE
keywords codereviewautomationfederatedlearninglargelanguagemodelsmulti-taskcatastrophicforgettingparameter-efficientfine-tuningLoRALLaMA-3
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

The paper tries to establish that the three code review sub-tasks—deciding whether a patch needs review, writing a review comment, and refining code from the comment—can be handled by one federated large language model without sharing private code. It reports that sequentially training the model on one task after another destroys earlier-task performance, while a cumulative schedule in which the two regression tasks are trained together, separated from the classification task, outperforms individual per-task federated models on comment generation and code refinement and matches them on review-necessity prediction. If the claim holds, organizations with siloed code can jointly build a single privacy-preserving review assistant instead of one model per task.

What carries the argument

The carrying mechanism is a collection of five multi-task fine-tuning schedules applied to one 8B LLaMA-3 backbone, in which each client trains LoRA adapters locally, the server averages the adapters with FedAvg, and the merged adapter becomes the base for the next round. The decisive variant is FedCFT-reg, a two-model schedule: one federated model for the classification task T1 and one federated model trained on a randomly mixed corpus of the two generation tasks T2 and T3. The comparison baseline is FedBEST, the best federated round selected per task from twenty rounds, with best rounds of 1, 1, and 8 for T1, T2, and T3.

What would settle it

Rerun the five schedules with a held-out validation split used only for round selection, or with a fixed round budget for every method, and compare FedCFT-reg against FedBEST on the same test set; if the cumulative model no longer beats or matches the best per-task model on T2 and T3, the central claim is refuted. The paper's own tables show that the best round differs by task, so the selection protocol is directly testable.

Watch

Extended reading notes

Core claim

The central claim, stated on the paper's own terms, is that the cumulative fine-tuning technique for multi-task federated large language models shows improved performance over individual-task models for code review automation. Concretely, the FedCFT-reg model—one federated model for the two generation tasks plus the individual federated model for the binary necessity task—beats or matches the best per-task federated models on all three tasks. Sequential methods fail because the model forgets the earlier tasks once trained on the next one, with review-necessity prediction metrics dropping to zero. The paper concludes that task relatedness is exploitable in a federated model only if the training schedule avoids catastrophic forgetting.

Load-bearing premise

The comparison assumes that picking the best round by looking at the test scores, and then reporting that round's scores, does not inflate the claimed advantage of the multi-task model over the per-task baselines.

Editorial extensions

If this is right

  • Organizations with siloed, proprietary code can jointly fine-tune one shared model for review-comment generation and code refinement by exchanging LoRA adapters instead of code.
  • A single multi-task model is feasible for code review automation only if the training schedule is cumulative; sequential schedules should be avoided because they forget the earlier tasks.
  • The reported Wilcoxon test gives a statistical basis for preferring FedCFT-reg over per-task FedBEST on the chosen metrics, not merely a numerical one.
  • The benefit of federated fine-tuning over the vanilla model is largest for code refinement, where the best federated round raises ROUGE-L from 34.451% to 87.472%.

Reading between the lines

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

  • In the editor's reading, the round-selection protocol is the most fragile link: because the best round is picked from test-set metrics, the reported FedCFT-reg advantage over FedBEST could shrink under a held-out validation split or a fixed round budget; a re-run with proper round selection would settle this.
  • The same two-model cumulative recipe (classification separate from generation) is a natural candidate for other software engineering task trios that mix a binary decision with two generation tasks, such as issue triage, patch explanation, and fix generation, though the paper does not test these.
  • The FedTOC collapse to zero on T1 is so abrupt that it would be worth comparing against replay- or regularization-based continual learning to see whether the forgetting is intrinsic to federated sequential fine-tuning or to sequential fine-tuning in general.
  • Because only two simulated clients with a 3:1 data ratio were used, the performance ordering should be rechecked with more clients and with naturally unbalanced real-world participation before treating FedCFT-reg as the default multi-task schedule.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 7 minor

Summary. The paper studies whether federated fine-tuning of a large language model can automate three code-review sub-tasks (review necessity prediction, review comment generation, code refinement) and whether a multi-task federated model can match or beat separately trained per-task federated models. Using LLaMA-3 8B with LoRA, two clients, and the CodeReviewer dataset, the authors report that sequential multi-task training causes catastrophic forgetting, while a cumulative fine-tuning variant (FedCFT-reg) outperforms individual-task models. The empirical framework is the first application of multi-task FedLLM to code review, and the qualitative examples and the clear demonstration of catastrophic forgetting in sequential methods are useful. However, the paper's headline claim is undermined by how the best-performing 'multi-task' method is defined, by the use of test-set metrics to select the best federated round, and by statistical comparisons that do not support the stated conclusions.

Significance. If the results were robust, the paper would make a useful empirical contribution: it would show that privacy-preserving collaborative fine-tuning can improve code-review models for low-resource clients, and that sequential multi-task training of an 8B LLM is unstable. The paper also contributes reproducible artifacts, detailed dataset preprocessing, and a transparent round-by-round reporting of metrics, which are strengths. However, the load-bearing comparison that supports the central claim is compromised by three issues: the best multi-task method is not a single multi-task model, the best federated round is selected from test-set metrics without a validation holdout or repeated runs, and the reported FedCFT-reg numbers combine metrics from different rounds. These issues are fixable with re-analysis or reframing, but they currently prevent the paper from establishing its stated RQ2 conclusion.

major comments (5)
  1. [3.4.3, RQ2 Summary, Table 12] The RQ2 claim that 'the cumulative fine-tuning technique for multi-task FedLLM shows improved performance over individual-task models' is not supported by the method that actually delivers the improvement. FedCFT-reg (Section 3.4.3) trains two separate models: one for T1, which is explicitly the same individual-task T1 model from RQ1, and another for T2+T3. It is therefore not a single multi-task FedLLM. The only single-model cumulative method, FedCFT, performs far worse on T1 (F1 11.503 vs. 55.175 for FedBEST in Table 12) and its T2/T3 gains over FedBEST are small. The statement in Section 9 that the cumulative technique 'enables the deployment of a single FedLLM' is contradicted by the paper's own architecture. The claim and the RQ2 answer need to be reframed, or a genuinely single multi-task model must be evaluated.
  2. [4.2, 5.1, 5.2] The selection of the best federated round from test-set metrics is a load-bearing methodological flaw. Section 4.2 states that the study runs for 1 to T rounds and selects the best model among all T models, and Section 5.1/5.2 then choose per-task BEST rounds (T1=1, T2=1, T3=8; FedCFT-reg=1/1/2) from the same test columns in Tables 3 and 7-11. Because Section 3.1 repurposed the original validation set as client-1 training data, there is no held-out validation split for round selection. Selecting the best of 20 test rounds overstates performance, especially for comparisons where the reported advantage is small, and with a single run there are no confidence intervals to gauge the selection effect. The comparison should be repeated with validation-based round selection, or the authors should report the full round trajectories and avoid claiming an advantage at a test-selected optimum.
  3. [5.2, Table 11, Table 12] The FedBEST row for FedCFT-reg in Table 11 mixes metrics from two different rounds. From the Fed@1 and Fed@2 rows of the same table, the T2 values (C-BLEU 0.667, METEOR 9.323, ROUGE-L 10.921) come from round 1, while the T3 values (C-BLEU 76.104, METEOR 85.560, ROUGE-L 88.142) come from round 2. No single model instance achieves this combination. The text acknowledges that for T2 round 1 is slightly better but then chooses round 2 'for practicality', yet the table still reports the round-1 T2 numbers. This composite row is then used in Table 12 to claim that CFT-reg outperforms FedBEST, so the central numerical comparison is not based on an achievable model. Please report all metrics for one chosen round, or clearly label per-task best rounds and refrain from treating them as a single model's performance.
  4. [5.2, paragraph following Table 12] The Wilcoxon signed-rank test as applied is not a valid significance test here. The test compares 9 metric values (three tasks by three metrics) between two conditions, but these cells are not independent observations, are on different scales (F1 vs. C-BLEU vs. ROUGE-L), and come from a single training run. A p-value of 0.0277 therefore does not establish that FedCFT-reg significantly outperforms FedBEST. A proper paired test requires multiple independent runs per condition or an appropriate per-task statistical design with correction for multiple comparisons; alternatively, the significance claim should be removed and the results reported as descriptive.
  5. [5.2, Tables 8 and 9] For FedCOT and FedCAT, the tables report different BEST rounds per task (e.g., Table 8: T1=18, T2=2, T3=1) in a single row labeled FedBEST. Since each row is supposed to correspond to one model instance, this obscures the fact that no single round of the training run achieves those three scores simultaneously. The text acknowledges that a single BEST round could not be determined for all tasks; the tables and the comparison in Table 12 should make this explicit rather than presenting a per-task oracle as if it were a single model.
minor comments (7)
  1. [4.1] The sentence 'LoRA rank r search is performed for for powers of 2' contains a duplicated 'for'; please fix.
  2. [7 (and Section 9)] 'reply-based' should be 'replay-based' in the continual learning discussion; the term appears twice.
  3. [3.3] The hyper-parameter section states 'Experiments for hyper-parameter search of were conducted' with a missing object; the sentence is incomplete.
  4. [Tables 10 and 11] The 'BEST' rows are ambiguous because they combine per-task best rounds; please add a note to each table clarifying whether the shown metrics come from one round or from different rounds.
  5. [5.1] When discussing the FedLLM improvement over vanilla for T2, the text says 'the federated model at round 1 performs the best' and reports C-BLEU 0.6%; the improvements are stated in percentage points but the phrasing could be clearer that C-BLEU remains very low in absolute terms.
  6. [3.1] The decision to repurpose the original validation set as client-1 training data is a significant design choice with direct consequences for model selection; it should be flagged in the Threats to Validity section as a limitation.
  7. [Table 3] The table title 'Round-wise Metrics' does not indicate that these are test-set metrics; please label the table header to make clear that all reported rounds are evaluated on the test split.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: RQ2's FedCFT-reg T1 equality is by construction, but the 'improved performance' claim rests on measured T2/T3 gains.

full rationale

No circularity in the strict sense. This is an empirical benchmark paper, not a derivation: RQ1 compares federated rounds against vanilla and central baselines, and RQ2 compares five multi-task training techniques against the RQ1 FedBEST models. All headline numbers are executed runs on the CodeReviewer dataset (Tables 3, 7-12), not outputs of an equation or a fitted parameter renamed as a prediction. The closest candidate for a definitional reduction is FedCFT-reg. Section 3.4.3 defines it as 'training two separate models,' and Section 4.3 says for T1 'we use the individual-task model trained for T1 in RQ1, instead of re-training the same for evaluation.' Therefore the FedCFT-reg vs FedBEST T1 row in Table 12 is equal by construction (identical 49.141/62.900/55.175), and the RQ2 wording about a 'single multi-task model' is not literally satisfied. However, the paper does not use that T1 equality to derive the 'improved performance' conclusion; that conclusion is supported by independently measured T2/T3 gains (C-BLEU 0.667 vs 0.612 and 76.104 vs 74.583 in Table 12). This is a construct-validity/consistency issue, not a circular step. The self-citations to Kumar & Chimalakonda [15] supply design constants (26,000 samples, 20 rounds, hyper-parameter search recipe), but the result comparisons are measured against external baselines and are falsifiable independent of those constants, so the self-citations are not load-bearing proof. Selecting 'best' rounds from test metrics (Section 4.2) is a real statistical-selection concern but is not circularity. The central empirical content is self-contained; score 2 reflects only the minor recurrent reliance on the authors' own prior recipe.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

This is an empirical study, so the bookkeeping concerns design choices and assumptions rather than derivation constants. The main fitted quantities are LoRA hyperparameters and the test-selected best federated rounds. No invented physical or conceptual entities are introduced.

free parameters (4)
  • LoRA target modules and rank per task = T1: (Wk,Wv), rank 8; T2: (Wv), rank 8; T3: (Wq,Wo), rank 16; multi-task methods: (Wq,Wv,Wk,Wo), rank 8
    Chosen by hyperparameter search on a 10k training-data subset and finalized per task based on metrics; these choices affect all downstream comparisons.
  • Best federated round per task and method = T1=1, T2=1, T3=8; FedTOC 1/8/2; FedCOT 18/2/1; FedCAT 3/1/19; FedCFT 1/1/2; FedCFT-reg 1/1/2
    Selected post hoc from test-set metrics after running 20 rounds, so the reported BEST values are fitted to the test set.
  • Client data split ratio = 3:1 (19,500 to 6,500 samples)
    Chosen by the authors as a practical simulation; results may depend on this ratio and on the dataset re-splitting procedure.
  • Training data size and patch-length cutoff = 26k training and 2k test per task; patch length below 5000 characters
    Chosen to balance compute and avoid out-of-memory errors; arbitrary thresholds that influence which examples are used.
assumptions (4)
  • domain assumption CodeReviewer dataset provides reliable ground truth for review necessity, comments, and refined code.
    All metrics are computed against these references; no human or additional validation is performed.
  • domain assumption BLEU, METEOR, and ROUGE-L adequately capture the quality of generated review comments and code refinements.
    Lexical overlap metrics may not reflect semantic correctness of code; the paper uses them as the primary dependent variables.
  • domain assumption FedAvg of LoRA adapters from heterogeneous clients yields a usable shared model.
    The paper relies on FedAvg without analyzing convergence for non-IID data in this specific code review setting.
  • ad hoc to paper Wilcoxon signed-rank test over metric values across tasks is a valid significance test.
    The test treats each metric value as an observation across tasks, which is not a standard way to compare two models on one dataset.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Code Review Automation Via Multi-task Federated LLM -- An Empirical Study." pith.science (2026). https://pith.science/paper/36DA4R7Y

@misc{pith2026241215676,
  author       = {Pith},
  title        = {Pith review of: Code Review Automation Via Multi-task Federated LLM -- An Empirical Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/36DA4R7Y}},
  note         = {Machine review of arXiv:2412.15676}
}
read the original abstract

Code review is a crucial process before deploying code to production, as it validates the code, provides suggestions for improvements, and identifies errors such as missed edge cases. In projects with regular production releases, the effort required for peer code-reviews remains high. Consequently, there has been significant interest from software engineering (SE) researchers in automating the code review process. Previous research on code review automation has typically approached the task as three independent sub-tasks: review necessity prediction, review comment generation, and code refinement. Our study attempts to (i) leverage the relationships between the sub-tasks of code review automation, by developing a multi-task model that addresses all tasks in an integrated manner, and (ii) increase model robustness on unseen data via collaborative large language model (LLM) modeling, while retaining the proprietary nature of code, by using federated learning (FL). The study explores five simple techniques for multi-task training, including two sequential methods, one parallel method, and two cumulative methods. The results indicate that sequentially training a federated LLM (FedLLM) for our code review multi-task use case is less efficient in terms of time, computation, and performance metrics, compared to training separate models for each task. Because sequential training demonstrates catastrophic forgetting, alternatively cumulative fine-tuning for multi-task training performs better than training models for individual tasks. This study highlights the need for research focused on effective fine-tuning of multi-task FedLLMs for SE tasks.

Figures

Figures reproduced from arXiv: 2412.15676 by the authors.

Figure 1
Figure 1. Example of Code Review with Task Workflow. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Overall architecture diagram, illustrating Tasks 1, 2, and 3 and Clients a and b. [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Data Distribution of clients a and b 3.3 Hyper-parameter configuration Experiments for hyper-parameter search of were conducted similarly to methodology outlined in [15] utilizing a random selection of 10,000 balanced data points from the training dataset. These experiments were performed on an NVIDIA A100 40GB GPU. For the fine-tuning process, we set lora_alpha to 16 and applied a dropout probability of 0.1 to the … view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. SWR-Bench: Assessing LLM Performance in Real-World Code Review Comment Generation

    cs.SE 2025-09 conditional novelty 6.0 of 10

    SWR-Bench is a PR-centric code review benchmark with objective LLM scoring; current ACR tools reach at best 19.4% F1, and multi-review aggregation yields relative F1 gains up to 43.7%.

Reference graph

Works this paper leans on

43 extracted references · 33 canonical work pages · cited by 1 Pith paper

  1. [15]

    Jahnavi Kumar and Sridhar Chimalakonda. 2024. Code Summarization without Direct Access to Code-Towards Exploring Federated LLMs for Software Engineering. In Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering . 100–109

    work page 2024

  2. [1]

    Wisam Haitham Abbood Al-Zubaidi, Patanamon Thongtanunam, Hoa Khanh Dam, Chakkrit Tantithamthavorn, and Aditya Ghose. 2020. Workload-aware reviewer recommendation using a multi-objective search-based approach. In Proceedings of the 16th ACM international conference on predictive models and data analytics in software engineering . 21–30

    work page 2020

  3. [2]

    Nathaniel Ayewah, William Pugh, J David Morgenthaler, John Penix, and YuQian Zhou. 2007. Using findbugs on production software. In Companion to the 22nd ACM SIGPLAN conference on Object-oriented programming systems and applications companion. 805–806

    work page 2007

  4. [3]

    Alberto Bacchelli and Christian Bird. 2013. Expectations, outcomes, and challenges of modern code review. In 2013 35th International Conference on Software Engineering (ICSE) . IEEE, 712–721

    work page 2013

  5. [4]

    Vipin Balachandran. 2013. Reducing human effort and improving quality in peer code reviews using automatic static analysis and reviewer recommendation. In 2013 35th International Conference on Software Engineering (ICSE) . IEEE, 931–940

    work page 2013

  6. [5]

    Oussama Ben Sghaier and Houari Sahraoui. 2024. Improving the learning of code review successive tasks with cross-task knowledge distillation. Proceedings of the ACM on Software Engineering 1, FSE (2024), 1086–1106

    work page 2024

  7. [6]

    Keith Bonawitz, Vladimir Ivanov, Ben Kreuter, Antonio Marcedone, H Brendan McMahan, Sarvar Patel, Daniel Ramage, Aaron Segal, and Karn Seth. 2017. Practical secure aggregation for privacy-preserving machine learning. Inproceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security . 1175–1191

    work page 2017

  8. [7]

    Zhi Chen and Lingxiao Jiang. 2024. Promise and Peril of Collaborative Code Generation Models: Balancing Effectiveness and Memorization. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering . 493–505

    work page 2024

Show all 43 references
  1. [8]

    Nicole Davila and Ingrid Nunes. 2021. A systematic literature review and taxonomy of modern code review. Journal of Systems and Software 177 (2021), 110951

    2021

  2. [9]

    Nasir U Eisty and Jeffrey C Carver. 2022. Developers perception of peer code review in research software development. Empirical Software Engineering 27 (2022), 1–26

    2022

  3. [10]

    Mohamad Fakih, Rahul Dharmaji, Yasamin Moghaddas, Gustavo Quiros, Oluwatosin Ogundare, and Mohammad Ab- dullah Al Faruque. 2024. Llm4plc: Harnessing large language models for verifiable programming of plcs in industrial control systems. In Proceedings of the 46th International...

    2024

  4. [11]

    Shuzheng Gao, Hongyu Zhang, Cuiyun Gao, and Chaozheng Wang. 2023. Keeping pace with ever-increasing data: Towards continual learning of code intelligence models. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 30–42

    2023

  5. [12]

    Fatemeh H. Fard. 2024. Technical Briefing on Parameter Efficient Fine-Tuning of (Large) Language Models for Code- Intelligence. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings. 434–435. 4Replication package: http...

    2024

  6. [13]

    Edward J Hu, Yelong Shen, Phillip Wallis, Zeyuan Allen-Zhu, Yuanzhi Li, Shean Wang, Lu Wang, and Weizhu Chen

  7. [14]

    Oleksii Kononenko, Olga Baysal, and Michael W Godfrey. 2016. Code review quality: How developers see it. In Proceedings of the 38th international conference on software engineering . 1028–1038

    2016

  8. [16]

    Xiang Li, Kaixuan Huang, Wenhao Yang, Shusen Wang, and Zhihua Zhang. 2019. On the convergence of fedavg on non-iid data. arXiv preprint arXiv:1907.02189 (2019)

    2019 arXiv

  9. [17]

    Zhiyu Li, Shuai Lu, Daya Guo, Nan Duan, Shailesh Jannu, Grant Jenks, Deep Majumder, Jared Green, Alexey Svy- atkovskiy, Shengyu Fu, et al. 2022. Automating code review activities by large-scale pre-training. In Proceedings of the 30th ACM Joint European Software Engineering Co...

    2022

  10. [18]

    Sin Kit Lo, Qinghua Lu, Liming Zhu, Hye-Young Paik, Xiwei Xu, and Chen Wang. 2022. Architectural patterns for the design of federated learning systems. Journal of Systems and Software 191 (2022), 111357

    2022

  11. [19]

    Junyi Lu, Lei Yu, Xiaojia Li, Li Yang, and Chun Zuo. 2023. LLaMA-Reviewer: Advancing code review automation with large language models through parameter-efficient fine-tuning. In 2023 IEEE 34th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 647–658

    2023

  12. [20]

    Rodrigo Morales, Shane McIntosh, and Foutse Khomh. 2015. Do code review practices impact design quality? a case study of the qt, vtk, and itk projects. In 2015 IEEE 22nd international conference on software analysis, evolution, and reengineering (SANER). IEEE, 171–180

    2015

  13. [21]

    Dinh C Nguyen, Ming Ding, Pubudu N Pathirana, Aruna Seneviratne, Jun Li, and H Vincent Poor. 2021. Federated learning for internet of things: A comprehensive survey. IEEE Communications Surveys & Tutorials 23, 3 (2021), 1622–1658

    2021

  14. [22]

    Changan Niu, Chuanyi Li, Vincent Ng, Jidong Ge, Liguo Huang, and Bin Luo. 2022. Spt-code: Sequence-to-sequence pre-training for learning source code representations. In Proceedings of the 44th International Conference on Software Engineering. 2006–2018

    2022

  15. [23]

    Ipek Ozkaya. 2023. Application of large language models to software engineering tasks: Opportunities, risks, and implications. IEEE Software 40, 3 (2023), 4–8

    2023

  16. [24]

    Kishore Papineni, Salim Roukos, Todd Ward, and Wei-Jing Zhu. 2002. Bleu: a method for automatic evaluation of machine translation. In Proceedings of the 40th annual meeting of the Association for Computational Linguistics . 311–318

    2002

  17. [25]

    Chanathip Pornprasit and Chakkrit Tantithamthavorn. 2024. Fine-tuning and prompt engineering for large language models-based code review automation. Information and Software Technology (2024), 107523

    2024

  18. [26]

    Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, and Alberto Bacchelli. 2018. Modern code review: a case study at google. In Proceedings of the 40th international conference on software engineering: Software engineering in practice. 181–190

    2018

  19. [27]

    June Sallou, Thomas Durieux, and Annibale Panichella. 2024. Breaking the silence: the threats of using llms in software engineering. In Proceedings of the 2024 ACM/IEEE 44th International Conference on Software Engineering: New Ideas and Emerging Results. 102–106

    2024

  20. [28]

    Shriram Shanbhag and Sridhar Chimalakonda. 2022. Exploring the under-explored terrain of non-open source data for software engineering through the lens of federated learning. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Fou...

    2022

  21. [29]

    Carl Smestad and Jingyue Li. 2023. A systematic literature review on client selection in federated learning. InProceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering . 2–11

    2023

  22. [30]

    Saikrishna Sripada, Y Raghu Reddy, and Ashish Sureka. 2015. In support of peer code review and inspection in an undergraduate software engineering course. In 2015 IEEE 28th conference on software engineering education and training . IEEE, 3–6

    2015

  23. [31]

    Hugo Touvron, Louis Martin, Kevin Stone, Peter Albert, Amjad Almahairi, Yasmine Babaei, Nikolay Bashlykov, Soumya Batra, Prajjwal Bhargava, Shruti Bhosale, et al. 2023. Llama 2: Open foundation and fine-tuned chat models. arXiv preprint arXiv:2307.09288 (2023)

    2023 arXiv

  24. [32]

    Rosalia Tufano, Ozren Dabić, Antonio Mastropaolo, Matteo Ciniselli, and Gabriele Bavota. 2024. Code review automa- tion: strengths and weaknesses of the state of the art. IEEE Transactions on Software Engineering (2024)

    2024

  25. [33]

    Rosalia Tufano, Simone Masiero, Antonio Mastropaolo, Luca Pascarella, Denys Poshyvanyk, and Gabriele Bavota

  26. [34]

    Rosalia Tufano, Luca Pascarella, Michele Tufano, Denys Poshyvanyk, and Gabriele Bavota. 2021. Towards automating code review activities. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE) . IEEE, 163–174. , Vol. 1, No. 1, Article . Publication date: ...

    2021

  27. [35]

    Martin Weyssow, Xin Zhou, Kisub Kim, David Lo, and Houari Sahraoui. 2023. On the usage of continual learning for out-of-distribution generalization in pre-trained language models of code. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposi...

    2023

  28. [36]

    Robert F Woolson. 2007. Wilcoxon signed-rank test. Wiley encyclopedia of clinical trials (2007), 1–3

    2007

  29. [37]

    Yanming Yang, Xing Hu, Zhipeng Gao, Jinfu Chen, Chao Ni, Xin Xia, and David Lo. 2024. Federated Learning for Software Engineering: A Case Study of Code Clone Detection and Defect Prediction. IEEE Transactions on Software Engineering (2024)

    2024

  30. [38]

    Min Zeng, Haiqin Yang, Wei Xue, Qifeng Liu, and Yike Guo. 2024. Dirichlet Continual Learning: Tackling Catastrophic Forgetting in NLP. In The 40th Conference on Uncertainty in Artificial Intelligence

    2024

  31. [39]

    Yuexiang Zhai, Shengbang Tong, Xiao Li, Mu Cai, Qing Qu, Yong Jae Lee, and Yi Ma. 2024. Investigating the catastrophic forgetting in multimodal large language model fine-tuning. In Conference on Parsimony and Learning . PMLR, 202–227

    2024

  32. [40]

    Hongyi Zhang, Jan Bosch, and Helena Holmström Olsson. 2020. Federated learning systems: Architecture alternatives. In 2020 27th Asia-Pacific Software Engineering Conference (APSEC) . IEEE, 385–394

    2020

  33. [41]

    Xiao Zhang and Ji Wu. 2024. Dissecting learning and forgetting in language model finetuning. In The Twelfth International Conference on Learning Representations . , Vol. 1, No. 1, Article . Publication date: December 2024

    2024

  34. [2021]

    arXiv preprint arXiv:2106.09685 (2021)

    Lora: Low-rank adaptation of large language models. arXiv preprint arXiv:2106.09685 (2021)

    2021 arXiv

  35. [2022]

    In Proceedings of the 44th international conference on software engineering

    Using pre-trained models to boost code review automation. In Proceedings of the 44th international conference on software engineering. 2291–2302

Pith tools

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