Entropy-based Code Adversarial Translation for Real-world Repository Migration

Fengyi Song; Junkang Mao; Lin Peng; Yantao Jia; Yisen Cao; Yushun Tang; Zhicheng Chen

Entropy-based Code Adversarial Translation for Real-world Repository Migration

T0 review · 4 major / 3 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 long-horizon repository migration can be automated by treating it as adversarial entropy minimization, and demonstrates a generator–discriminator framework that raises Android-to-HarmonyOS migration quality to 74.7%.

desk verdict The benchmark and the adversarial loop are worth taking seriously; the 74.7% headline is not yet earned because the optimization objective overlaps the evaluation metric and Code Entropy is never calibrated. read the letter →

arxiv 2608.09273 v2 pith:K7JAH3LW submitted 2026-08-10 cs.AI cs.SE

Yushun Tang , Yisen Cao , Zhicheng Chen , Lin Peng , Junkang Mao , Fengyi Song , Yantao Jia This is my paper · ORCID

classification cs.AIcs.SE

keywords repositorymigrationCodeEntropyadversarialoptimizationgenerator-discriminatorAndroid-to-HarmonyOSmulti-agentLLMself-evolvingmemorybenchmark

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

Automatically migrating a real software repository from one platform to another is a long-horizon task where errors pile up across thousands of interdependent files. This paper argues that the migration can be framed as adversarial entropy minimization: an independent 'discriminator' agent measures the disorder of the current translation using a unified Code Entropy score, and a 'generator' agent repairs the code under text instructions from the discriminator. Only updates that actually lower the entropy estimate are accepted, so the translated repository is driven toward a low-entropy, functionally complete state over many iterations. The authors build this loop on top of LLM agents, add a self-evolving memory tree that transfers experience across repositories, and introduce a benchmark of three real Android applications ranging from 50,000 to 300,000 lines of code. On that benchmark the framework scores 74.7% average quality versus 46.4% for the strongest baseline.

What carries the argument

The central object is Code Entropy, $H(R_t) = \frac{W^\top E}{\mathbf{1}^\top W}$, a normalized scalar in $[0,1]$ that aggregates $K=14$ entropy dimensions $e_i$, each estimated either by a deterministic rule (compilation success, leftover placeholders, permission mapping) or by an LLM judge (feature completeness, navigation reachability, UI alignment with an emulator screenshot). Each dimension carries a hand-set weight $w_i\in\{0.1,0.3\}$ that governs repair priority. The generator–discriminator loop carries the argument: the discriminator produces an estimated entropy $H_t$ plus a structured text gradient $g_t$ (file-specific issues and recommended skills), the generator applies the gradient to propose $\hat{R}_{t+1}$, and Eq. (6) accepts the candidate only when $H(\hat{R}_{t+1}) < H(R_t)$, which the authors state guarantees monotonic entropy decrease. A sliding-window stopping rule avoids premature termination on transient fluctuations, and a three-level self-evolving memory tree stores successful low-entropy trajectories as reusable, repository-agnostic patterns. Together these components turn repository migration into a discrete-space optimization loop with an explicit, computable objective.

What would settle it

Instrument ECAT to save every candidate repository that Eq. (6) rejects, then score those same candidates with the held-out Agent-as-Judge checklist; if a meaningful share of rejected candidates scores at or above the accepted final repository, then the entropy estimate is not a faithful proxy for migration quality.

Watch

Extended reading notes

Core claim

The paper's central claim is that repository-level migration is best treated not as a single translation step but as repeated adversarial optimization, with the objective being a scalar quantity the authors call Code Entropy, defined as a weighted average of fourteen defect dimensions covering compilation, structure, fidelity, permissions, navigation, and runtime behavior. The discriminator estimates this score and emits a structured text gradient: a list of concrete file-level issues with suggested repair skills. The generator acts on that gradient, and the next candidate repository is accepted only when its estimated entropy is strictly lower, a guarantee that, by construction, every accepted update monotonically reduces the estimated disorder. The loop terminates when the estimate stays below a threshold for a sliding window of iterations, and successful trajectories are distilled into a hierarchical memory tree shared by both agents. Evaluated on the new A2H-RepoBench, the approach reaches 74.7% average quality under node alignment and an agent-based functional judge, consistently beating three agentic baselines, and the ablation shows that removing the independent discriminator drops the average score to 28.4%.

Load-bearing premise

