PaperlayerView exact revision on arXiv

Source-linked AI summary

CodeMeepo: A Multi-Agent Workflow for Repository-Level Code Migration and Optimization

Farzad Habibi, Changrong Wu, Jinzhou Jiang, Guohan Lu

arXiv:2610.34633v1cs.SEcs.AI

TL;DR

Repository-level code migration must preserve behavior across interdependent project components, yet large projects challenge model context and jointly generated tests can share blind spots. CodeMeepo uses ordered migration milestones, an independent oracle and parity assessment, then benchmark-guided optimization with conformance checks. Across nine subjects it achieves the best pass rate on every subject and passes 18% more tests than ReCodeAgent using the same model.

  • Problem

    Repository-level migration must preserve behavior across interdependent components, while large repositories exceed model context and implementation and agent-written acceptance tests may share blind spots.

    Source: §I · pp. 1–2

  • Method

    CodeMeepo coordinates specialized agents through a deterministic two-phase workflow, using ordered milestones, a fixed external oracle, parity checks that reopen the plan, and benchmark-guided optimization.

    Source: §I · p. 2

  • Results

    Across nine subjects in three language pairs, CodeMeepo has the best pass rate on every subject and passes 18% more tests than ReCodeAgent using the same model.

    Source: §I · p. 2

  • Takeaways & Limitations

    The workflow combines migration completeness checks with performance refinement followed by full-suite conformance testing and repair.

    Source: §I · p. 2

Abstract

from arXiv · show

Repository-level code migration rewrites an entire project in a new programming language while preserving its observable behavior. It is challenging because behavior spans interdependent modules, dependencies and build infrastructure must be adapted to the target ecosystem, and the source code is often the only specification. Large language model agents can now attempt these migrations end to end, but three challenges remain. First, an agent that writes both the translation and its acceptance tests may overlook the same requirements in both, leaving missing or incorrect behavior undetected. Second, large repositories can exceed a model's context window, and dividing the work into smaller tasks does not ensure that all required behavior is migrated. Third, even behaviorally correct translations may be slower than the original implementation. We present CodeMeepo, a multi-agent pipeline for complete and efficient migration of large repositories. Each milestone is evaluated against a fixed external oracle that the agents neither author nor modify. A separate parity assessment compares source and target components in scope and adds identified gaps back into the plan as required work. Ordered milestones limit the scope of each task, while cumulative regression checks guard against breaking already-migrated behavior. A benchmark-guided optimization phase addresses performance, followed by full-suite conformance testing and repair. Eight specialized agent roles communicate through file artifacts, and a deterministic state machine governs repair, deferral, scope changes, and termination. On nine subjects in three language pairs, CodeMeepo achieves the best pass rate on every subject and passes 18% more tests than a state-of-the-art multi-agent baseline using the same model. On a production daemon, its optimization phase improves half of the benchmarks, by 25% on average.

I. INTRODUCTION

Repository-level migration must preserve behavior across interdependent components while adapting dependencies and build infrastructure. CodeMeepo structures that work into two phases, using independent checks to assess migration completeness and benchmark-guided optimization to improve performance.

I. INTRODUCTION

  • Repository migration must coordinate interdependent components and dependencies, and large repositories exceed a single model context, making decomposition necessary but coordination still challenging.Later changes must not break migrated behavior, and unresolved tasks must be tracked and revisited.Source: §I · p. 1
  • When the same agentic process writes both implementation and acceptance tests, shared misunderstandings can leave required behavior undetected, while behavioral compatibility alone does not establish acceptable performance.Generated oracles can encode observed defects as specifications; even a behaviorally compatible translation may have excessive runtime or resource use.Source: §I · pp. 1–2
  • A separate parity assessment compares source and target components, and identified gaps return to the plan as required work rather than being treated as completion.A reported gap becomes a new milestone, after which the verifier runs again.Source: §I · p. 2
  • CodeMeepo is a two-phase multi-agent workflow: specialized agents migrate the repository, then optimize the accepted translation, while deterministic orchestration governs execution and termination.Agents hand work to one another through files rather than conversation.Source: §I · p. 2
  • Ordered milestones and cumulative test gates limit each migration task while checking that new work does not break previously migrated behavior.Each milestone is evaluated against a fixed external oracle that the agents neither author nor modify.Source: §I · p. 2
  • Across nine subjects in three language pairs, CODEMEEPO has the best pass rate on every subject and passes 18% more tests than ReCodeAgent; on a production daemon, optimization improves half the benchmarks by 25% on average.It passes 1,166 of 1,180 Java-to-Python tests, all 63 C-to-Rust tests, and all 105 production-daemon tests, against ReCodeAgent’s 1,029, 47, and 53, respectively.Source: §I · p. 2

