Pith. sign in

REVIEW 4 major objections 4 minor 51 references

A Pilot Study on LLM-Based Agentic Translation from Android to iOS: Pitfalls and Insights

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

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

Pith's one-line read A three-agent LLM pipeline translates Android apps to Swift with a 70.7% valid-file rate after validation, though no project builds without substantial human effort.

desk verdict Useful first measurement of agentic Android-to-iOS translation with a solid failure taxonomy, but the headline 70.7% valid-file rate rests on a manual, file-local judgment and overstates usable output. read the letter →

arxiv 2507.16037 v1 pith:KG2HPPV5 submitted 2025-07-21 cs.SE

Zhili Zeng , Kimya Khakzad Shahandashti , Alvine Boaye Belle , Song Wang , Zhen Ming (Jack) Jiang This is my paper
classification cs.SE
keywords CodetranslationLargelanguagemodelsAgenticAndroidtoiOSmigrationRepository-levelRootcauseanalysisEmpiricalstudy
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 sets out to establish whether large language models can translate entire Android applications into iOS Swift code, and what exactly stands in the way. Using five open-source Android projects spanning about 2,800 to 150,000 lines of code, a multi-agent pipeline built on GPT-4o converted Java files to Swift and then ran a validation agent that checked references and syntax. The average percentage of translated files judged valid rose from 43.2% before validation to 70.7% after it, with syntax errors driven to zero but style and lint issues persisting. A manual root-cause analysis of 380 failures produced a ten-category taxonomy, led by internal reference mismatches at 23.95%, ahead of incomplete translations and third-party library mismatches. The result matters because cross-platform app migration is currently labor-intensive, and it pinpoints where an automated pipeline helps and where it still needs project-wide awareness and platform-specific adaptation.

What carries the argument

The central machinery is a chain of three specialized agents. A Specification Extraction Agent pulls contextual grounding from project documentation, issues, and related text through retrieval-augmented generation. A Code Translation Agent parses the Java into abstract syntax trees, builds class and component dependency graphs, and translates bottom-up from methods to classes to components so the least-dependent code is converted first. A Code Validation Agent then checks inter-file references and dependency graphs, runs the Swift compiler and a linter, and feeds the errors back to the translator for up to three refinement rounds. This last agent is what lifts the valid-file average from 43.2% to 70.7% and eliminates syntax errors.

What would settle it

Compile the 1,187 translated Swift files from the released replication data with the standard Swift toolchain and attempt to launch the assembled apps in an iOS simulator; if far fewer than 70.7% of files compile or the apps cannot start, the manual validity oracle was more lenient than actual buildability.

Watch

Extended reading notes

Core claim

The paper's central claim is that an agentic translation pipeline—specification extraction, dependency-aware translation, then validation with feedback—can produce Swift files that pass manual review for syntactic correctness, semantic accuracy, and functional completeness for 70.7% of the 1,187 translated files on average, compared with 43.2% when translation is attempted before the validation stage. Performance differs by project: the smallest and simplest projects do best, while the largest and most complex codebase stays at 68.7% after validation. The authors further claim that the failures are not random: among the 380 manually reviewed failure cases, 23.95% are dependency mismatches on internal references, 17.89% are incomplete translations, and 17.11% are third-party library mismatches, with the rest spread over syntax, linting, error handling, performance, data storage, and platform-specific design and system settings. They conclude that the limiting factors are global project awareness and platform-specific knowledge, not basic code generation.

Load-bearing premise

The effectiveness numbers rest on the authors' manual judgment of whether a translated file is valid, not on the translated projects compiling or running; the paper explicitly states the projects cannot be built without substantial human effort.

Editorial extensions

If this is right

  • Adding the Code Validation Agent lifts the average valid-file rate from 43.2% to 70.7%, a gain of 14.7 to 44.4 percentage points depending on the project.
  • After validation, no translated file has remaining syntax errors, but 348 lint issues persist, and 18.1% of the unfixable ones appear to be false positives.
  • The dominant single failure is internal reference mismatch at 23.95%, meaning the model loses track of class and method relationships across files more often than it makes syntax mistakes.
  • The largest project, at about 150,000 lines, posts the lowest post-validation rate at 68.7%, so translation quality declines as codebase size and interdependency grow.
  • Even after the full pipeline, none of the translated projects can be built into a working iOS app without substantial manual restructuring and dependency work.

