Pith. sign in

REVIEW 3 major objections 6 minor 43 references

A code-review pass between two AI coding models helps only when the stronger model reviews the weaker model's draft.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-01 09:32 UTC pith:QYQ3VJIX

load-bearing objection A clean, honest empirical study of cross-model review ordering; the asymmetry result holds on the analyzed 116-task sample, but the missing attrition analysis bounds its generality. the 3 major comments →

arxiv 2607.21656 v1 pith:QYQ3VJIX submitted 2026-07-22 cs.SE cs.AI

Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?

classification cs.SE cs.AI
keywords agentic codingcode reviewLLM reviewstatic reviewLiveCodeBenchcross-model collaborationwriter-reviewer role assignmentClaude and Codex
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper asks a practical role-assignment question: when two coding agents work together, which one should write and which should review? On 116 hard and medium LiveCodeBench tasks, it finds the pairing is asymmetric. When the weaker writer (Codex) drafts, a static review pass by the stronger reviewer (Claude) lifts pass rate from 71.6% to 89.7%, and even self-review lifts it to 84.5%. When the stronger writer (Claude) drafts, a review pass by the weaker reviewer (Codex) drops the pass rate from 91.4% to 82.8%, and Claude self-review adds no accuracy. The useful recommendation is to use Claude to review Codex, not the other way around.

Core claim

The central claim is that the benefit of a second-model code review pass is controlled by the direction of the capability gap, not by the mere presence of a reviewer. A reviewer that is the stronger of the two models recovers most of the gap between the writer's solo accuracy and its own solo accuracy—Codex drafts reach 89.7% under Claude review, nearly matching Claude solo at 91.4%—whereas a reviewer that is the weaker model tends to overwrite correct drafts and cause regressions, dropping Claude's passing rate by 8.6 points. Same-model review helps only the weaker writer, not the stronger one. Because the two models differ in baseline pass rate, the paper presents the cross-model contrast

What carries the argument

The static-review protocol: six writer/reviewer conditions run on the same 116 tasks, with the reviewer seeing the problem and the draft and emitting a final program without running tests. Paired McNemar tests with Benjamini-Hochberg correction compare conditions on identical tasks, and fix/regression counts separate helpful repairs from harmful rewrites. The protocol isolates the review intervention from tool use, iteration, and memory, so the measured effects are attributable to the cross-model review pass itself.

Load-bearing premise

The central claim depends on the 116-task complete-case sample being an unbiased slice of hard and medium LiveCodeBench; the excluded tasks (CLI errors, timeouts, parse failures, empty artifacts) are never described, and if they are missing not at random, the asymmetry could change.

What would settle it