II. PROBLEM DEFINITION

The paper models repository migration as discharging fixed obligations over a defined scope, using evidence suited to behavior, coverage, and implementation. Because full observational equivalence cannot generally be checked, it motivates staged work with explicit acceptance and tracking rules.

Migration instances

  • The migration instance specifies the source repository, target language and environment, in-scope components, fixed acceptance oracle, and optional benchmark suite.The scope is a set of source modules, types, functions, or exported interfaces; components outside it are exclusions rather than gaps.Source: §II · pp. 2–3

Obligations and acceptance

  • Full observational equivalence cannot generally be checked, so the paper approximates it with three obligations: build, oracle behavior, and substantive implementation of in-scope components.C1 requires the target to build; C2 requires passing the fixed oracle; C3 rules out vacuous realizations such as compatible-signature stubs.Source: §II · p. 3
  • Each oracle test is a behavioral obligation, and each in-scope source component is a separate coverage obligation.A realization map may be partial or set-valued, allowing omissions, splits, or merges; realized components must also substantively implement their source components.Source: §II · p. 3
  • C2 and C3 are independent: a target can pass every oracle test while omitting an untested component, or cover every component without behaving correctly.When benchmarks are supplied, optimization reduces their cost measure only among targets satisfying C1–C3.Source: §II · p. 3

Progressive discharge

  • Staged work bounds each stage’s obligations, preserves earlier ones with cumulative test gates, feeds parity findings into the plan, and uses explicit state rules to govern termination.Self-authored tests can help localize defects, but do not count as acceptance evidence; internal completion alone does not establish C2 or C3.Source: §II · p. 3

III. CODEMEEPO DESIGN

CODEMEEPO migrates repositories through translation and optimization phases, using specialized agents and a deterministic state machine to coordinate work and phase completion.

III. CODEMEEPO DESIGN

  • Translation constructs and assesses the port, while optimization refines its performance using a supplied benchmark.Both phases use specialized LLM coding agents that hand work to one another through files.Source: §III · p. 3
  • A deterministic state machine, rather than an agent, decides which specialized agent runs next and when a phase ends.The agents have single responsibilities and exchange work through files.Source: §III · p. 3
  • The design takes a migration instance and produces a target repository in two phases: translation followed by benchmark-guided optimization.The section introduces the controller, agent roles, acceptance oracle, end-to-end execution, and supporting mechanisms.Source: §III · p. 3

A. Separating reasoning from control

CODEMEEPO treats migration as evidence-producing actions whose routing is governed by explicit state predicates, not agent decisions. This makes control decisions inspectable while leaving agent reports and edits fallible.

A. Separating reasoning from control

  • The controller evaluates explicit predicates over persisted state to advance, repair, defer, re-scope, or terminate the workflow.Each action launches a specialized agent with standing role instructions and a stage-specific prompt; the harness runs the agent’s file-reading, command-execution, and editing loop.Source: A. Separating reasoning from control · p. 3
  • Routing is deterministic given observed state, but agents’ observations and edits are not, and processing a mistaken agent report deterministically does not make it correct.The controller relies on agent-produced reports.Source: A. Separating reasoning from control · p. 3
  • The state machine exposes repair budgets, outstanding skips, parity findings, and termination reasons, preventing an agent’s completion claim from replacing the configured stopping rule.An LLM does not choose the graph edge.Source: A. Separating reasoning from control · p. 3