The load-bearing premise is that the Code Entropy scores produced by Eq. (2), with its hand-set weights and LLM-based estimators, reliably track true migration quality: the acceptance rule Eq. (6) guarantees only that the estimated score decreases, so if the estimates are biased, the loop can settle on a low-estimate repository that is still functionally incomplete.

Editorial extensions

If this is right

If the reported results hold, a real Android application of up to 300K lines of code can be migrated to a functionally runnable HarmonyOS repository without human code repair, which is the concrete scale at which prior agentic systems collapsed.
The independent discriminator is a key ingredient: the paper's ablation shows that letting one agent both generate and evaluate collapses the average score from 74.7% to 28.4%, with failure amplifying as the repository grows.
Emulator-based dynamic entropy evaluation protects runtime-heavy applications; removing it drops the average to 72.7% and produces visible UI defects that static checks miss.
The self-evolving memory tree transfers migration knowledge across repositories, cutting convergence iterations from 66 to 38 and roughly halving token consumption on the smallest repository.
Because the entropy dimensions are defined generically, with no application-specific checklist, the same loop should transfer to other platform pairs without re-engineering the objective.

Reading between the lines

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

Extending beyond the paper, the same adversarial entropy loop could apply to other long-horizon repository transformations, such as iOS-to-Android, Java-to-Kotlin, or framework upgrades, provided a credible Code Entropy estimator exists; the paper only demonstrates Android-to-HarmonyOS.
A subtle consequence the authors do not discuss is that the monotonic acceptance rule makes the optimization greedy: a miscalibrated early entropy estimate could lock the system into a local minimum, since rejected candidates are discarded permanently; a slower acceptance schedule that occasionally accepts entropy-increasing edits, similar to simulated annealing, is a natural stress test.
Because several entropy dimensions are judged by LLMs, the objective itself is a moving target: as the judge's notion of migration fidelity drifts with the underlying model, the loop converges to what that judge considers low-entropy, a form of reward overfitting that the paper does not measure.
A testable extension is to measure whether distilled memory patterns generalize to a repository outside A2H-RepoBench, since the current transfer experiment only evaluates transfer among the three benchmark repositories.

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.

Desk Editor's Note

read the letter

Two things to know. First, A2H-RepoBench is the real contribution: three real Android repositories at 50K/120K/300K LOC with functional checklists and a sealed evaluation protocol, two orders of magnitude larger than prior repo-translation benchmarks. Second, the headline result (74.7% vs 46.4%) is not yet trustworthy. The reader's conditional verdict is about right.

What the paper does well: the generator/discriminator split is sensible, and the w/o-discriminator ablation is compelling — collapsing to self-evaluation drops the average score to 28.4%, and the failure mode scales with repository size. The memory-tree transfer experiment (38 vs 66 iterations, roughly half the tokens) is a clean demonstration. The appendix is unusually honest: baseline prompts, evaluation details, a sealed reference protocol, artifact sizes, and base-LLM robustness all support the framework-level claims.

The soft spots, in order of seriousness.

One: the optimization objective and the evaluation metric overlap. Code Entropy's feature_check dimension (weight 0.3) is an LLM judge scoring per-feature completeness against the Android counterpart; Agent-as-Judge is an LLM judge scoring per-feature completeness against the Android counterpart. The discriminator is denied the checklist, but the feature_check prompt can reconstruct essentially the same construct from the source. Section 3.2's claim that no entropy dimension carries application-specific functional requirements is not consistent with feature_check's own definition. This does not make ECAT useless, but it means the reported functional gain may be partly an artifact of optimizing a judge-like objective.

Two: Code Entropy is never calibrated. There is no comparison against human-verified functionality, no test-suite score, no estimator-bias study. Eq. (6) guarantees monotone decrease of the estimated score, and that is definitional, not empirical. The acceptance rule is fine as an optimization device; the problem is that we do not know whether the estimated score tracks true migration quality. The dynamic/emulator dimensions help, but the static judge dimensions dominate the weights.

Three: baselines are adapted by the authors, run without error bars, and no pinned code artifact is provided. The GitHub link is nice, but a commit hash and a runnable evaluator would make the 74.7% claim checkable.

None of this sinks the paper. The benchmark, the adversarial formulation, and the memory-tree results justify a serious referee. I would send it to review and ask for: (a) calibration of Code Entropy against human or executable ground truth; (b) removal or redefinition of feature_check so the optimization signal is not the same construct as the evaluation; (c) pinned code and baseline error bars. If those land, the paper is a solid systems contribution.

