Auto-Train for Code Translation (ACT)

Updated 7 July 2026

The paper presents ACT, an automated training framework that generates synthetic parallel code and validates translations via unit tests to preserve execution behavior.
ACT’s four-component architecture—Data Generation, Finetuning, Evaluation, Controller—dynamically refines models to enhance software migration and cross-language interoperability.
Empirical results, especially for Java to Go, show improved pass@1 and pass@5 metrics, underscoring ACT’s effectiveness in accelerating code translation quality.

Auto-Train for Code Translation (ACT) is an automated training framework for code translation that improves open-source LLMs by generating synthetic parallel data, validating that data with unit tests, finetuning models locally, and iterating under controller supervision. Introduced as an in-house, secure alternative to proprietary translation systems, ACT targets software modernization / migration, cross-language interoperability, and long-term codebase maintainability, while treating execution-level correctness as the central criterion of translation quality rather than surface-form similarity (Saxena et al., 22 Jul 2025).

1. Definition, problem setting, and intellectual context

ACT addresses code translation as the task of converting programs from a source language to a target language while preserving behavior. The framework is motivated by two difficulties emphasized in the literature: the lack of high-quality parallel data for open-source models, and the fact that a translation may be syntactically valid yet still be functionally wrong because semantics, dependencies, APIs, and language-specific idioms are not preserved (Saxena et al., 22 Jul 2025).

The framework is positioned against two earlier traditions. Rule-based, phrase-based statistical, and AST-based migration systems require manual engineering, are brittle, and do not generalize well to varied real-world codebases. Proprietary LLM-based translators can be strong, but they are API-based, may raise data security / privacy concerns, create vendor dependence, and are not easily adapted in-house to project-specific migration rules (Saxena et al., 22 Jul 2025).

An important antecedent to ACT is the use of automated unit tests to construct cleaner pseudo-parallel corpora for unsupervised translation. In "Leveraging Automated Unit Tests for Unsupervised Code Translation" (Roziere et al., 2021), candidate translations are generated, filtered by translated unit tests, and then used for self-training; this reduced noisy pseudo-labels from back-translation and improved computational accuracy across Java, Python, and C++. That work demonstrates the core ACT-style principle that automatic semantic filtering can be used to create better training supervision than raw generation alone (Roziere et al., 2021).

2. Core architecture and iterative training logic

ACT is organized into four components: Data Generation, Finetuning, Evaluation, and Controller. The central idea is iterative improvement: generate synthetic data, train, evaluate, and then decide whether to add more data, continue training, or stop (Saxena et al., 22 Jul 2025).

Component	Function	Primary output
Data Generation	Expands seed samples, translates them, and creates unit tests	Synthetic parallel data
Finetuning	Adapts an open-source LLM locally	Updated translator
Evaluation	Executes translations against tests and measures quality	Execution-level feedback
Controller	Decides whether to continue finetuning, generate more data, or stop	Stage-wise orchestration

This design distinguishes ACT from one-shot translation pipelines. The controller manages the entire pipeline by dynamically adjusting hyperparameters, orchestrating iterative data generation, and finetuning based on real-time evaluations. It looks at training loss, validation loss, evaluation scores, performance trends from current and previous stages, whether the base model is already strong enough for LoRA versus needing full finetuning, and whether failures indicate insufficient data diversity or model weakness (Saxena et al., 22 Jul 2025).

A common misconception is that ACT is only a synthetic data generator. The framework is broader: the synthetic data module is central, but the controller also selects between Full Supervised Fine-Tuning (SFT) and LoRA, tunes training configurations, and can send the pipeline back to targeted data generation when evaluation reveals coverage gaps, recurring failures, or insufficient diversity (Saxena et al., 22 Jul 2025).

3. Synthetic data generation, unit tests, and execution-based filtering

ACT begins with a small set of seed source-code samples. In the reported experiments, the framework uses 150 seed source-target pairs from HumanEval and expands them synthetically through breadth-based and depth-based augmentation (Saxena et al., 22 Jul 2025).

Breadth-based expansion creates new tasks with different functionality. Depth-based expansion makes the same problem more complex, using four prompt styles: Constraints Prompt, Deepen Prompt, Concretizing Prompt, and Reasoning Prompt. A user-provided diverse factor from 1 to 10 controls how far generated code deviates from the seed: higher diverse factor corresponds to more breadth-oriented variation, while lower diverse factor corresponds to more depth-oriented augmentation. Users can also specify additional requirements such as lower time complexity or inclusion of docstrings. In experiments, GPT-4o and Claude-3.5-Sonnet are used to increase variety (Saxena et al., 22 Jul 2025).

After expansion in the source language, ACT translates the generated samples into the target language. For large code files, the framework can segment the input into classes, functions, or transformation steps such as ETL pipelines, translate each segment, and then merge them back with an LLM. This segmentation is explicitly intended for larger migration workloads, where whole-file translation may be unstable (Saxena et al., 22 Jul 2025).