B. Specialized roles and file handoffs

CODEMEEPO separates agent responsibilities through file-based handoffs and distinguishes code authorship from assessment. Its acceptance oracle is fixed independently of migration and is run by a non-editing Validator.

B. Specialized roles and file handoffs

  • Agents exchange authoritative files rather than conversational handoffs, making decisions inspectable and helping interrupted runs recover working context.JSON reports carry machine-consumed verdicts, while analysis and plans provide context for later reasoning.Source: B. Specialized roles and file handoffs · p. 3
  • Only the Translator and Optimizer change the implementation; assessment roles inspect code without editing it, while other roles write their own artifacts.The Parity agent and Benchmarker have no file-editing tool, helping separate assessment from authorship.Source: B. Specialized roles and file handoffs · pp. 3–4

C. The acceptance oracle

  • The acceptance oracle is an end-to-end suite fixed before migration; translation runs selected subsets, and post-optimization conformance runs it in full.The Validator alone interacts with the oracle and writes no code; the oracle runs in an environment reproducing target operating conditions, including dependent services and devices.Source: C. The acceptance oracle · pp. 4–5
  • Oracle conformance is evidence for behavioral correctness, not proof of equivalence; parity assessment addresses in-scope behavior the oracle does not exercise.Withholding test sources is intended to limit overfitting, but runner output and Validator diagnoses may still reveal test details.Source: C. The acceptance oracle · p. 5

D. End-to-end execution

The workflow prepares an ordered migration plan, implements and validates milestones, checks for uncovered source components, and then optimizes the accepted translation. A final full-suite milestone verifies behavior after performance changes.

D. End-to-end execution

  • The Analyzer inventories source behavior and dependencies, the Scoper orders functionality into milestones, and the Planner maps translation units and creates a compilable target skeleton.Project configuration supplies languages, paths, commands, loop budgets, and the migration brief.Source: D. End-to-end execution · p. 5
  • Each milestone is implemented and checked with unit tests and a cumulative oracle gate; failures are repaired within a bounded attempt budget or recorded as skipped.A skipped milestone’s failing oracle tests are deferred, and the run may continue under the default skip-on-give-up policy.Source: D. End-to-end execution · p. 5
  • After the last milestone, the Parity agent compares source and target components and sends identified omissions back through planning and implementation as new milestones.The translation phase ends successfully only when parity reports complete coverage.Source: D. End-to-end execution · p. 5
  • After complete parity, the optimizer makes benchmark-guided changes, then a final full-suite milestone repairs behavioral failures or undoes incorrect optimizations.The final milestone includes deferred tests and must pass for the run to succeed.Source: D. End-to-end execution · pp. 5–6

E. Design rationale and details

The design uses cumulative test gates, parity-driven gap repair, and bounded deferral to manage incomplete plans and difficult milestones. It also separates iterative performance exploration from final behavioral conformance; the evaluation covers two benchmark suites and a production migration.

E. Design rationale and details

  • Cumulative gates combine the selectors introduced by each milestone with those from earlier milestones, creating regression boundaries without running the full suite at every intermediate step.The boundary is only as comprehensive as the tests selected and available.Source: E. Design rationale and details · p. 6
  • Parity assessment links a detected source omission to new implementation and validation work, but its effectiveness depends on recognizing the gap and repairing it.The assessment complements the initial plan, which may be incomplete or unfulfilled.Source: E. Design rationale and details · p. 6
  • When a milestone gives up, only its failing oracle tests are deferred, preserving other obligations; each deferred test receives at most one dedicated retry.Deferral is a progress trade-off, not evidence that skipped behavior is satisfactory.Source: E. Design rationale and details · p. 6
  • Optimization accumulates benchmark-guided changes before a final conformance repair, but the phase does not guarantee speedup or preserve the best-performing intermediate version.The final change and subsequent conformance repairs are not automatically remeasured by the stated schedule.Source: E. Design rationale and details · p. 6