Referee Report

4 major / 3 minor

Summary. The paper proposes ECAT, a generator–discriminator framework for Android-to-HarmonyOS repository migration. The discriminator estimates a weighted Code Entropy objective (Eq. 2) over 14 static and dynamic dimensions and emits structured text gradients; the generator proposes repository updates, and Eq. (6) accepts an update only when estimated Code Entropy decreases. Successful trajectories are stored in a self-evolving memory tree for cross-repository transfer. The authors introduce A2H-RepoBench, containing three real-world Android repositories (50K, 120K, and 300K LOC), and report that ECAT improves average migration quality from 46.4% (best baseline) to 74.7% under Node Alignment and Agent-as-Judge metrics.

Significance. If the reported results hold, the paper would make a substantial contribution to long-horizon repository migration: it provides a new multiscale benchmark (A2H-RepoBench), a reproducible evaluation skill (a2h-evaluate), an open-source implementation, and a clear adversarial-optimization architecture that decouples generation from evaluation. The detailed appendices on baseline prompting, evaluation grounding, and platform-friction filtering are valuable for reproducibility. However, the central claim depends critically on whether the optimized Code Entropy objective tracks true functional migration quality, and the current evidence for that link is incomplete; this must be addressed before the headline result is acceptable.

major comments (4)

[Sec. 4.1, Sec. 4.3, Table 5] The headline claim that ECAT improves average migration quality from 46.4% to 74.7% is not yet settled because the optimization objective overlaps the evaluation metric. Table 5 defines feature_check (weight 0.30) as 'per-feature completeness against the Android counterpart', estimated by an LLM judge, while Agent-as-Judge (Eq. 9 and Sec. C.2) scores per-feature completeness against a sealed Android-derived feature checklist. These are semantically the same construct, even if the discriminator is not given the literal evaluation checklist. The paper should report: (i) the correlation between Code Entropy and Agent-as-Judge with the feature_check dimension excluded, (ii) an ablation that removes feature_check from the optimization objective, and (iii) a human or executable ground-truth evaluation on at least a sample of features to show that entropy reduction corresponds to real functional improvement.
[Sec. 3.3, Eq. (6)] The statement that Eq. (6) 'guarantees that every accepted repository update monotonically reduces estimated Code Entropy' is correct, but it is a property of the estimator, not of migration quality. The acceptance rule guarantees monotone decrease of H(R), which is computed by the discriminator's rule-based and LLM-based estimators; it does not by itself guarantee monotone improvement in functional completeness. The paper never calibrates Code Entropy against human-verified functionality, an executable test suite, or any independent ground truth. I recommend adding a calibration study, e.g., comparing Code Entropy scores with human judgments on a stratified sample of migrated repositories, and reporting estimator bias and variance across iterations.
[Sec. 3.2, Table 5] The assertion in Sec. 3.2 that 'all entropy dimensions are defined at the level of generic migration defects and contain no application-specific functional requirements' is inconsistent with the feature_check dimension in Table 5, which explicitly evaluates 'per-feature completeness against the Android counterpart'. Per-feature completeness is an application-specific functional property. If the intended meaning is that the discriminator does not receive the curated evaluation checklist, the paper should state this precisely and provide the actual feature_check prompt so readers can assess how much application-specific information the LLM judge recovers from the Android source. As written, the isolation claim is too strong.
[Sec. A.1, Table 2] The w/o-Discriminator ablation demonstrates that replacing the independent evaluator with self-evaluation degrades performance, which supports the adversarial-design motivation. However, it does not establish that the independent LLM discriminator is well calibrated: a self-consistent but biased judge could still drive convergence to a low estimated entropy without improving real functionality. The conclusion that 'decoupling repository generation from quality evaluation' is the cause of the gain should be supported by evidence that the discriminator's entropy estimates agree with an external ground truth, not just that they differ from the generator's self-estimates.

minor comments (3)