Unit test generation is the principal semantic filter. ACT generates unit tests for each translated sample, and these tests are derived from the original source code logic rather than only from the translated code. The intent is to reduce translation bias and make the tests reflect the true intended behavior. The translated samples are then executed in Docker containers using a custom Docker Manager, which sets up language-specific containers, installs dependencies, arranges file structure, runs the translated code, and executes the tests. Only samples that pass all tests are retained (Saxena et al., 22 Jul 2025).

Mutation testing is used to improve the robustness and diversity of test suites. ACT creates a mutant by introducing a single bug through modifications of conditional operators, arithmetic operators, assignment operators, relational operators, or logical operators. If a mutant still passes all unit tests, the tests are revised and strengthened. This creates a feedback loop intended to improve coverage and reliability of test cases (Saxena et al., 22 Jul 2025).

The broader ACT literature shows that this emphasis on validated supervision has multiple realizations. TransCoder-ST keeps only candidate translations that pass all translated unit tests, with Java test suites filtered by mutation score $> 0.9$ and at least two asserts (Roziere et al., 2021). A later augmentation method automatically manufactures snippet-alignment data from program-alignment corpora by inserting comments, rewriting targets to preserve comment structure, splitting by shared comments, and discarding mismatched pairs; after filtering, it retains 135,654 pairs from an initial 139,556, a 97.2% usability rate (Zhang et al., 16 Oct 2025).

4. Controller policy, training configuration, and evaluation protocol

ACT’s controller decides whether to continue finetuning, generate more synthetic data, or stop training. It dynamically adjusts the number of epochs, learning rate, batch size, gradient accumulation, LoRA rank $r$ , LoRA scaling $\alpha$ , Deepspeed strategy, CPU offloading, and training/validation batch sizes per GPU. The training pipeline uses Deepspeed, PyTorch Lightning, mixed precision, quantized training, gradient checkpointing, gradient accumulation, FlashAttention, Deepspeed ZeRO, and CPU offloading (Saxena et al., 22 Jul 2025).

The controller also chooses between Full Supervised Fine-Tuning and LoRA. The rule of thumb described in the paper is that poor evaluation scores favor full finetuning, whereas a base model that is already reasonably good favors LoRA. This choice is conditioned by dataset size, model size, and GPU constraints (Saxena et al., 22 Jul 2025).

The reported ACT experiments finetune Qwen2.5-Coder-7B-Instruct and DeepSeek-Coder-V2-Instruct on two translation tasks: Java $\to$ Go and C++ $\to$ Rust. Training uses one 80GB A100 GPU with the model loaded in 8-bit. The LoRA hyperparameters are $r \in \{16, 32\}$ and $\alpha = 64$ ; epochs range from 2 to 5, learning rate from $3\times 10^{-5}$ to $10^{-6}$ , and batch size from 1 to 4. The initial training set averages 450 samples, later stages add 100 samples, and the validation set contains 50 samples (Saxena et al., 22 Jul 2025).

Evaluation is execution-based and uses pass@k as the principal metric:

$\text{pass@}k = P(\text{at least one of } k \text{ generated outputs passes the tests})$

This formulation makes functional behavior, not textual resemblance, the unit of success (Saxena et al., 22 Jul 2025).

The staging behavior is explicit. In one reported Java-Go run, Stage 1 generates 500 samples from 150 seeds and trains for 3 epochs; Stage 2 adds 2 more epochs because improvement is still expected; Stage 3 generates 100 targeted samples from previous failures and trains 2 more epochs, after which performance rises substantially. In another run, the controller stops after 2 stages when no further gains are anticipated. The paper also mentions a maximum of four stages in the experimental setup (Saxena et al., 22 Jul 2025).

5. Reported performance, empirical interpretation, and limitations

ACT improves open-source LLM performance on both evaluated tasks, although the gains are not uniform across all metrics. The reported execution-based results are as follows (Saxena et al., 22 Jul 2025):

Task	Model	pass@1 / pass@5
Java $r$ 0 Go	Qwen2.5-Coder-7B-Instruct $r$ 1 ACT-Qwen2.5-Coder-7B-Instruct	0.4461 / 0.5904 $r$ 2 0.4865 / 0.6642
Java $r$ 3 Go	DeepSeek-Coder-V2-Instruct $r$ 4 ACT-DeepSeek-Coder-V2-Instruct	0.5348 / 0.6048 $r$ 5 0.6248 / 0.7019
C++ $r$ 6 Rust	Qwen2.5-Coder-7B-Instruct $r$ 7 ACT-Qwen2.5-Coder-7B-Instruct	0.4184 / 0.5646 $r$ 8 0.3950 / 0.6192
C++ $r$ 9 Rust	DeepSeek-Coder-V2-Instruct $\alpha$ 0 ACT-DeepSeek-Coder-V2-Instruct	0.4500 / 0.5612 $\alpha$ 1 0.5653 / 0.6328