Reading between the lines

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

  • Beyond the paper: if internal reference mismatches really drive 23.95% of failures, feeding the translator a repository-wide symbol table or retrieved definitions of referenced classes might close most of the remaining gap, and that is directly testable with the released data.
  • Beyond the paper: the evaluation stops at "valid file," so a natural follow-up is to measure the actual human time needed to make each translated project buildable, giving a cost-per-line estimate that would determine practical adoption.
  • Beyond the paper: the failure taxonomy suggests platform translation is asymmetric; an iOS-to-Android reverse study would show whether Android-specific concepts left untranslated are simply a direction artifact or a general LLM limitation.
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. This paper reports a pilot empirical study of an LLM-based agentic pipeline for translating Android (Java) applications to iOS (Swift). The pipeline consists of a Specification Extraction Agent using retrieval-augmented generation, a Code Translation Agent using AST and dependency analysis, and a Code Validation Agent performing dependency resolution, linting, and syntax checks. Five open-source projects totaling 1,187 files are translated with GPT-4o, and two authors manually assess the resulting files for syntactic correctness, semantic accuracy, and functional completeness. The headline results are an average valid-file rate of 43.2% before and 70.7% after the Code Validation Agent, and a taxonomy of 10 failure categories derived from 380 manually reviewed issues, with internal reference mismatches as the most common failure type. The paper also proposes future directions including platform-specific fine-tuning, human-in-the-loop feedback, and dependency synchronization.

Significance. If interpreted as an exploratory measurement, the study is valuable: it contributes one of the few empirical datasets on repository-level Android-to-iOS translation, includes a public replication package, and its taxonomy of failure categories is a useful starting point for improving translation agents. The inter-rater agreement is reported above 0.8, and the manual review process is described in enough detail to be auditable. The study is not circular: it uses external open-source projects, a commercial LLM, and a manual oracle rather than a metric defined by the pipeline itself. However, the central effectiveness number rests on a file-local, manual validity oracle, and the paper itself admits the translated projects cannot be built without substantial human effort. The most frequent failure category is unresolved internal references, which can survive the reported validation stages; this means the 70.7% valid-file rate likely overstates the practical usability of the translated code. The absence of a non-agentic baseline also limits what can be concluded about the agentic pipeline specifically.

major comments (4)
  1. [Section 4.4, Table 6] The central metric, 'Percentage of Valid Translated Files', is defined in Section 4.4 as passing 'basic compilation or syntax checking' plus manual verification, but the same section states that the translated projects cannot be built without substantial human effort, and Section 5.2.2 identifies 'Dependency Mismatch - Internal Reference' as the most frequent failure (23.95% of 380 reviewed issues). Files that reference undefined project-specific classes, methods, or constants can pass per-file swiftc parsing, which does not resolve cross-file symbols, and can still be counted as valid if the manual reviewer judges the local logic faithful; the reported 70.7% therefore conflates locally plausible Swift snippets with integrable, buildable files. I request a stricter validity criterion based on dependency resolution or whole-project compilation, or an explicit breakdown of valid files into those with and without unresolved internal references, and a corresponding restatement of the RQ1 answer.
  2. [Table 6, Section 5.1] The aggregate numbers in Table 6 are internally inconsistent for the before-validation condition. Using the per-project percentages and file counts in the same table gives approximately 523 valid files out of 1,187, or about 44.0%, not the reported 43.2%; if the exact counts differ, they should be printed. Since the RQ1 answer in Section 5.1 quotes 43.2% and 70.7%, a precise, reproducible table with exact valid-file counts per project is needed before these numbers can be cited as the study's central result.
  3. [Section 3, Section 5.1] No baseline condition isolates the contribution of the proposed agentic pipeline. The before/after comparison in Table 6 varies only the Code Validation Agent within the same pipeline, and it does not compare against a non-agentic baseline such as zero-shot whole-file GPT-4o translation, method-level translation without retrieval-augmented specification context, or a single-agent flat prompt. As a result, the paper's claim that an 'LLM-based agentic approach' achieves these rates cannot distinguish the pipeline's contribution from GPT-4o's ordinary code-translation ability. Add at least one simple baseline to RQ1, or narrow the claim to the incremental effect of the validation stage.
  4. [Section 5.2] The sampling description in Section 5.2 is incomplete for a quantitative taxonomy: the authors state that random sampling was performed 'with a 95% confidence level' and produced 380 reviewed cases, but they do not report the population size, the confidence interval, or the margin of error, so the representativeness of the 380-case sample is not verifiable from the paper. Without this information, the category percentages in Figure 2 cannot be interpreted as statistically grounded estimates of the underlying failure distribution.