[Sec. 4.1, Eq. (8); Sec. C.3] The Node Alignment score is defined in Eq. (8) as |M|/|Vs|, but Sec. C.3 defines the denominator as D_s, the pre-filter Android retention denominator after excluding platform-friction entities. Please reconcile the notation and state clearly whether |Vs| in Eq. (8) is the raw node count or D_s.
[Fig. 5] Figure 5(a) shows a threshold at 0.01, but the stopping criterion in Eq. (7) also requires a sliding window of size l=2. The caption should describe the complete stopping rule so the reader does not infer that a single crossing of the threshold terminates optimization.
[Sec. 3.2] The sentence 'higher entropy indicates greater uncertainty, inconsistency, and unresolved migration errors' uses 'entropy' as an analogy rather than an information-theoretic quantity; the paper already acknowledges this, but the phrasing in the abstract and Section 1 could be tightened to avoid implying a formal thermodynamic or Shannon interpretation.

Circularity Check

2 steps flagged · score 5.0 of 10

Partial circularity: Eq. (6) enforces monotone entropy decrease by construction, and the feature_check entropy dimension (weight 0.30) is semantically the same construct as the Agent-as-Judge metric, so part of the 74.7% claim is forced.

self definitional [Section 3.3, Eq. (6)]
"To guarantee entropy reduction, a candidate repository is accepted only if its Code Entropy decreases. ... The accepted repository is determined by ... which guarantees that every accepted repository update monotonically reduces estimated Code Entropy."

The monotonic decrease is imposed by the acceptance rule, not discovered. Eq. (6) sets Rt+1 to the candidate only when H(candidate) < H(Rt), so any reported entropy-vs-iteration curve is non-increasing by construction. The paper cites this enforced decrease as evidence that iteratively minimizing Code Entropy leads to more faithful migration, but the decrease is definitional with respect to the estimator H and carries no independent evidence that H tracks true functional quality.
self definitional [Table 5 (feature_check row) and Sec. 4.1]
"feature_check: Per-feature completeness against the Android counterpart [LLM, w=0.30] ... Agent-as-Judge evaluates functional preservation using a predefined feature checklist, where each feature is assigned a score s_i of 1, 0.5, or 0 (Full, Partial, or Missing) ... Notably, all entropy dimensions are defined at the level of generic migration defects and contain no application-specific functional requirements."

Code Entropy's feature_check dimension is an LLM judgment of per-feature completeness against the Android counterpart, and Agent-as-Judge is also an average of per-feature completeness judgments (Full/Partial/Missing) against a feature checklist. These are the same construct, so Eq. (2) with w=0.30 and Eq. (6) directly optimize what Table 1 reports. The claim that no entropy dimension carries application-specific functional requirements contradicts feature_check's own definition, and withholding the checklist does not sever the overlap because the prompt can reconstruct per-feature completeness from the Android source. The Agent-as-Judge advantage is partly an artifact of optimizing a proxy semantically identical to the headline metric.

full rationale

The paper is not wholly circular: Node Alignment, deterministic rule-based entropy dimensions, and the A2H-RepoBench construction are independent of the optimization target, and ECAT's generator-discriminator separation has real content (Table 2 shows self-evaluation collapses without it). However, two load-bearing steps reduce to the paper's own definitions. First, the claimed monotone entropy reduction in Fig. 5 is guaranteed by Eq. (6), which accepts a candidate only when estimated Code Entropy falls; the guarantee is a property of the acceptance rule, not evidence of migration quality. Second, the optimization objective H includes feature_check (w=0.30), an LLM per-feature completeness judgment against the Android counterpart, which is semantically the same construct as the Agent-as-Judge metric in Eq. (9). The paper asserts these dimensions are application-agnostic, but per-feature completeness is application-specific by definition; the discriminator's prompt can recover the checklist-like information from the Android source even though the checklist file is withheld. Consequently the improvement from 46.4% to 74.7% on Agent-as-Judge is partly forced by optimizing a near-twin of the metric, while Code Entropy is never calibrated against human-verified functionality or executable test outcomes. Score 5 reflects this partial, rather than total, circularity: a substantial fraction of the quality signal (Node Alignment, compilation, placeholder counts, dynamic emulator checks) remains external to the metric being optimized.

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

The central result rests on two self-defined components: Code Entropy (a weighted average of LLM and rule judgments) and the A2H-RepoBench evaluation (Node Alignment plus Agent-as-Judge). The optimization objective is coupled to the evaluation metric through shared semantic categories, the acceptance rule is definitional with respect to estimated entropy, and the hand-set weights and thresholds are not fully ablated. The ledger therefore concentrates in the definition of H and the evaluation protocol.

free parameters (4)