Run the same six conditions on the full LiveCodeBench hard/medium slice without dropping any tasks, or on the currently excluded tasks alone, and recompute the paired pass rates: if OA no longer beats O substantially, or if AO no longer drops below A, the asymmetry is an artifact of the filtering.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • When Codex must write, add a review pass: Claude as reviewer gives the best accuracy (89.7%, +18.1 points) and Codex self-review gives a cheaper, faster option (84.5%, +12.9 points).
  • When Claude must write, the paper recommends submitting the draft unreviewed: self-review adds cost and latency with zero accuracy gain, and Codex review loses 8.6 points.
  • A helpful review fixes a local flaw in a sound draft (26 fixes, 5 regressions for OA), while a harmful review rewrites a working draft into a failing one (13 regressions for AO).
  • Same-model review is not uniformly useful: it lifts Codex by 12.9 points but leaves Claude unchanged, so the value of a self-review pass depends on whether the writer leaves catchable errors.
  • On this sample, Claude solo sits on the Pareto frontier: no reviewed condition beats it on both accuracy and cost, so review spend is only justified for the Codex writer column.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the asymmetry is driven by relative capability rather than the specific two models, the same pattern should hold for any pair where the reviewer's solo pass rate exceeds the writer's; swapping in different model families is a direct test.
  • The complete-case filter may bias the result: tasks dropped for CLI errors, timeouts, or parse failures are never described, and if their difficulty correlates with model behavior, the paired pass rates could shift. Re-analyzing with the full sample is the first robustness check.
  • A prompt that lets the reviewer abstain rather than always emit a rewrite might remove the harmful 11.2% regression rate seen when Codex reviews Claude; that prediction is testable within the paper's own setup.
  • Because the reviewer cannot execute code, the measured review gains are a lower bound on what an execution-enabled reviewer could achieve; adding a sandbox would likely change the fix/regression balance.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. This paper reports a controlled experiment using LiveCodeBench hard and medium tasks (n=116 complete cases) to compare six writer/reviewer configurations between Claude Opus 4.7 and Codex GPT-5.5: two solo baselines, two cross-model orderings, and two same-model orderings. The reviewer receives the problem statement and the writer's draft but cannot execute tests, approximating a static code review step. The headline results are that Claude review raises Codex drafts from 71.6% to 89.7% (p_BH=.001), Codex self-review raises them to 84.5% (p_BH=.022), Codex review of Claude drafts lowers the pass rate from 91.4% to 82.8% (p_BH=.046), and Claude self-review is neutral. The paper acknowledges that the direct AO vs OA contrast is not significant after correction (p_BH=.144), and interprets the asymmetry relative to each writer's solo baseline. It also reports cost and latency trade-offs and releases an artifact with prompts, outputs, and scripts.

Significance. If the empirical asymmetry holds, the paper gives a practical role-assignment result and a useful data point for the broader claim that a review/repair pass helps mainly when the reviewer is stronger than the writer, consistent with prior self-repair findings (Olausson et al.). The design has several strengths: fixed prompt templates, exact paired McNemar tests with BH correction, transparent reporting of the non-significant direct ordering contrast, and a released artifact for reproducibility. The cost/latency analysis is a useful addition. However, the scope is a single model pair and a single static-review protocol, and the headline numbers depend on a complete-case sample whose attrition is not characterized.

major comments (3)
  1. [§3.4, Tables 2–4] The central estimates are computed on the 116-task complete case, but the paper never reports the size of the original hard and medium LiveCodeBench slices, how many tasks were excluded, or the reason per condition (CLI error, timeout, parse failure, empty artifact, budget). If exclusion correlates with difficulty or model-specific failure, every pass rate, SID, and p-value in Tables 2–4 could shift. This is load-bearing for the asymmetry claim. Please add an attrition table/flow diagram and a sensitivity analysis (e.g., re-running key contrasts under optimistic/pessimistic assignments of excluded tasks, or at least reporting exclusion rates by condition and difficulty). The 'bounded controlled sample' caveat in §3.4 does not substitute for this.
  2. [§3.3, §5.5] Each condition is a single run per task; the paper's own related-work discussion cites non-trivial variance of LLM outputs across repeated runs, and §4.3 notes that inspected patterns 'might not be reproducible in repeated runs.' Pass rates, confidence intervals, and McNemar p-values condition on one observed realization, so generation stochasticity is not reflected. Please either report repeated runs for a subset of tasks to quantify run-to-run variability, or explicitly justify why high-reasoning-effort outputs are treated as deterministic. Without this, the 95% CIs in Table 2 are understated.
  3. [§3.4, §4] The paper pools hard and medium tiers but reports no per-tier pass rates, SIDs, or attrition. Difficulty is a plausible effect modifier for review value (e.g., hard tasks may have more room for fixes, or more risk of regressions). Please report the complete-case counts and results by difficulty tier, and confirm whether the asymmetry holds within tiers; otherwise the pooled recommendation may be an artifact of tier composition.
