MatchFixAgent: Autonomous Code Translation Repair
- MatchFixAgent is a language-agnostic, autonomous framework that validates and repairs repository-level code translations using lightweight static analysis and LLM reasoning.
- It decomposes validation into six parallel semantic analyses, such as control flow and API comparison, to efficiently detect inequivalences in translated code.
- Empirical evaluation on 2,219 translation pairs demonstrates higher accuracy and repair rates with significantly lower implementation overhead than prior pair-specific methods.
MatchFixAgent is a language-agnostic, autonomous framework for repository-level code translation validation and repair. It takes a source-language function, its translated target-language counterpart, and both surrounding repositories, then determines whether the translation is functionally equivalent and, when inequivalence is detected, attempts a repair. The framework is designed for repository-scale migration settings in which existing validation approaches are often language-pair-specific, engineering-heavy, or overly dependent on inadequate inherited test suites; in the reported evaluation, MatchFixAgent is applied to 2,219 translation pairs spanning 6 programming-language pairs and 24 GitHub projects totaling 910,398 lines of code (Ibrahimzada et al., 19 Sep 2025).
1. Scope and problem formulation
MatchFixAgent addresses repository-level code translation rather than isolated snippet translation. In this setting, a benchmark instance is a translation pair: a source function and its translated counterpart, both embedded in real repositories with project-specific types, helper methods, libraries, and calling conventions. This makes equivalence validation difficult because the source and target languages may differ in type systems, library APIs, string encodings, exception behavior, mutability, ownership, error signaling, and data representations. The framework therefore treats validation and repair as a joint problem rather than as a post-processing afterthought (Ibrahimzada et al., 19 Sep 2025).
The system is described as “language-agnostic autonomous repository-level code translation validation and repair.” “Language-agnostic” refers to the fact that its core orchestration and semantic analyses do not rely on handcrafted pair-specific interoperability mechanisms; instead, the framework uses lightweight per-language static analysis built on Tree-sitter plus LLM reasoning. “Autonomous” denotes that its agents can analyze code, generate and execute tests, inspect results, and propose patches without human intervention during normal operation. “Repository-level” indicates that the framework operates with full source and translated repositories rather than standalone functions (Ibrahimzada et al., 19 Sep 2025).
The paper contrasts this design with prior repository-level systems such as AlphaTrans, Oxidizer, and Skel, which are described as tied to individual language pairs and as requiring substantial custom engineering such as language interoperability layers, dynamic instrumentation, feature maps, or hand-maintained type maps. Reported implementation sizes are 10,859 LoC for AlphaTrans, 19,052 LoC for Oxidizer, and 3,843 LoC for Skel, compared with 1,650 LoC for MatchFixAgent; adding support for each additional language reportedly requires about 280 LoC (Ibrahimzada et al., 19 Sep 2025).
Operationally, the task is defined by explicit inputs and outputs. Inputs are a source project, a source fragment, a translated project, a translated fragment, an LLM, a set of tools for the agents, and a timeout. The output is a validation-and-repair report containing an equivalence verdict, a natural-language report, and optionally a patch when inequivalence is found. The framework does not offer a formal proof system for translation correctness; it instead combines static semantic decomposition, generated executable tests, and LLM-based verdict synthesis (Ibrahimzada et al., 19 Sep 2025).
2. Multi-agent architecture and semantic decomposition
The architecture has three stages: a Semantic Analyzer, a Test Generator & Repair Agent, and a Verdict Agent. The first stage is the most distinctive. It decomposes equivalence validation into six parallel semantic analyses after lightweight static structure extraction: Control Flow Analyzer, Data Flow Analyzer, IO Analyzer, Library API Analyzer, Exception and Error Handling Analyzer, and Specification Analyzer. The paper presents this decomposition as a way to avoid a single monolithic “judge equivalence” prompt and to keep LLM reasoning focused on separate semantic dimensions (Ibrahimzada et al., 19 Sep 2025).
Before several of these analyses, MatchFixAgent constructs a control-flow graph and a simple data-flow graph for both functions. Tree-sitter parses each function into an AST. From the AST, the framework extracts basic blocks and control structures to form a CFG. For data flow, it performs a deliberately simple syntactic def-use analysis: variable names are extracted from statements, labeled as definitions or uses, associated with CFG nodes, and composed into def-use chains. The paper is explicit that this DFG computation does not handle aliasing, concurrency, or context sensitivity (Ibrahimzada et al., 19 Sep 2025).
The Control Flow Analyzer compares source and target CFGs by abstracting them into canonical node and edge types and computing Jaccard similarities on the node-type sets and edge-type sets. Its similarity score is
with threshold $0.7$. If similarity is at least $0.7$, the analyzer short-circuits and returns an equivalent verdict for control flow without calling the LLM; the paper reports that this symbolic prefilter skips about 25% of control-flow LLM invocations (Ibrahimzada et al., 19 Sep 2025).
The Data Flow Analyzer uses a related short-circuit strategy. It extracts variable data-flow paths and compares path sets using a symmetric best-match Jaccard-style similarity routine. If the resulting similarity is at least $0.7$, it returns an equivalent verdict without an LLM call; this reportedly skips about 35% of data-flow LLM invocations (Ibrahimzada et al., 19 Sep 2025).
The remaining analyzers contribute semantically different evidence. The IO Analyzer evaluates accepted inputs, produced outputs, side effects, handling of edge cases, and performance-critical complexity, and it asks for a plausible input that would expose differing behavior when inequivalence is suspected. The Library API Analyzer focuses on subtle mismatches between seemingly analogous source and target library calls. The Exception and Error Handling Analyzer compares error detection, exception raising, error types, messages or codes, recovery mechanisms, and propagation. The Specification Analyzer attempts to recover explicit and implicit contracts from signatures, type annotations, docstrings, comments, and code behavior, then compares requirements, preconditions, postconditions, invariants, and input-domain assumptions (Ibrahimzada et al., 19 Sep 2025).
Each sub-analyzer uses a short custom prompt and emits JSON with a property-level verdict and explanation. The semantic-analysis result is therefore a six-part structured report rather than a single scalar judgment. This suggests a deliberate design preference for semantic factorization over holistic prompting (Ibrahimzada et al., 19 Sep 2025).
3. Test generation, repair loop, and verdict synthesis
The second stage, Test Generator & Repair Agent, consumes the semantic-analysis reports together with the source fragment and translated fragment. This stage is implemented with an off-the-shelf coding agent—primarily Claude Code in the main experiments, with Codex in an adaptability study—and is given tools for reading and writing files, running shell commands, and, in Claude Code’s case, web search. The prompt asks it to consider the semantic analyses while producing is_equivalent, explanation, tests, and patch outputs (Ibrahimzada et al., 19 Sep 2025).
The core operational idea is to generate repository-aware executable tests rather than relying solely on inherited project tests. These tests are differential in spirit: they are written to demonstrate equivalence or expose divergence between source and translated behavior. The agent can inspect repository files and context, write tests in the source and target languages, execute them, observe failures, and, when inequivalence is found, attempt to patch the translated implementation. The paper frames this as addressing the “unknown test requirements” problem: instead of hoping that the repository’s existing tests hit the translation defect, MatchFixAgent synthesizes new tests guided by semantic differences (Ibrahimzada et al., 19 Sep 2025).
The final stage is the Verdict Agent. It receives two evidence bundles: the semantic-analysis report and the test-execution-plus-repair report. Its purpose is to validate the preceding stage’s claims and to issue the final equivalence judgment and summary. The final verdict therefore synthesizes approximate static semantic evidence and dynamic execution evidence. The framework does not define a learned global objective or calibrated confidence score; the synthesis remains LLM-based (Ibrahimzada et al., 19 Sep 2025).
Two examples in the paper illustrate how this loop operates. In a Go-to-Rust case, the source code counts Unicode characters with len([]rune(s)), while the Rust translation incorrectly uses .len(), which counts bytes. MatchFixAgent generates a Unicode test input, exposes the mismatch, and repairs the translation by changing to .chars().count(). In an Apache Commons Validator case, the Java source uses DateFormat.SHORT, while the Python translation incorrectly uses datetime.date.SHORT; the Library Analyzer flags the API mismatch, and the repair agent patches the translation to use constant 3, matching the intended style constant (Ibrahimzada et al., 19 Sep 2025).
The framework’s repair evaluation is conservative. A generated patch is counted correct only if the original project tests that previously failed on the buggy translation now pass. The paper explicitly states that MatchFixAgent’s own generated tests were not used to score repair correctness, to avoid bias (Ibrahimzada et al., 19 Sep 2025).
4. Language-agnostic implementation and engineering profile
MatchFixAgent’s language-agnostic claim is grounded in a specific engineering choice: pair-specific interoperability code is replaced with lightweight per-language static analysis plus language-neutral LLM prompting. Tree-sitter supplies parsing support for 165+ languages, and the authors report that adding a new language required only about 280 LoC in their experience with six languages. The execution environment used language-specific toolchains—Rust 1.87.0, Python 3.12.9, Java 21.0.7, Node 22.16.0, GCC 7.3.1, and Go 1.24.4—but the orchestration logic remained shared across language pairs (Ibrahimzada et al., 19 Sep 2025).
This engineering profile is part of the paper’s central comparative claim. Existing tools are described as incurring substantial pair-specific overhead because they depend on custom interoperability infrastructure, while MatchFixAgent attempts to minimize such specialization. The reported implementation size is 1,650 LoC, compared with 10,859 LoC for AlphaTrans, 19,052 LoC for Oxidizer, and 3,843 LoC for Skel; the authors characterize this as 2.3 cheaper than Skel, 6.6 cheaper than AlphaTrans, and 11.6 cheaper than Oxidizer (Ibrahimzada et al., 19 Sep 2025).
The system remains repository-dependent rather than language-oblivious. It assumes that repositories are buildable and testable in their native environments and that the coding agent can navigate files, write tests, and execute commands. It also includes only lightweight CFG/DFG extraction rather than a complete static semantics. This suggests that the framework’s portability is primarily orchestration-level rather than formal-semantics-level (Ibrahimzada et al., 19 Sep 2025).
In methodological terms, MatchFixAgent belongs to a broader shift toward repository-aware, agentic software-repair systems. Related work in this broader trend includes FixAgent, which frames debugging as a unified pipeline across localization, repair, validation, and explanation (Lee et al., 2024); HAFixAgent, which injects blame-derived repository history into APR loops (Shi et al., 2 Nov 2025); SelfHeal, which repairs bugs in LLM agents through fix-rule retrieval and critic-guided iteration (Islam et al., 20 Apr 2026); and PAGENT, which post-processes failed SWE-bench patches through repository-level static analysis and type-aware rewriting (Xue et al., 21 Jun 2025). This suggests that MatchFixAgent is part of a wider movement from one-shot patch generation toward staged, tool-using, evidence-fusing repair agents.
5. Experimental evaluation and empirical results
The evaluation covers 2,219 translation pairs across 6 programming-language pairs from 24 GitHub projects totaling 910,398 lines of code. The artifacts come from Oxidizer, AlphaTrans, Skel, and RustRepoTrans. The language-pair breakdown includes Go→Rust, Java→Python, Python→JavaScript, Python→Rust, C→Rust, and Java→Rust. Average benchmark test coverage before MatchFixAgent-generated tests was 89.6% (Ibrahimzada et al., 19 Sep 2025).
Overall, MatchFixAgent produced verdicts for 99.2% of translation pairs, with only 18 validation failures out of 2,219. Existing approaches produced verdicts for 71.6% overall. Across the full set, prior tools reported 1,140 equivalent, 449 not equivalent, and 630 validation failures, whereas MatchFixAgent reported 1,519 equivalent, 682 not equivalent, and 18 validation failures (Ibrahimzada et al., 19 Sep 2025).
On the 1,571 pairs where both MatchFixAgent and prior tools produced verdicts, agreement was 1,143 cases, or 72.8%. The authors then manually investigated disagreement cases. After filtering several cases tied to unavailable mocking or non-strictly-equivalent human translations, 145 disagreement cases remained. In those disagreements, MatchFixAgent was judged correct 60.7% of the time overall, versus 39.3% for prior tools. By benchmark family, MatchFixAgent won 84.1% of disagreements with Oxidizer, 73.5% with AlphaTrans, 53.5% with Skel, and 12.5% with RustRepoTrans (Ibrahimzada et al., 19 Sep 2025).
The repair results are stronger. For a subset of 265 buggy translations on which both techniques identified bugs and generated patches, prior techniques repaired 49/265, or 18.5%, while MatchFixAgent repaired 134/265, or 50.6%, a gain of 32.1 percentage points. On disagreement cases from the validation study that MatchFixAgent marked not equivalent and patched, 47 of 49 patches were judged correct, or 95.9% (Ibrahimzada et al., 19 Sep 2025).
The paper also reports that generated tests improved overall project coverage from 89.6% to 98.1%, an 8.5% absolute increase. Some projects showed much larger gains, including commons-fileupload with +78.1%. This supports the framework’s central claim that generated, semantics-guided tests are not merely auxiliary but materially alter the observability of translation defects (Ibrahimzada et al., 19 Sep 2025).
Two ablations further characterize the architecture. A standalone baseline agent using the same underlying LLM and agent framework but without MatchFixAgent’s semantic analyzer and guided test-generation architecture showed a 42.3% drop in validation accuracy relative to MatchFixAgent and the agreed-upon reference results. Removing only the semantic-analysis results when prompting the test generator and verdict agents reduced performance by 39.7% and increased interactions, tokens, and total time; the paper summarizes this as roughly a 5.4% average cost increase when the semantic analyzer is removed (Ibrahimzada et al., 19 Sep 2025).
6. Limitations, error modes, and interpretation
MatchFixAgent’s verdicts are not formal proofs of equivalence. The paper is explicit that equivalent judgments remain high-confidence decisions based on approximate analyses and test evidence rather than complete semantic guarantees. Several failure modes are reported. Existing tools were often wrong because of inadequate unit tests, excessively strict equivalence definitions, and language interoperability bugs. MatchFixAgent reduced those classes of error but introduced its own characteristic failures, especially hallucinated semantic differences, inadequate test generation, and infeasible input construction (Ibrahimzada et al., 19 Sep 2025).
Two qualitative examples illustrate these limits. In a textrank case, MatchFixAgent found a source/target divergence only under a map initialization state that could not arise through the repository’s public interface, leading to a false inequivalence judgment. In a RustRepoTrans case from deltachat-core, MatchFixAgent judged a C-to-Rust translation too strictly because the Rust version relied on type-system guarantees rather than reproducing a literal null-check pattern from C. The authors argue that a developer might regard the Rust translation as acceptable and idiomatic even though it is not a strict observational mirror (Ibrahimzada et al., 19 Sep 2025).
The reported disagreement profile reflects this tension. MatchFixAgent performs well on Oxidizer and AlphaTrans disagreements, moderately on Skel, and poorly on RustRepoTrans, where translations are more complex and often intentionally idiomatic rather than strictly one-to-one. A plausible implication is that MatchFixAgent is strongest when the task is strict repository-level equivalence validation and weaker when migration quality is judged relative to target-language reformulation norms (Ibrahimzada et al., 19 Sep 2025).
The paper also notes broader experimental limitations. Runs were performed only once, so repeated-run variance is not quantified. Manual disagreement analysis adjudicates whether a not-equivalent judgment is correct in sampled cases, but it does not establish full ground-truth equivalence for the entire corpus. Externally, only six languages and six language pairs were evaluated. These caveats place MatchFixAgent in the category of high-coverage, empirically effective neuro-symbolic validation-and-repair systems rather than formally verified translation checkers (Ibrahimzada et al., 19 Sep 2025).