Code Entropy dimension weights w_i = 0.3 for compile, entry_nav, feature_check, data_layer_parity, permission_parity; 0.1 for the other nine dimensions…
Coarse weights chosen by hand to govern repair prioritization. Sensitivity analysis only varies all weights uniformly on Gallery and does not examine coupling with the stopping threshold.
Entropy stopping threshold epsilon = 0.01
Fixed for all experiments. The authors note epsilon should be calibrated jointly with the weight configuration, but no epsilon ablation is reported.
Sliding-window size l = 2
Stopping criterion in Eq. (7) uses the two most recent iterations; no sensitivity analysis is provided.
Node alignment matching threshold theta = 0.30
Frozen threshold for candidate platform-agnostic semantic graph pairs in Appendix C.3. The Node Alignment score depends on this choice, with no sensitivity analysis.

assumptions (4)

domain assumption Code Entropy as defined in Eq. (2), a weighted average of normalized rule-based and LLM-judged scores, is a valid and monotone proxy for repository migration quality.
The optimization loop and stopping criterion depend on this proxy. No external validation of Code Entropy against human migration experts is provided, and the proxy overlaps the evaluation metric.
domain assumption The discriminator's Code Entropy estimates are stable and comparable across iterations, so accepting updates with lower estimated entropy drives real improvement.
Eq. (6) guarantees monotone decrease of the estimated score only. If estimates are biased or noisy, convergence to the threshold may not imply functional completeness.
domain assumption CodeGraph-based platform-agnostic semantic graphs and the theta=0.30 matching threshold faithfully represent functional correspondence between Android and HarmonyOS.
Node Alignment is one of the two headline metrics, so its validity depends on this abstraction and threshold.
ad hoc to paper The authors' adapted baseline prompts preserve the intended behavior of OpenHands, RepoTransAgent, and ReCodeAgent.
ReCodeAgent's original executable-test validation was replaced with static checks, and all baseline adapters were written by the ECAT team, which can bias comparisons.

invented entities (3)

Code Entropy H(R)
purpose: Unified repository-level optimization objective and stopping criterion; a weighted average of 14 defect dimensions estimated by rules and LLM judges.
Introduced in the paper as an analogy to information-theoretic entropy. No external validation of the metric against human expert quality judgments is provided.
Text gradient g_t
purpose: Structured LLM-generated feedback listing files, issues, and suggested skills, used to guide the generator toward lower Code Entropy.
Operationalizes TextGrad-style textual gradients. No evidence of optimality, calibration, or robustness is given.
Self-evolving memory tree M_t
purpose: Hierarchical shared memory that stores successful low-entropy trajectories for cross-repository transfer.
Implementation details are described at a high level. Only one transfer curve is shown, and the distillation criteria are not fully specified.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Entropy-based Code Adversarial Translation for Real-world Repository Migration." pith.science (2026). https://pith.science/paper/K7JAH3LW

@misc{pith2026260809273,
  author       = {Pith},
  title        = {Pith review of: Entropy-based Code Adversarial Translation for Real-world Repository Migration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K7JAH3LW}},
  note         = {Machine review of arXiv:2608.09273}
}

read the original abstract

LLMs have demonstrated strong capabilities in code generation and automated program repair, but migrating an entire repository rarely produces a runnable application because long-horizon translation challenges LLM-based agents' ability to maintain repository-level migration objectives. In this work, we propose Entropy-based Code Adversarial Translation (ECAT), a multi-agent framework for automated Android-to-HarmonyOS repository migration. ECAT formulates repository migration as adversarial entropy minimization through a generator-discriminator architecture. The discriminator measures migration quality using a unified metric called Code Entropy and produces text gradients that specify both file-level generation directives and the skills needed to execute them. Guided by these optimization signals, the generator iteratively updates the repository, and each update is accepted only if it reduces Code Entropy. Repeated generator--discriminator interactions progressively drive the migration from an initial template toward a functionally complete HarmonyOS repository. Successful low-entropy trajectories are further distilled into a self-evolving memory tree, enabling transferable migration knowledge across repositories. We also introduce A2H-RepoBench, the first real-world benchmark for Android-to-HarmonyOS repository migration, covering applications from tens of thousands to hundreds of thousands of lines of code. Evaluated by node alignment and an agent-based functional judge, ECAT achieves 74.7% overall migration quality and consistently outperforms existing agent-based methods across repositories of different scales.