minor comments (6)
  1. [§6 and Abstract] Because the direct AO vs OA contrast is not significant, 'use Claude to review Codex, not the other way around' could be misread as a direct ordering comparison. Suggest rewording to clarify that the recommendation is relative to each writer's solo baseline.
  2. [Table 4] Please state the total number of contrasts included in the BH correction and list all contrasts in the artifact; 'all pairwise contrasts generated by the analysis script' is not checkable from the paper.
  3. [§4] Typo: 'The program is ran locally' should be 'The program was run locally.'
  4. [References [1], [28]] The text uses Claude Opus 4.7 and Codex GPT-5.5, but the cited references are for Claude Opus 4 and GPT-5; align model identifiers with the cited versions.
  5. [Figure 1] The legend 'pass kept fix fail kept regression' is hard to parse; use explicit transitions such as 'pass→pass', 'fail→pass', 'pass→fail'.
  6. [§5.4] The 'cost per net fix' figures are computed as total per-task cost divided by net fixes, not marginal fix costs; clarify this to avoid overinterpretation.

Circularity Check

0 steps flagged

No significant circularity: the paper reports direct measurements against external LiveCodeBench hidden tests, with no fitted parameters or load-bearing self-citations.

full rationale

The paper does not attempt a derivation from first principles; it runs a controlled experiment and reports measured pass rates, deltas, and paired tests. SID (Eq. 2) is defined as the simple difference between a reviewed condition's measured pass rate and the corresponding solo baseline's measured pass rate; it is a descriptive contrast, not a fitted quantity later presented as a prediction. The central asymmetry claim (Claude reviewing Codex improves Codex drafts; Codex reviewing Claude worsens Claude drafts) is read directly from Table 2/Table 4 outcomes on the shared 116-task complete-case set, and the authors explicitly disclaim a stronger causal interpretation: 'this design cannot fully separate the effect of review direction from the effect of that baseline gap.' The comparison to Olausson et al. [27] is an external citation, and the self-citations appearing in the related-work sections ([11], [36], [37], [38]) are incidental context rather than load-bearing support for the paper's empirical claims. The main methodological weakness—complete-case attrition, where Section 3.4 restricts analysis to 116 tasks for which all six conditions produced a valid evaluated artifact without quantifying the excluded tasks—is a representativeness and missingness threat, not a circularity: it does not make any reported result equal to its input by construction. The paper's own Section 5.5 limitations similarly disclose prompt sensitivity, single-model-pair scope, and the exploratory nature of the sample. Those are validity concerns, and none of the seven circularity patterns can be exhibited with quoted evidence.

Axiom & Free-Parameter Ledger

0 free parameters · 5 axioms · 0 invented entities

No free parameters are fitted and no entities are invented; the study is an empirical measurement against an external benchmark. The implicit postulates are representativeness of the complete-case sample, single-run equivalence to model behavior, contamination-free benchmark timing, prompt fairness, and static review as a code-review proxy.

axioms (5)
  • domain assumption LiveCodeBench hidden tests are a valid correctness oracle for generated Python code.
    Section 3.1/3.4; all pass/fail labels come from the hidden evaluator.
  • domain assumption A single high-reasoning run per condition represents the model's behavior.
    Section 3.3; there is no repeated sampling or temperature control, and the authors cite LLM nondeterminism [11,40] but do not quantify it.
  • domain assumption Post-2025 LiveCodeBench problems are uncontaminated for both models.
    Section 1; relies on release-date metadata being after each model's training cutoff.
  • domain assumption Hand-written writer/reviewer prompts are equally fair to both models.
    Section 5.5; the authors note hand-written prompts 'can advantage or disadvantage either model.'
  • domain assumption Static review without test execution approximates a pre-CI code review step.
    Section 1 and Listing 2; the reviewer is explicitly forbidden from running code.

pith-pipeline@v1.3.0-alltime-deepseek · 13555 in / 13526 out tokens · 118805 ms · 2026-08-01T09:32:26.177961+00:00 · methodology

0 comments
read the original abstract