minor comments (4)
  1. [Section 5.2.2, Figure 2] The text reports 16.58% for Incomplete Translation, while Figure 2 reports 17.89% (68/380); these values should be reconciled.
  2. [Section 5.2.1, Figure 4] The caption of Figure 4 calls the example a 'Semantic Error', but the category in the taxonomy and the surrounding text is 'Syntax Errors'; the terminology should be aligned.
  3. [Section 3.3] The validation section says 'we performed up to three rounds of iterative refinement' and later says 'diminishing returns in code quality improvements after five iterations'; the intended number of refinement rounds should be stated consistently.
  4. [Section 2.2, References] CodePlan is cited as reference [7] and again as reference [14] with different author lists; please verify the citations and remove duplicate or conflicting entries.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an empirical measurement study whose central results are observations from an external oracle, not derivations from the pipeline's own definitions.

full rationale

This is an empirical pilot study, not a derivation. The central RQ1 claim (43.2% valid before and 70.7% after the Code Validation Agent) is a reported measurement from Table 6, obtained by running a multi-agent pipeline on five external open-source Android projects and judging output files with a manual review protocol defined in Section 4.4. The validity metric is operationalized as passing syntax checks plus manual verification of core functionality; it is not defined as 'whatever the agent produces,' so there is no self-definitional equation. The Code Validation Agent clearly influences the after-validation numbers, but its effect is the object of study rather than a fitted parameter or a renamed prediction. The paper explicitly discloses a major limitation in Section 4.4: 'we cannot build the translated iOS projects successfully without further substantial human efforts.' This is an honest construct-validity threat, and the RQ2 taxonomy itself shows that the most common failure category is 'Dependency Mismatch - Internal Reference' (23.95%), but this concerns whether the manual oracle overstates usable output, not whether the reported result reduces to its own input. RQ2's ten-category taxonomy is inductively produced from 380 manually reviewed cases, not derived from a prior theorem or from the pipeline's assumptions. Several related-work references include co-authors of this paper (e.g., refs. [21], [34], [35], [36]), but these citations are descriptive background and are not load-bearing; no uniqueness theorem, ansatz, or fitted value is imported from them to force the paper's conclusions. No equation, definition, or citation chain in the manuscript makes a claimed result equivalent to its input, so no circular step can be exhibited.

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

The paper is an empirical evaluation, so the ledger contains no fitted mathematical parameters. The main judgment calls the claims rest on are: GPT-4o as a representative model, manual inspection as the validity oracle, and the five selected repositories as a representative sample. The only explicit hand-chosen numeric setting is the number of refinement rounds in the validation agent.

free parameters (1)
  • Number of iterative refinement rounds = 3 (with text also mentioning 5)
    Section 3.3 sets up to three rounds of validation feedback per issue and says the count was chosen empirically based on observed diminishing returns. Table 6's after-validation numbers depend on this round count, which was not systematically tuned.
assumptions (4)
  • domain assumption GPT-4o with default parameters is representative of state-of-the-art LLMs for code translation.
    Section 4.3 states GPT-4o was selected for superior code performance; the generalizability of all effectiveness numbers rests on this representativeness assumption.
  • domain assumption Manual inspection by two experienced authors is a reliable oracle for syntactic, semantic, and functional validity.
    Section 4.4 defines valid files via manual verification criteria and reports kappa above 0.8, but no translated project was built or run, so the oracle is human judgment rather than execution.
  • domain assumption The five selected Android repositories are a representative sample of real-world mobile applications.
    Section 4.2 selects projects by domain and size but excludes heavy third-party dependencies, and NextCloud accounts for 955 of 1,187 source files, so aggregate percentages are skewed toward that single project.
  • domain assumption Tree-sitter, ChromaDB, SwiftLint, and swiftc behave as standard tools and do not systematically bias the translation or evaluation.
    Sections 3.2 and 3.3 rely on these tools for AST parsing, RAG storage, linting, and syntax checking; results inherit any errors or version-specific behavior in these tools.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Pilot Study on LLM-Based Agentic Translation from Android to iOS: Pitfalls and Insights." pith.science (2026). https://pith.science/paper/KG2HPPV5