IV. EXPERIMENTAL SETUP

  • The evaluation compares CodeMeepo with ReCodeAgent and four simpler same-model baselines across two benchmark suites and a production migration.The production migration also exercises the optimization phase.Source: §IV · pp. 6–7

A. Implementation

The implementation uses a persistent controller to route specialized agents through migration stages, while the evaluation includes benchmark subjects and a production daemon. CodeMeepo leads the reported subject-level pass-rate comparison.

A. Implementation

  • An Apache Burr controller routes stages through state-guarded transitions, persists state in SQLite, and launches Copilot CLI processes for agent work.Routing depends on files agents write, rather than their session messages.Source: A. Implementation · p. 7
  • Eight custom agent roles receive stage prompts and configured project details, while the subject test suite serves as the pipeline’s acceptance oracle.The Validator can run tests and report failures but is forbidden from editing the implementation, tests, or oracle.Source: A. Implementation · p. 7

B. Subjects

  • The subjects span AlphaTrans Java-to-Python projects, CRUST-Bench C-to-Rust projects, and SONiC’s xcvrd Python-to-Rust production daemon.The xcvrd port must preserve interactions with worker state machines, Redis databases, a platform-plugin bridge, and other SONiC services.Source: B. Subjects · p. 7
  • A 105-test black-box xcvrd suite drives deployment-like events on a SONiC virtual switch and checks published tables and EEPROM access traces.It includes conformance tests against snapshots from the upstream Python daemon and grades the Python and Rust versions identically.Source: B. Subjects · p. 7
  • CodeMeepo achieves the best pass rate on every subject and passes 18% more tests than ReCodeAgent using the same model.Figure 3 marks compilation or test-suite errors with E, not a zero score.Source: Figure 3 · p. 8

C. Baselines

The baseline comparison holds the model and information conditions constant while varying workflow structure and use of test feedback. It includes ReCodeAgent, direct single-shot translation, a single-agent workflow, and repair loops.

C. Baselines

  • All suite runs use claude-sonnet-5 at medium reasoning effort, so differences reflect scaffolding rather than model choice.CodeMeepo runs with max_iter = 6 and max_parity_rounds = 4.Source: C. Baselines · p. 8
  • The single-agent Copilot CLI baseline receives the whole repository and suite command but lacks milestones, parity assessment, and repair.The single-shot LLM instead makes one independent request per module, without shared state, retries, or feedback.Source: C. Baselines · p. 8
  • Two repair-loop baselines apply up to three iterations of build repair or test repair to frozen single-shot output, retaining the final iteration.Test repair also uses suite failure output.Source: C. Baselines · p. 8
  • ReCodeAgent is implemented as a multi-agent workflow, but unlike CodeMeepo it does not systematically use existing acceptance-suite feedback to guide migration.Its Validator mainly checks against tests it translates or writes itself.Source: C. Baselines · p. 8
  • Scores are recomputed from frozen artifacts using a pristine test suite staged separately from each candidate’s source.Reported scores are passed tests out of passed plus failed tests.Source: C. Baselines · p. 8

V. RESULTS

CODEMEEPO leads the evaluated baselines on every subject, while the single-shot and ReCodeAgent results expose weaknesses in cross-module coordination and completeness. Repair recovers only part of the gap.

A. Comparison with baselines

  • CODEMEEPO passes 18% more tests than ReCodeAgent overall, 1,334 against 1,129, and has the best pass rate on every subject.It passes 105 of 105 xcvrd tests, compared with ReCodeAgent’s 53.Source: A. Comparison with baselines · p. 8
  • On commons-cli, 243 of the single-shot baseline’s 271 failures stem from one naming disagreement, while all arms score within one test on the flattest-dependency commons-fileupload.Similar interface disagreements make single-shot commons-csv uncollectable and prevent three of four single-shot Rust crates from compiling.Source: A. Comparison with baselines · p. 8
  • Figure 4 tracks oracle tests gated at each phase-1 milestone of the xcvrd run.Source: Figure 4 · p. 9
  • Build-guided repair raises commons-validator to 382 of 462 passes, but test-guided repair reaches only 370 and 403 on commons-cli and remains below CODEMEEPO’s 380 and 452.No repaired crate compiles in CRUST-Bench.Source: A. Comparison with baselines · p. 9
  • ReCodeAgent’s whole-repository translation, self-authored validation, and lack of parity checking leave gaps, including four xcvrd behaviors no test exercises that CODEMEEPO recovered as milestones.On xcvrd, ReCodeAgent passes 53 tests versus CODEMEEPO’s 105.Source: A. Comparison with baselines · p. 9

