InfCode: Adversarial Repository Repair

• InfCode is an adversarial multi-agent framework for automated repository-level issue resolution that iteratively refines tests and patches to overcome insufficient test verification.
• The framework employs a Test Patch Generator, Code Patch Generator, and Selector Agent in a continuous loop to ensure patches remain robust under evolving test conditions.
• Evaluated on SWE-bench benchmarks and extended for C++ repair, InfCode demonstrates significant gains over baselines by optimizing both test strength and patch selection.

InfCode is an adversarial multi-agent framework for automated repository-level issue resolution. It is designed around a specific failure mode in LLM-based software repair: patches can satisfy an available verification signal while still failing to correct the underlying defect when the test suite is insufficient. To address that problem, InfCode couples iterative test refinement with iterative patch refinement through an adversarial interaction between a Test Patch Generator and a Code Patch Generator, and then uses a Selector agent to choose the most reliable fix. The framework operates in a containerized environment for realistic repository inspection, modification, and validation. On SWE-bench Lite and SWE-bench Verified, it reports consistent gains over strong baselines, including 79.4\% on SWE-bench Verified (Li et al., 20 Nov 2025).

1. Problem setting and reliability objective

InfCode targets repository-level issue resolution rather than isolated function synthesis. In this setting, success depends on repository-level reasoning, accurate diagnostics, and strong verification signals. The motivating claim of the framework is that existing agent-based and pipeline-based methods often rely on insufficient tests, allowing patches to pass verification while leaving the root cause unresolved. A common misconception in automated repair is therefore that passing a current test suite is equivalent to fixing the issue; the InfCode formulation explicitly rejects that equivalence and treats verification quality itself as an object of optimization (Li et al., 20 Nov 2025).

The framework models issue resolution through the interaction of three spaces: the repository state, the evolving test suite, and the evolving patch set. In the formalization described for InfCode, let $\mathcal{T}$ denote the space of possible test suites, $\mathcal{P}$ the space of code patches, and $E(P,T,R)$ the empirical evaluation of patch $P$ on test suite $T$ in repository $R$. The optimization target is not merely a patch that passes once, but a patch that remains valid under strengthened, issue-aligned tests. This makes reliability operational rather than rhetorical: robustness is approximated through continued adversarial pressure from newly synthesized tests.

2. Multi-agent architecture

InfCode is organized around three specialized agents. The Test Patch Generator reads the issue description and repository state, generates or strengthens tests that expose the reported behavioral discrepancy, and continues to search for missing edge cases or coverage gaps after a candidate fix appears to work. The Code Patch Generator receives the current test suite and synthesizes a code patch intended to satisfy it. The Selector Agent receives the accumulated code-and-test patch pairs from the iterative process, re-evaluates them in the execution environment, and selects the most robust solution (Li et al., 20 Nov 2025).

This architecture makes the adversarial structure explicit. The Test Patch Generator is not a passive validator; it acts as a pressure source that tries to invalidate superficial fixes by strengthening the behavioral specification. The Code Patch Generator, in turn, must respond to an increasingly stringent suite rather than a static oracle. The Selector Agent closes the loop by comparing all discovered candidates under consistent empirical evaluation, considering correctness, test coverage, compatibility, and execution stability.

The overall design can be read as a decomposition of software repair into three coupled subproblems: behavioral specification tightening, code modification, and empirical selection. This suggests a broader methodological point: in repository-level repair, verification artifacts and patches are co-evolving objects rather than independent inputs and outputs.

3. Adversarial iterative refinement loop

The iterative process begins with an initial test suite generated from the issue description and repository state. At iteration $k$, the Code Patch Generator produces a patch against the current suite; if the patch passes, the Test Patch Generator attempts to strengthen the suite again. The loop terminates when strengthening no longer changes the suite, when the patch continues to pass the strengthened suite, or when the iteration cap is reached. In the notation reported for InfCode, the procedure is:

$T_0 = \text{TestGen}(I, R)$

$\text{for } k=1,\dots,N:$

$P_k = \text{CodeGen}(T_{k-1}, R)$

$\mathcal{P}$0

$\mathcal{P}$1

and the final choice is expressed as

$\mathcal{P}$2

The key technical point is that test synthesis is conditioned on the patched repository as well as on prior tests. That is, InfCode does not simply regenerate alternative tests from scratch; it strengthens the current suite in response to observed patch behavior. The paper characterizes this as an adversarial “game” between test generation and patch generation, with the goal of driving the system toward a “dynamic equilibrium” of comprehensive tests and robust patches (Li et al., 20 Nov 2025).

This loop also changes what counts as failure. A candidate patch that passes an initial suite but fails after test strengthening is treated as evidence that the original verification signal was weak, not as evidence that the search has converged. In practice, that reframes patch validation as an iterative specification-repair process.

4. Execution environment and operational workflow

InfCode runs inside a containerized environment. Each issue is isolated in a dedicated container, which serves two purposes: reproducibility and prevention of state leakage across tasks. The environment supports realistic codebase manipulation and validation rather than a restricted API-only interaction model (Li et al., 20 Nov 2025).

The implementation exposes a tool suite including bash, editor, searcher, submitter, and executor. This is significant because repository-level issue resolution typically requires mixed symbolic and operational behavior: searching the codebase, editing files, running tests, inspecting outputs, and finally materializing a patch. The patch diffs are taken with git diff, and test file modifications are ignored for fairness in the reported evaluation.

The operational workflow can be summarized as follows. The repository snapshot and issue description are loaded into the container. The Test Patch Generator synthesizes initial tests. The Code Patch Generator proposes candidate fixes. The system validates those fixes in situ. If a candidate survives, the test generator seeks additional adversarial tests. After the loop ends, the Selector Agent re-runs empirical evaluation and returns the chosen patch. The framework is released as an open-source project at https://github.com/Tokfinity/InfCode (Li et al., 20 Nov 2025).