@misc{pith2026250716037,
  author       = {Pith},
  title        = {Pith review of: A Pilot Study on LLM-Based Agentic Translation from Android to iOS: Pitfalls and Insights},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KG2HPPV5}},
  note         = {Machine review of arXiv:2507.16037}
}
read the original abstract

The rapid advancement of mobile applications has led to a significant demand for cross-platform compatibility, particularly between the Android and iOS platforms. Traditional approaches to mobile application translation often rely on manual intervention or rule-based systems, which are labor-intensive and time-consuming. While recent advancements in machine learning have introduced automated methods, they often lack contextual understanding and adaptability, resulting in suboptimal translations. Large Language Models (LLMs) were recently leveraged to enhance code translation at different granularities, including the method, class, and repository levels. Researchers have investigated common errors, limitations, and potential strategies to improve these tasks. However, LLM-based application translation across different platforms, such as migrating mobile applications between Android and iOS or adapting software across diverse frameworks, remains underexplored. Understanding the performance, strengths, and limitations of LLMs in cross-platform application translation is critical for advancing software engineering automation. This study aims to fill this gap by evaluating LLM-based agentic approaches for mobile application translation, identifying key failure points, and proposing guidelines to improve translation performance. We developed a chain of agents that account for dependencies, specifications, program structure, and program control flow when translating applications from Android to iOS. To evaluate the performance, we manually examined the translated code for syntactic correctness, semantic accuracy, and functional completeness. For translation failures, we further conducted a detailed root cause analysis to understand the underlying limitations of the agentic translation process and identify opportunities for improvement.

Figures

Figures reproduced from arXiv: 2507.16037 by the authors.