B. CODEMEEPO on xcvrd

On xcvrd, five optimization rounds improved five of ten benchmarks while preserving test conformance. The run also expanded milestone and test coverage after parity checks identified uncovered behavior.

B. CODEMEEPO on xcvrd

  • The 37 source modules became 73 translation units across thirteen initial milestones, with the cumulative gate reaching the full 105-test suite at M12.Parity then identified four uncovered source behaviors, prompting three additional milestones and a further milestone for command-line options.Source: B. CODEMEEPO on xcvrd · p. 9
  • Across 23 measurements spanning events, idle resource use, steady-state work, and shutdown, five optimization rounds improved five of ten benchmarks by more than 5%, averaging 25%.Reported gains included 21.6% fewer hardware reads and 12.2% less CPU use when idle.Source: B. CODEMEEPO on xcvrd · p. 10
  • Parity added four milestones beyond the original plan for behaviors no oracle test exercised, and phase 1 ended with 320 unit tests, up from 25 at M0.The 18 milestones included added debounce behavior, startup configuration handling, runtime DOM polling updates, and original command-line options.Source: B. CODEMEEPO on xcvrd · p. 9
  • Validators and the Benchmarker spent 3.5–5.9% of sessions in model calls, versus 96–98% for the Scoper, Planner, Parity agent, and Optimizer.Table III describes the last recorded session for each role; its Model column is model-call share, and its Calls column counts tool calls.Source: B. CODEMEEPO on xcvrd · p. 9, Table III · p. 9
  • The full-suite conformance milestone tested all 105 tests after accumulated optimization changes, repairing failures or undoing changes that could not be made correct.The ten benchmarks covered 23 measurements across startup, hardware events, idle resource use, steady-state work, and shutdown.Source: B. CODEMEEPO on xcvrd · pp. 9–10

VI. RELATED WORK

Related work addresses translation, repository editing, multi-agent migration, validation, and performance optimization; CODEMEEPO emphasizes integrating progress accounting with post-translation coverage feedback. Its conclusion presents deterministic workflow structure as a way to make migration progress and acceptance evidence inspectable without treating an LLM verdict as proof.

VI. RELATED WORK

  • Prior work addresses translation fragments, repository-wide edits, compiler feedback, and specialized verification; CODEMEEPO’s distinction is workflow-level integration of progress accounting and coverage feedback.The paper characterizes its parity coverage report as a fallible assessment, not a verifier.Source: §VI · p. 10
  • Unlike ReCodeAgent’s whole-repository translation and mainly self-authored validation, CODEMEEPO uses gated milestones and parity findings to create bounded re-scoping work.The related-work discussion distinguishes this integration from deterministic orchestration, multiple agents, or repair loops considered individually.Source: §VI · p. 10

VII. CONCLUSION

  • CODEMEEPO’s conclusion combines deterministic routing, cumulative milestone gates, parity-driven plan reopening, bounded repair, and a repairable conformance milestone for performance changes.These mechanisms make progress and acceptance evidence inspectable without treating an LLM verdict as proof.Source: §VII · p. 10
  • Across nine subjects, CODEMEEPO has the best test pass rate on every subject; on the production daemon it passes 105 tests versus ReCodeAgent’s 53.Its parity loop added four milestones beyond the plan, and five optimization rounds improved half the benchmarks by 25% on average.Source: §VII · p. 10

Related papers

Loading 2610.34633v1…