Developers increasingly use two coding agents together: one writes a draft, and the other reviews it. However, it is not clear whether the pairing is worth its cost and time, or whether the order of the pairing matters. We run a controlled experiment on 116 recent hard and medium lcb tasks with Claude and Codex across six conditions to approximate a software practitioner's workflow: both solo baselines, both cross-model orderings, and both same-model orderings. The reviewer sees the problem and the writer's draft but cannot execute tests, which approximates a code review step. Claude review raises Codex drafts from 71.6% to 89.7% ($p_{BH}=.001$); Codex self review raises them to 84.5% ($p_{BH}=.022$). The reverse direction does not pay off: Codex reviewing Claude drafts drops the pass rate from 91.4% to 82.8% ($p_{BH}=.046$), and Claude self review leaves the 91.4% baseline unchanged. Our evaluation indicates that the useful pairing is asymmetric: use Claude to review Codex, not the other way around.

Figures

Figures reproduced from arXiv: 2607.21656 by Hailu Xu, Yike Zhang, Yueming Zhang, Zuodong Xiang.

Figure 1
Figure 1. Figure 1: Per task outcomes (𝑛 = 116): stacked decomposition with conditions grouped by writer. Absolute fix and regres￾sion counts are shown to the right of each bar. first pass. At high reasoning effort, Claude Opus 4.7 may already catch most errors that a static reviewer could find, leaving the second pass with little signal. Codex GPT-5.5 appears to leave more residual, catchable errors. The latency table suppor… view at source ↗
Figure 2
Figure 2. Figure 2: Cost versus accuracy (left) and latency versus accuracy (right) trade-offs. Circles are solo baselines; diamonds are [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

43 extracted references · 1 canonical work pages

  1. [1]

    Anthropic. 2025. Claude Opus 4 System Card. https://www.anthropic.com/ claude/opus. Model identifier: claude-opus-4

  2. [2]

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. 2021. Program synthesis with large language models.arXiv preprint arXiv:2108.07732(2021). 1Code and data: https://github.com/shawnzxiang/cross-model-review-code

  3. [3]

    Alberto Bacchelli and Christian Bird. 2013. Expectations, outcomes, and chal- lenges of modern code review. In2013 35th international conference on software engineering (ICSE). IEEE, 712–721

  4. [4]

    Yoav Benjamini and Yosef Hochberg. 1995. Controlling the false discovery rate: a practical and powerful approach to multiple testing.Journal of the Royal Statistical Society: Series B (Methodological)57, 1 (1995), 289–300

  5. [5]

    Bei Chen, Fengji Zhang, Anh Nguyen, Daoguang Zan, Zeqi Lin, Jian-Guang Lou, and Weizhu Chen. 2022. CodeT: Code generation with generated tests.arXiv preprint arXiv:2207.10397(2022)

  6. [6]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374(2021)

  7. [7]

    Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. 2024. Teaching large language models to self-debug. InInternational Conference on Learning Representations, Vol. 2024. 8746–8825

  8. [8]

    Zhiyuan Cheng, Longying Lai, Yue Liu, and Yu Sun. 2026. Toward Sustainable On-Device Intelligence: A Survey on Energy-Efficient RAG Systems with Small Language Models.A vailable at SSRN 6698538(2026)

  9. [9]

    Yilun Du, Shuang Li, Antonio Torralba, Joshua B Tenenbaum, and Igor Mordatch

  10. [10]

    Yaxin Gao, Yao Lu, Zongfei Zhang, Jiaqi Nie, Shanqing Yu, and Qi Xuan. 2026. DSPC: Dual-Stage Progressive Compression Framework for Efficient Long- Context Reasoning. InICASSP 2026 - 2026 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). 19387–19391. doi:10.1109/ ICASSP55912.2026.11460600

  11. [11]

    Jiaming Guo, Zhichun Qi, Xiaokuan Zhao, Shuai Xu, and Hailu Xu. 2025. LightLLM-Enhanced Multi-Robot Collaboration with Human-in-the-Loop. In 2025 8th International Conference on Robotics, Control and Automation Engineering (RCAE). IEEE, 27–32

  12. [12]

    Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, et al. 2021. Mea- suring coding challenge competence with APPS.arXiv preprint arXiv:2105.09938 (2021)

  13. [13]

    Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Steven Yau, Zijuan Lin, Liyang Zhou, et al . 2024. MetaGPT: Meta programming for a multi-agent collaborative framework. In International Conference on Learning Representations, Vol. 2024. 23247–23275

  14. [14]

    Dong Huang, Jie M Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui. 2023. AgentCoder: Multi-agent-based code generation with iterative testing and optimization.arXiv preprint arXiv:2312.13010(2023)

  15. [15]

    Naman Jain, Alex Gu, Wen-Ding Li, Fanjia Yan, Tianjun Zhang, Sida Wang, Armando Solar-Lezama, Koushik Sen, and Ion Stoica. 2025. LiveCodeBench: Holistic and contamination free evaluation of large language models for code. In International Conference on Learning Representations, Vol. 2025. 58791–58831

  16. [16]

    Xiaochong Jiang, Shiqi Yang, Ziwei Li, Lifei Liu, Haoran Yu, and Yichen Liu

  17. [17]

    Yuxuan Jiang, Dawei Li, and Francis Ferraro. 2026. DRP: Distilled Reasoning Pruning with Skill-aware Step Decomposition for Efficient Large Reasoning Models. arXiv:2505.13975 [cs.CL] https://arxiv.org/abs/2505.13975

  18. [18]

    Haolin Jin and Huaming Chen. 2026. Are LLMs Reliable Code Reviewers? Sys- tematic Overcorrection in Requirement Conformance Judgement.arXiv preprint arXiv:2603.00539(2026)

  19. [19]

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. 2022. Competition-level code generation with AlphaCode.Science378, 6624 (2022), 1092–1097

  20. [20]

    Zhiyu Li, Shuai Lu, Daya Guo, Nan Duan, Shailesh Jannu, Grant Jenks, Deep Majumder, Jared Green, Alexey Svyatkovskiy, Shengyu Fu, et al. 2022. Automating code review activities by large-scale pre-training. InProceedings of the 30th ACM joint European software engineering conference and symposium on the foundations of software engineering. 1035–1047

  21. [21]

    Tian Liang, Zhiwei He, Wenxiang Jiao, Xing Wang, Yan Wang, Rui Wang, Yujiu Yang, Shuming Shi, and Zhaopeng Tu. 2024. Encouraging divergent thinking in large language models through multi-agent debate. InProceedings of the 2024 conference on empirical methods in natural language processing. 17889–17904

  22. [22]

    Hong Yi Lin, Chunhua Liu, Haoyu Gao, Patanamon Thongtanunam, and Christoph Treude. 2025. CodeReviewQA: The code review comprehension assess- ment for large language models. InFindings of the Association for Computational Linguistics: ACL 2025. 9138–9166

  23. [23]

    Jiayuan Liu, Tianqin Li, Shiyi Du, Xin Luo, Haoxuan Zeng, Emanuel Tewolde, Tai Sing Lee, Tonghan Wang, Carl Kingsford, and Vincent Conitzer. 2026. The Memory Curse: How Expanded Recall Erodes Cooperative Intent in LLM Agents. arXiv preprint arXiv:2605.08060(2026)

  24. [24]

    Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa? Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea

    Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al . Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa? Agentic SE @ KDD ’26, August 10, 2026, Jeju, Korea

  25. [25]

    Quinn McNemar. 1947. Note on the sampling error of the difference between correlated proportions or percentages.Psychometrika12, 2 (1947), 153–157

  26. [26]

    Ansong Ni, Srini Iyer, Dragomir Radev, Veselin Stoyanov, Wen-tau Yih, Sida Wang, and Xi Victoria Lin. 2023. LEVER: Learning to verify language-to-code generation with execution. InInternational Conference on Machine Learning. PMLR, 26106–26128

  27. [27]

    Theo X Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar-Lezama. 2024. Is self-repair a silver bullet for code generation?. InInternational Conference on Learning Representations, Vol. 2024. 36545–36593

  28. [28]

    OpenAI. 2025. Introducing GPT-5. https://openai.com/index/introducing-gpt-5/. Model identifier: gpt-5

  29. [29]

    Ruwei Pan, Hongyu Zhang, and Chao Liu. 2025. CodeCoR: An LLM-based self-reflective multi-agent framework for code generation.arXiv preprint arXiv:2501.07811(2025)

  30. [30]

    Chen Qian, Wei Liu, Hongzhang Liu, Nuo Chen, Yufan Dang, Jiahao Li, Cheng Yang, Weize Chen, Yusheng Su, Xin Cong, et al. 2024. ChatDev: Communicative agents for software development. InProceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers). 15174–15186

  31. [31]

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

  32. [32]

    Binqi Shen, Lier Jin, Hanyu Cai, Lan Hu, and Yuting Xin. 2026. The Efficiency Frontier: A Unified Framework for Cost-Performance Optimization in LLM Con- text Management.arXiv preprint arXiv:2605.23071(2026). doi:10.48550/arXiv. 2605.23071

  33. [33]

    Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal reinforcement learning. Advances in neural information processing systems36 (2023), 8634–8652

  34. [34]

    Rosalia Tufano, Luca Pascarella, Michele Tufano, Denys Poshyvanyk, and Gabriele Bavota. 2021. Towards automating code review activities. In2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 163–174

  35. [35]

    Yining Wang, Zhixiang Lu, Pin Qian, Jionglong Su, Mian Zhou, Chong Li, and Zhengyong Jiang. 2025. GEMs-LLM: Integrating Large Language Mod- els with Goal-Aware Exploration for RL-Based Portfolio Optimization. InAd- vanced Intelligent Computing Technology and Applications (Communications in Computer and Information Science, Vol. 2566). Springer, Singapore,...

  36. [36]

    Simon Zhang, Zhengxiong Li, Yaxuan Yin, Shuai Xu, Vipin Chaudhary, and Hailu Xu. 2025. A survey on multi-robot collaboration systems: Architectures, performances, and applications. (2025)

  37. [37]

    Yike Zhang, Zuodong Xiang, and Hailu Xu. 2026. Performance-Efficiency Trade- offs in Human Preference Prediction: A Comparative Study of Traditional Ma- chine Learning and Large Language Models. InProceedings of the 31st IEEE Symposium on Computers and Communications (ISCC 2026)

  38. [38]

    YueMing Zhang, Shuai Xu, Zhengxiong Li, Fangtian Zhong, Xiaokun Yang, and Hailu Xu. 2026. SwiftBot: A Decentralized Platform for LLM-Powered Federated Robotic Task Execution.The 26th IEEE International Symposium on Cluster, Cloud, and Internet Computing (CCGrid)(2026)

  39. [39]

    Zijian Zhang, Rong Fu, Yangfan He, Xinze Shen, Yanlong Wang, Xiaojing Du, Haochen You, Keyan Jin, Jiazhao Shi, and Simon Fong. 2026. FinSentLLM: Multi- LLM and Structured Semantic Signals for Enhanced Financial Sentiment Fore- casting. InICASSP 2026 - 2026 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). IEEE, 17682–17686

  40. [40]

    Yongxi Zhou, Lai Yun Choi, Jiaxi Wen, and Wenbo Ye. 2026. Accuracy, Stabil- ity, and Repeated-Run Reliability of Large Language Models on Deterministic Programming Tasks. arXiv:2606.00920 [cs.LG] https://arxiv.org/abs/2606.00920

  41. [2023]

    Self-Refine: Iterative refinement with self-feedback.Advances in neural information processing systems36 (2023), 46534–46594

  42. [2024]

    InForty-first international conference on machine learning

    Improving factuality and reasoning in language models through multiagent debate. InForty-first international conference on machine learning

  43. [2026]

    arXiv:2605.26542 [cs.CR] https://arxiv.org/abs/2605.26542

    ChainCaps: Composition-Safe Tool-Using Agents via Monotonic Capability Attenuation. arXiv:2605.26542 [cs.CR] https://arxiv.org/abs/2605.26542