Figure 1
Figure 1. Overview of our LLM-based agent for Android-to-iOS translation [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. The categories of translation errors and their distributions [PITH_FULL_IMAGE:figures/full_fig_p017_2.png] view at source ↗
Figure 3
Figure 3. An example issue labeled as Linting/Code Quality [PITH_FULL_IMAGE:figures/full_fig_p018_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: An example issue labeled as Semantic Error iOS .../JSONWeatherParser.swift static func getWeather(data: String) throws -> Weather { let mainObj = try JSONSerialization.jsonObject(with: Data(data.utf8), options: []) as! [String: Any]Lack error handling Android .../JSONW…
Figure 5
Figure 5. Figure 5: An example issue of Error Handling 5.2.2 File-Level Issues. File-level issues involve the structure or implementation of a single/multiple classes or a specific file. We identified three types of patterns regarding internal reference, incomplete translation, and framew…
Figure 6
Figure 6. Figure 6: An example issue of Dependency Mismatch - Internal Reference iOS .../DetailFragment.swift override func onItemClicked(itemViewHolder: Presenter.ViewHolder, item: Any, rowViewHolder: RowPresenter.ViewHolder, row: Row) { if let movie = item as? Movie { let intent = Inten…
Figure 7
Figure 7. Figure 7: An example issue of Incomplete Translation [PITH_FULL_IMAGE:figures/full_fig_p020_7.png]
Figure 8
Figure 8. Figure 8: An example issue of Framework/API differences translation failures. These issues occur when the source code depends on platform-specific frameworks or APIs that lack direct counterparts in the target environment, resulting in semantic mismatches or runtime errors. This…
Figure 9
Figure 9. Figure 9: An example issue of Performance Concerns [PITH_FULL_IMAGE:figures/full_fig_p021_9.png]
Figure 10
Figure 10. Figure 10: An example issue of Platform-Specific-Design-Features apps can have multiple scenes. This approach assumes a single-window setup, which may lead to incorrect behavior in multi-scene environments and reduce maintainability. A more robust solution would involve using UI…
Figure 11
Figure 11. Figure 11: A example issue under Platform-Specific-System-Settings [PITH_FULL_IMAGE:figures/full_fig_p023_11.png]
Figure 12
Figure 12. Figure 12: An example issue under Data Storage Inconsistency the iOS environment. This functionality must be reimplemented using iOS-native approaches, such as leveraging Bundle or UIApplication. • Data Storage Inconsistency: Android and iOS adopt distinct approaches to data sto…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

51 extracted references · 26 canonical work pages

  1. [1]

    MinimalToDo: A minimalistic To-Do list application for Android

    2016. MinimalToDo: A minimalistic To-Do list application for Android. https://github.com/avjinder/Minimal-Todo

    work page 2016

  2. [2]

    2018. C2rust. https://www.galois.com/articles/c2rust

    work page 2018

  3. [3]

    2023. Sharpen. https://github.com/mono/sharpen

    work page 2023

  4. [4]

    Wasi Uddin Ahmad, Saikat Chakraborty, Baishakhi Ray, and Kai-Wei Chang. 2020. A Transformer-based Approach for Source Code Summarization. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics . Association for Computational Linguistics, 4998–5007. https://doi.org/10.18653/v1/2020.acl-main.448

    doi:10.18653/v1/2020.acl-main.448 2020

  5. [5]

    Barr, Premkumar Devanbu, and Charles Sutton

    Miltiadis Allamanis, Earl T. Barr, Premkumar Devanbu, and Charles Sutton. 2018. A Survey of Machine Learning for Big Code and Naturalness. ACM Computing Surveys (CSUR) 51, 4 (2018), 1–37. https://doi.org/10.1145/3212695

    doi:10.1145/3212695 2018

  6. [6]

    Ardovic. 2020. Open Source Android Weather App. https://github.com/ardovic/Open-Source-Android-Weather-App

    work page 2020

  7. [7]

    Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B Ashok, and Shashank Shet. 2024. Codeplan: Repository-level coding using llms and planning. Proceedings of the ACM on Software Engineering 1, FSE (2024), 675–698

    work page 2024

  8. [8]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, et al. 2021. Evaluating Large Language Models Trained on Code.arXiv preprint arXiv:2107.03374 (2021). https://arxiv.org/abs/2107.03374

    arXiv 2021

Show all 51 references
  1. [9]

    Yinghao Chen, Zehao Hu, Chen Zhi, Junxiao Han, Shuiguang Deng, and Jianwei Yin. 2024. Chatunitest: A framework for llm-based test generation. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering . 572–576

    2024

  2. [10]

    Nextcloud GmbH. 2016. NextCloud: A self-hosted productivity platform for cloud storage and collaboration. https://github.com/nextcloud/android

    2016

  3. [11]

    Yuxuan He, Xiaodong Chen, and Yifan Li. 2023. Enhancing Code Translation in Language Models with Few-Shot Learning via Retrieval-Augmented Generation. In Proceedings of the 45th International Conference on Software Engineering (ICSE) . IEEE, 1234–1245. https://doi.org/10.1109/...

    2023 doi

  4. [12]

    Jaemin Hong. 2023. Improving Automatic C-to-Rust Translation with Static Analysis. In 2023 IEEE/ACM 45th International Conference on Software Engineering: Companion Proceedings (ICSE-Companion) . IEEE, 273–277

    2023

  5. [13]

    Ali Reza Ibrahimzada, Kaiyao Ke, Mrigank Pawagi, Muhammad Salman Abid, Rangeet Pan, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. AlphaTrans: A Neuro-Symbolic Compositional Approach for Repository-Level Code Translation and Validation. arXiv preprint arXiv:2410.24117 A Pilot S...

    2024 arXiv

  6. [14]

    Ankur Jain, Yifan Hu, Dongxu Zhang, Peng Xu, and Daniel Lin. 2023. CodePlan: Repository-Level Coding using LLMs and Planning. arXiv preprint arXiv:2307.23456 (2023). https://arxiv.org/abs/2307.23456

    2023

  7. [15]

    Prithwish Jana, Piyush Jha, Haoyang Ju, Gautham Kishore, Aryan Mahajan, and Vijay Ganesh. 2024. Cotran: An llm-based code translator using reinforcement learning with feedback from compiler and symbolic execution. In ECAI 2024. IOS Press, 4011–4018

    2024

  8. [16]

    Lazarela Lazareska, Kire Jakimoski, et al. 2017. Analysis of the advantages and disadvantages of Android and iOS systems and converting applications from Android to iOS platform and vice versa. American Journal of Software Engineering and Applications 6, 5 (2017), 116–120

    2017

  9. [17]

    Alexander LeClair, Hongjun Shi, Xiaopeng Ma, and Collin McMillan. 2023. Towards Translating Real-World Code with LLMs: A Study of Translating to Rust. arXiv preprint arXiv:2306.67890 (2023). https://arxiv.org/abs/2306.67890

    2023

  10. [18]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Shuo Kuang, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In Advances in Neural...

    2020 doi arXiv

  11. [19]

    Xiaodan Liang and Peng Wang. 2023. TRANSAGENT: An LLM-Based Multi-Agent System for Code Translation. InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP) . Association for Computational Linguistics, 456–467. https://doi.org/10.18653/...

    2023 doi

  12. [20]

    Junwei Liu, Kaixin Wang, Yixuan Chen, Xin Peng, Zhenpeng Chen, Lingming Zhang, and Yiling Lou. 2024. Large language model-based agents for software engineering: A survey. arXiv preprint arXiv:2409.02977 (2024)

    2024 arXiv

  13. [21]

    Fangwen Mu, Lin Shi, Song Wang, Zhuohao Yu, Binquan Zhang, ChenXue Wang, Shichao Liu, and Qing Wang. 2024. Clarifygpt: A framework for enhancing llm-based code generation via requirements clarification. Proceedings of the ACM on Software Engineering 1, FSE (2024), 2332–2354

    2024

  14. [22]

    Anh Tuan Nguyen, Tung Thanh Nguyen, and Tien N Nguyen. 2014. Migrating code with statistical machine translation. In Companion Proceedings of the 36th International Conference on Software Engineering . 544–547

    2014

  15. [23]

    OpenAI. 2023. GPT-4 Technical Report. arXiv preprint arXiv:2303.08774 (2023). https://arxiv.org/abs/2303.08774

    2023 arXiv

  16. [24]

    Halil Ozel. 2019. Android TV Movie Paradise. https://github.com/halilozel1903/AndroidTVMovieParadise

    2019

  17. [25]

    Rangeet Pan, Ali Reza Ibrahimzada, Rahul Krishna, Divya Sankar, Lambert Pouguem Wassi, Michele Merler, Boris Sobolev, Raju Pavuluri, Saurabh Sinha, and Reyhaneh Jabbarvand. 2024. Lost in translation: A study of bugs introduced by large language models while translating code. I...

    2024

  18. [26]

    Renaud Pawlak, Martin Monperrus, Nicolas Petitprez, Carlos Noguera, and Lionel Seinturier. 2016. Spoon: A library for implementing analyses and transformations of java source code. Software: Practice and Experience 46, 9 (2016), 1155–1179

    2016

  19. [27]

    Hung Dang Phan, Anh Tuan Nguyen, Trong Duc Nguyen, and Tien N Nguyen. 2017. Statistical migration of API usages. In 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C) . IEEE, 47–50

    2017

  20. [28]

    Chen Qian, Xin Cong, Cheng Yang, Weize Chen, Yusheng Su, Juyuan Xu, Zhiyuan Liu, and Maosong Sun. 2023. Communicative agents for software development. arXiv preprint arXiv:2307.07924 6, 3 (2023)

    2023 arXiv

  21. [29]

    Zeeshan Rasheed, Muhammad Waseem, Kai Kristian Kemell, Aakash Ahmad, Malik Abdul Sami, Jussi Rasku, Kari Systä, and Pekka Abrahamsson

  22. [30]

    Christopher Rawles, Alice Li, Daniel Rodriguez, Oriana Riva, and Timothy Lillicrap. 2023. Androidinthewild: A large-scale dataset for android device control. Advances in Neural Information Processing Systems 36 (2023), 59708–59728

    2023

  23. [31]

    Nils Reimers and Iryna Gurevych. 2019. Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. arXiv preprint arXiv:1908.10084 (2019)

    2019 arXiv

  24. [32]

    Subhajit Roy, Alexander LeClair, and Collin McMillan. 2021. Reassessing Automatic Evaluation of Code Summaries. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering . ACM, 164–176. htt...

    2021

  25. [33]

    Baptiste Roziere, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. 2020. Unsupervised translation of programming languages. Advances in neural information processing systems 33 (2020), 20601–20611

    2020

  26. [34]

    Soumit Kanti Saha, Fazle Rabbi, Song Wang, and Jinqiu Yang. 2024. Specification-Driven Code Translation Powered by Large Language Models: How Far Are We? arXiv preprint arXiv:2412.04590 (2024)

    2024 arXiv

  27. [35]

    Jiho Shin, Reem Aleithan, Hadi Hemmati, and Song Wang. 2024. Retrieval-Augmented Test Generation: How Far Are We? arXiv preprint arXiv:2409.12682 (2024)

    2024

  28. [36]

    Jiho Shin, Clark Tang, Tahmineh Mohati, Maleknaz Nayebi, Song Wang, and Hadi Hemmati. 2023. Prompt engineering or fine tuning: An empirical assessment of large language models in automated software engineering tasks. arXiv preprint arXiv:2310.10508 (2023)

    2023 arXiv

  29. [37]

    Uneven Software. 2018. LeafPic - Open Source Gallery App. https://github.com/UnevenSoftware/LeafPic

    2018

  30. [38]

    Alex Svyatkovskiy, Shao Kun Deng, Shengyu Fu, and Neel Sundaresan. 2020. Intellicode Compose: Code Generation Using Transformer. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering . ...

    2020

  31. [39]

    Tree-sitter Contributors. 2021. Tree-sitter. https://tree-sitter.github.io/tree-sitter/

    2021

  32. [40]

    Ashish Vaswani, Noam Shazeer, Niki Parmar, et al. 2017. Attention is All You Need. In Advances in Neural Information Processing Systems . 5998–6008. https://doi.org/10.48550/arXiv.1706.03762 28 Zhili Zeng, Kimya Khakzad Shahandashti, Alvine Boaye Belle, Song Wang, and Zhen Min...

    2017 doi arXiv

  33. [41]

    Luyuan Wang, Yongyu Deng, Yiwei Zha, Guodong Mao, Qinmin Wang, Tianchen Min, Wei Chen, and Shoufa Chen. 2024. MobileAgentBench: An Efficient and User-Friendly Benchmark for Mobile LLM Agents. arXiv preprint arXiv:2406.08184 (2024)

    2024 arXiv

  34. [42]

    Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, et al. 2024. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 6 (2024), 186345

    2024

  35. [43]

    Pinyan Wang, Hongyu Wang, Jaeseung Jang, Satish Chandra, and Zhendong Su. 2023. Lost in Translation: A Study of Bugs Introduced by Large Language Models while Translating Code. In Proceedings of the 44th ACM SIGPLAN Conference on Programming Language Design and Implementation ...

    2023

  36. [44]

    Zhiheng Xi, Wenxiang Chen, Xin Guo, Wei He, Yiwen Ding, Boyang Hong, Ming Zhang, Junzhe Wang, Senjie Jin, Enyu Zhou, et al. 2025. The rise and potential of large language model based agents: A survey. Science China Information Sciences 68, 2 (2025), 121101

    2025

  37. [45]

    Lei Xia, Baojian Hua, and Zhiyuan Peng. 2023. An empirical study of c to rust transpilers. School of Software Engineering, University of Science and Technology of China, and Suzhou Institute for Advanced Research, University of Science and Technology of China-04/27 (2023)

    2023

  38. [46]

    Weixiang Yan, Yuchen Tian, Yunzhe Li, Qian Chen, and Wen Wang. 2023. Codetransocean: A comprehensive multilingual benchmark for code translation. arXiv preprint arXiv:2310.04951 (2023)

    2023 arXiv

  39. [47]

    Zhiqiang Yuan, Weitong Chen, Hanlin Wang, Kai Yu, Xin Peng, and Yiling Lou. 2024. TRANSAGENT: An LLM-Based Multi-Agent System for Code Translation. arXiv preprint arXiv:2409.19894 (2024)

    2024 arXiv

  40. [48]

    Chi Zhang, Zhao Yang, Jiaxuan Liu, Yucheng Han, Xin Chen, Zebiao Huang, Bin Fu, and Gang Yu. 2023. Appagent: Multimodal agents as smartphone users. arXiv preprint arXiv:2312.13771 (2023)

    2023 arXiv

  41. [49]

    Dylan Zhang, Justin Wang, and Tianran Sun. 2025. Building A Proof-Oriented Programmer That Is 64% Better Than GPT-4o Under Data Scarsity. arXiv preprint arXiv:2502.11901 (2025)

    2025 arXiv

  42. [50]

    Renjie Zhong, Di Guo, and Daniel Lin. 2023. CodeTransOcean: A Comprehensive Multilingual Benchmark for Code Translation. arXiv preprint arXiv:2305.12345 (2023). https://arxiv.org/abs/2305.12345

    2023 arXiv

  43. [2025]

    arXiv preprint arXiv:2501.16998 (2025)

    Large Language Models for Code Generation: The Practitioners Perspective. arXiv preprint arXiv:2501.16998 (2025)

    2025 arXiv

Pith tools

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