5. Reported empirical results

InfCode is evaluated on SWE-bench Lite and SWE-bench Verified. SWE-bench Lite is described as a lightweight benchmark of 300 real issues. SWE-bench Verified is described as a curated, manually validated, strong-test-based benchmark. On Lite, the reported configuration uses DeepSeek-V3; on Verified, the abstract cites models such as Claude 4.5 Sonnet (Li et al., 20 Nov 2025).

Benchmark	InfCode result	Comparison
SWE-bench Lite	40.33\%, 121/300, avg. cost $0.26	KGCompass 36.67\%; Agentless 32.00\%; SpecRover 31.00\%; Moatless Tools 30.67
SWE-bench Verified	79.4\%, 397/500, rank 1	TRAE+Doub. Code 78.8\%; Atlassian Rovo 76.8\%; EPAM AI/Run 76.8\%; ACoder 76.4

These numbers matter for two separate reasons. First, on SWE-bench Lite, InfCode resolves more issues than the cited DeepSeek-V3-based baselines and also fixes the largest number of unique issues. Second, on SWE-bench Verified, the reported 79.4\% establishes the best result in the comparison table, with a nontrivial margin over the next entry at 78.8\% (Li et al., 20 Nov 2025).

The ablation study isolates the two central design choices: adversarial iteration and final patch selection.

Variant	Solved on SWE-bench Lite
Full InfCode	40.33\% (121)
w/o Adversarial Iteration	36.33\% (109)
w/o Patch Selection	32.33\% (97)

The ablation results indicate that both components are necessary, and that patch selection produces the larger drop when removed. In other words, InfCode’s gains are not attributable solely to generating harder tests; they also depend on retaining multiple candidate trajectories and choosing among them after re-evaluation (Li et al., 20 Nov 2025).

6. Variants, extensions, and comparative position

A language-specific extension, InfCode-C++, adapts the broader InfCode line of work to C++ repository-level issue resolution. It is described as the first C++-aware autonomous system for end-to-end issue resolution and is built around two complementary retrieval mechanisms: semantic code-intent retrieval and deterministic AST-structured querying. Its pipeline contains repository parsing, issue reproduction, patch generation, and patch selection, mediated by a Reproducer Agent, Patch Agent, and Selector Agent. On MultiSWE-bench-CPP, the paper reports a 25.58\% resolution rate for InfCode-C++ with GPT-5, outperforming the strongest prior agent by 10.85 percentage points and more than doubling MSWE-agent (Dong et al., 20 Nov 2025).

The C++ variant changes the technical center of gravity. Whereas the original InfCode emphasizes adversarial co-refinement of tests and patches, InfCode-C++ emphasizes language-aware localization and structural retrieval in repositories with overloaded identifiers, nested namespaces, template instantiations, and deep control-flow structures. This is not a contradiction but a specialization: the original framework attacks reliability through test–patch interaction, while the C++ system attacks localization and retrieval failures specific to statically typed, structurally rich codebases.

InfCode-C++ also serves as a comparison point for later work on vulnerability repair. MemRepair evaluates against InfCode-C++ on the C++ subset of Multi-SWE-bench and reports 30.58\% for MemRepair versus 25.60\% for InfCode-C++, while also reporting 15.08\% versus 13.20\% when both use DeepSeek-v3 (Liu et al., 17 May 2026). Notably, the MemRepair comparison table gives InfCode-C++ as 25.60\%, whereas the InfCode-C++ paper reports 25.58\%; both values appear in the literature. MemRepair attributes its gains to a hierarchical memory architecture and feedback-driven refinement loop, which positions it as a repository-level vulnerability-repair system rather than a general issue-resolution framework.

In broader context, contemporaneous benchmark work has increasingly separated functional correctness from instruction-following and has emphasized multi-turn refinement. IFEvalCode decouples correctness and instruction-following in controlled code generation across 1.6K multilingual test samples (Yang et al., 30 Jul 2025), while MultiCodeIF studies hierarchical constraints and reports that structured feedback can raise average constraint satisfaction from 63.0\% to 83.4\% over four refinement rounds (Duan et al., 1 Jul 2025). These results do not evaluate InfCode directly, but they align with the methodological premise that iterative feedback materially changes code-generation performance.

7. Significance and limitations

InfCode’s central significance lies in redefining repository-level repair as a co-evolution problem between executable specifications and code modifications. Instead of assuming a fixed test oracle, it treats tests as mutable artifacts that can be strengthened adversarially. That makes the framework especially relevant wherever static benchmark tests are known to be incomplete or where patches can overfit narrow validation signals (Li et al., 20 Nov 2025).

Its practical importance is reinforced by the use of full containers and repository-manipulation tools. The framework is therefore closer to CI-oriented repair or developer-assistant settings than methods that operate on abstracted code snippets alone. Reported application areas include automated code review, CI bug fixing, large-scale repository maintenance, and developer-assistant integration, although the paper’s primary evidence remains benchmark-based rather than deployment-based.

At the same time, the available evidence is concentrated on SWE-bench Lite and SWE-bench Verified for the general framework, and on MultiSWE-bench-CPP for the C++ specialization. A plausible implication is that InfCode’s strongest demonstrated advantage is under benchmark regimes where verification quality is a bottleneck. Whether the same adversarial loop remains optimal under settings dominated by localization failure, build-environment ambiguity, or language-specific structural complexity is partly addressed by InfCode-C++, and partly challenged by later specialized systems such as MemRepair. In that sense, InfCode is best understood not as a single monolithic agent, but as a methodological family centered on iterative verification strengthening, candidate repair generation, and empirical selection.