These results support two points emphasized in the paper. First, ACT improves both pass@1 and pass@5 for Java $\alpha$ 2 Go on both model families. Second, for C++ $\alpha$ 3 Rust, Qwen2.5-Coder-7B-Instruct shows a slight decrease in pass@1 but a noticeable improvement in pass@5, whereas DeepSeek-Coder-V2-Instruct improves strongly on both metrics. The paper concludes that ACT is especially effective for Java $\alpha$ 4 Go, and that DeepSeek adapts better overall to finetuning in this setup (Saxena et al., 22 Jul 2025).

A manual assessment was also performed on 30 generated training samples per translation task by three software developers using a 0-to-2 scale, where 0 denotes completely incorrect / misaligned, 1 partially aligned, and 2 fully correct / aligned. Correctly filtered samples reportedly received near-perfect scores, while incorrectly filtered samples scored much lower, which the paper presents as evidence that the execution-based filter was effective (Saxena et al., 22 Jul 2025).

The framework is claimed to have produced a notable increase in developer acceleration when its data generation pipeline was applied to industry-scale migration projects, but no precise numerical percentage is given in the provided text. The practical implication drawn in the paper is qualitative rather than fully quantified (Saxena et al., 22 Jul 2025).

The paper also notes clear limitations. Only two language pairs are evaluated, only two open-source models are tested, evaluation depends heavily on the quality of generated unit tests, the approach is more mature for function-level translation than for repository-level migration, and some settings show tradeoffs between pass@1 and pass@5. Future work proposed in the paper includes support for more programming languages, feedback-driven correction loops for test failures, and better handling of long-form, repository-level translation (Saxena et al., 22 Jul 2025).

6. ACT as a broader research pattern: extensions, variants, and adjacent systems

Subsequent work suggests that ACT can be read both as a named framework and as a broader design pattern for automatic refinement in code translation. One extension replaces program-level augmentation with fine-grained snippet supervision: "Automated Snippet-Alignment Data Augmentation for Code Translation" argues that program-alignment data provides full context but weak fine-grained alignment signals, automatically derives snippet-alignment data from existing program pairs, and uses a two-stage $\alpha$ 5 curriculum in which training on program-alignment data for one epoch is followed by one epoch of snippet-alignment finetuning. On TransCoder-test, that method reports consistent improvements over PA-only baselines, with a maximum gain of 3.78% on pass@k (Zhang et al., 16 Oct 2025).

Another direction moves ACT away from supervised retraining and toward agentic iterative repair. "BabelCoder: Agentic Code Translation with Specification Alignment" treats translation as a distributed, test-driven process involving a Translation Agent, a Refinement Agent, and a Test Agent. Its key abstraction is NL-Specification, a line-by-line, language-agnostic pseudocode-like summary aligned against the source code and reused for validation and repair. The framework reports improvements of 0.5%–13.5% in 94% of cases and an average accuracy of 94.16%, with the ablation of the Refinement Agent rising from 87.28% for initial translation and fixation alone to 94.16% when NL-Specification augmentation, NL-Specification validation, and Bug Scope Estimation are all enabled (Rabbi et al., 7 Dec 2025).

The privacy problem gives ACT a different architectural interpretation. "I Can't Share Code, but I need Translation -- An Empirical Study on Code Translation through Federated LLM" studies Java $\alpha$ 6 C# translation with CodeLLaMA-7B, LoRA, and federated aggregation. In that setting, raw code never leaves the client; only LoRA adapter weights are exchanged, aggregated by FedAvg or FLoRA over 20 federated rounds. The paper reports that federated models improve by at least 50% over individual models on BLEU, METEOR, and ROUGE, and that CodeBLEU improves by at least 40% over individual models, while the central model remains numerically best (Kumar et al., 10 Jan 2025).

Preference optimization introduces a different locus of automation. "Improving Code Translation with Syntax-Guided and Semantic-aware Preference Optimization" proposes CTO, which separates syntactic correctness and semantic consistency by combining compiler feedback with a learned cross-lingual semantic reward derived directly from source code. The method formulates translation as a multi-objective preference optimization problem and reports consistent gains over supervised finetuning and alternative preference-optimization baselines on TransCoder-Test and HumanEval-X (Wu et al., 13 May 2026).

Finally, ACT-style systems also require post-translation diagnosis. "Guided Debugging of Auto-Translated Code Using Differential Testing" introduces tHinter, a debugging assistant that uses AFL++, differential testing, coverage information, and heuristic localization to identify suspicious translated lines. It reports an average reduction ratio $\alpha$ 7, meaning developers review 71% fewer lines on average, and raises the likelihood of an LLM fixing translation errors in a single query by 59% (Wu et al., 16 Jan 2025).

These developments make the conceptual boundary of ACT more precise. ACT is not simply any code translator, nor is it reducible to synthetic data generation alone. The recurring pattern is automatic production of additional supervision or corrective feedback—through tests, snippets, specifications, preferences, federated aggregation, or debugging signals—followed by structured model adaptation or repair. A plausible implication is that the most durable legacy of ACT lies less in one fixed implementation than in establishing automated, execution-aware refinement as a central organizing principle for code translation research.