A Single Patch Is Not Enough: Deterministic Fusion of Repair Candidates
July 02, 2026
Abstract
Modern LLM coding agents are commonly evaluated using pass@\(k\), but developers typically apply a single final patch in real-world settings. This pass@\(k\)-to-pass@1 gap is a post-generation problem: a candidate patch pool may contain a correct patch, but the system must decide which one to suggest to developers. Existing post-generation approaches mainly rank whole candidates, filter them with tests, or query an LLM judge, but none deterministically reuse shared edit-atom evidence to both select and construct the final patch. Thus, we propose PatchFusion, a deterministic atomic evidence fusion approach for candidate patches that consults no test outcome at decision time. PatchFusion first fuses whole-diff agreement into a repair neighborhood, selects an auditable representative, and then applies evidence-constrained fusion (ECF) to retain repeated edit atoms and prune unsupported parts. To evaluate this setting, we build PatchFuseBench, a fixed-pool benchmark covering SWE-bench Verified, SWE-bench Multilingual, and Defects4J candidate patches.
On PatchFuseBench, PatchFusion solves 426/500 bugs on SWE-bench Verified and 236/300 on SWE-bench Multilingual, and reaches 87/371 plausible patches on Defects4J, outperforming every matched candidate-pool selector on all three. PatchFusion recovers 41 and 27 bugs that no single source solves (30 and 18 more over the best single source), repairs that require combining evidence across candidates rather than choosing one patch. It decides in only 3.28 ms per bug, consulting no test or model at decision time. Ablation studies show that ECF adds \(+5/+6/+9\) solved bugs by recovering in-pool repairs that selection misses, with no observed regression, and that PatchFusion’s gains remain stable as candidate pools are resampled. On these complementary multi-source pools, cross-candidate evidence recovers more correct patches than the test-based and LLM-based selectors we evaluate, at orders-of-magnitude lower cost, reaching within 96.2% and 89.7% of the candidate-reachable ceiling on the two SWE-bench benchmarks.
1 Introduction↩︎
LLM coding agents have improved rapidly and now resolve a large and growing share of real-world software issues, from bug fixes to repository-level edits [1]–[3]. However, behind each reported result, there is not one answer but many: a coding agent samples \(k\) candidate patches per bug and is scored by pass@\(k\), which counts a bug as fixed when any of the \(k\) samples is correct [4]. A developer applies only a single pass@1 patch, because validating and reviewing every candidate is budgeted work [5], [6] that prior repair-targeted studies also quantify [7], [8]. Because pass@\(k\) can far exceed pass@1, repairs that already sit in the sampled pool are lost the moment one patch must be chosen [9]. This loss grows once the pool spans systems: on SWE-bench [10], different agents and models fix overlapping but distinct bugs, and combining their patches covers far more than the best single system [11]–[13], reaching 443 of 500 against 396 on Verified and 263 of 300 against 218 across 7 models of a multilingual pool. A fixed candidate pool therefore already holds many more repairs than the one patch a developer applies; the open problem is how to surface them.
Correct fix may already be in the attempts. It just has to be pieced together from the parts each of them got right.
Surfacing them is a post-generation problem: once the pool is fixed, the system must commit to a single patch without re-running the sampling that produced it. This is hard because a candidate that looks plausible is often still wrong [14], [15], while the correct fix is usually present in the pool yet easily mis-selected, and the edits that compose it often recur across several otherwise-imperfect candidates. The common response is to select or rank whole candidates by how far they agree [16], which is cheap enough for a pool whose expensive sampling is already paid for; methods that recover more typically do so by spending test runs or extra model calls per bug.
However, existing approaches still face two major limitations:
Patch selectors are limited to the best whole patch. Millisecond-cost selectors treat the pool as a set of whole-diff alternatives and score each submitted diff as one unit: Agentless keeps the patch that the most candidates reproduce exactly [17], medoid and similarity selectors return the diff most central to the pool [11], [18], and rank-aggregation selectors such as Borda, Copeland, and MC4 merge several orderings into one [19]. All of them credit a fix only when an entire candidate already matches, so they cannot exceed the per-bug candidate-reachable ceiling and cannot recover a fix that no single candidate fully expresses; when no whole candidate is correct, the repair already present in fragments is lost. The correct local edits often recur across several otherwise-failing candidates, evidence that is free because it comes from the diffs already available, yet whole-diff scoring discards it.
Effective methods pay for each bug in tests or model calls. The selectors that beat simple consensus buy their gains per bug: test and dynamic-impact selectors re-run the suite or measure execution differences [20], [21], learned correctness predictors score each patch with a trained model [22], [23], LLM-as-judge selection prompts a model to rank the candidates [24], and generative fusion such as self-consistency, CodeT, and universal self-consistency asks a model to synthesize a new fused program [25]–[27]. Each adds seconds of inference, a dollar cost, and a dependence on an online model at the step that should add only milliseconds, the marginal decision over a pool that was already paid for. Beyond this cost, generative fusion carries a further risk: the program it emits need not trace to any candidate and is unverified before validation, which is less auditable when the budget allows only one patch.
This paper. To close these gaps, we propose PatchFusion, a deterministic patch-fusion approach for fixed candidate pools. Unlike free-form generative fusion, PatchFusion recombines only repeated edit evidence and keeps every output auditable against the repository state or the submitted candidates, all at decision time, before tests are run or run-quality metadata is available. Deciding without test outcomes is not only cheaper but harder to exploit: passing the provided tests does not imply a correct fix [14], [15], and as repair models increasingly optimize against the evaluation tests, any selector that trusts test outcomes inherits that exploit, whereas PatchFusion’s static cross-candidate agreement never consults a test, so it does not add another test-outcome-dependent selection channel. PatchFusion completes fusion in four steps: it (i) collapses exact duplicates into support counts, (ii) fuses whole-diff agreement into a repair neighborhood, (iii) selects an auditable representative under the pool structure, and (iv) applies evidence-constrained fusion (ECF) to keep edit atoms repeated across candidates and prune unsupported ones.
On SWE-bench Verified, SWE-bench Multilingual, and Defects4J, PatchFusion solves 426/500 and 236/300 SWE-bench bugs and produces 87/371 plausible Defects4J patches, repairing 38.0 and 23.7 more bugs than uniform random selection and outperforming consensus and LLM-based selectors. Ablation studies show that ECF adds \(+5/+6/+9\) solved bugs across the three benchmarks with no observed regression. PatchFusion runs in 3.28 ms per bug, two to three orders of magnitude below the model-based selectors. These results indicate that static cross-candidate agreement, rather than test-based validation or model judgments, can expose most reachable repairs at low cost.
The main contributions of our work are as follows:
Approach. We propose PatchFusion, a deterministic four-step patch-fusion approach that combines exact support, repair-neighborhood fusion, representative selection, and evidence-constrained fusion (ECF) to recombine repeated edit evidence into an auditable patch.
Benchmark. We construct PatchFuseBench, a reusable patch-fusion benchmark that packages fixed multi-system candidate pools from public leaderboard and repair runs on SWE-bench Verified, SWE-bench Multilingual, and Defects4J together with cached official labels, so any pooled candidate is scored without rerunning tests, while newly generated patches are scored by the official oracle.
Experiments. On all three pools, PatchFusion solves more bugs than uniform random selection, external ranking/consensus baselines, and strong DeepSeek-V4-Pro baselines.
Analysis. An ablation and a case study show that ECF is a content-fusion layer that recovers mis-selected repairs with no observed regression, constructing the submitted patch from repeated atoms (absent from the pool in 8 SWE-bench cases) rather than copying a candidate.
2 Motivating Example↩︎
Figure 1 shows a concrete case from SWE-bench Verified, django__django-14315. The bug is in Django’s dbshell: when launching the database shell, the client passes env={} to
subprocess.run, which replaces the child environment with an empty one instead of inheriting os.environ. The fix is to pass env or None so the child inherits the parent environment, and it spans 2 scopes: the
PostgreSQL client must return env or None from settings_to_cmd_args_env, and the base client must forward env or None into subprocess.run in runshell.
In this candidate pool, no submitted candidate solves the bug: all 6 candidates are unresolved by the official runner. The failures are complementary rather than redundant. Some candidates repair only the producer side (the returned
environment), others repair only the consumer side (the subprocess.run call), and the rest add tests or comments without completing the fix. A ranking or selection method can only return one of these whole diffs unchanged, so it cannot solve
the bug: the correct repair exists in the pool only as separated fragments, never as a complete patch.
Evidence-constrained fusion (ECF) instead reasons below the whole-diff level. It decomposes candidates into scope-local edit atoms and keeps those repeated across candidates (the producer-side atom return args, env or None and the
consumer-side atom env=env or None, each supported by 3 candidates), while dropping unsupported extras such as added tests or comments. Fusing these 2 supported atoms across both scopes reconstructs a single repository-backed patch that the
official SWE-bench runner resolves.
This patch is not an exact submitted candidate. The pool contained 0 solved patches, yet PatchFusion assembles a solved one from the locally correct edits of several failed candidates. This is what separates patch-level evidence fusion from candidate selection: PatchFusion recovers a repair that no single candidate expresses, while keeping the output auditable, since it is reconstructed against the checked-out repository state and traced back to the supported candidate atoms. The same audit rule holds throughout our evaluation; Defects4J pass@10 pools expose method bodies for atom-level reconstruction, and SWE-bench pools additionally allow scope reconstruction from the checked-out repository, so ECF can submit a new but auditable diff when the static guards are satisfied.
3 Approach↩︎
PatchFusion turns a fixed candidate pool into one auditable final patch in four deterministic steps (Figure 2): (1) candidate view and exact support collapses exact-duplicate diffs into support counts; (2) repair-neighborhood fusion groups candidates that touch related files and share edit vocabulary; (3) representative selection chooses one representative under the pool structure, admitting a local edit only under a same-surface guard; and (4) evidence-constrained fusion (ECF) keeps the edit atoms repeated across candidates and prunes unsupported ones.
3.1 Step 1: Candidate View and Exact Support↩︎
Step 1 reduces the raw pool to what the selector may inspect at decision time, and records how often each distinct fix recurs. The input is an unordered candidate pool for a bug, and every evaluated pool exposes unified diffs. From these PatchFusion builds a decision-time view of diff-derived fields, duplicate counts, and unlabeled pool structure only, excluding validation outcomes and run-quality metadata. It then collapses exact-duplicate diffs into a distinct-patch pool \(\widetilde{\mathcal{P}}_b\), giving each distinct candidate a support count equal to the number of raw candidates that share its canonical diff; content-different diffs stay distinct even when they are semantically similar.
3.2 Step 2: Repair-Neighborhood Fusion↩︎
Step 2 groups candidates that agree on what to change into repair neighborhoods, then keeps the grouping the pool most agrees on. Agreement between two candidates is measured on the files they touch and the identifier-like tokens they edit. For a candidate \(p\), let \(F(p)\) be its touched-file set and \(T(p)\) the identifier-like token set from its unified diff; for a pair \(p_i,p_j\), file and token overlap are the Jaccard similarities \[J_F(i,j)=\frac{|F(p_i)\cap F(p_j)|}{|F(p_i)\cup F(p_j)|},\quad J_T(i,j)=\frac{|T(p_i)\cap T(p_j)|}{|T(p_i)\cup T(p_j)|}.\] Pairs that share no file evidence or no token evidence are never linked. For the rest, PatchFusion avoids a fixed similarity cutoff: it considers only the overlap graphs induced by the distinct overlap levels actually present in this pool, a finite set \(\mathcal{G}_b\) of candidate granularities for bug \(b\). Among these it keeps the granularity whose induced neighborhoods make the Step-3 routing decision most decisive (made precise in Step 3), and takes the connected components of that graph as the repair neighborhoods.
PatchFusion then scores each neighborhood. For a neighborhood \(N\) it computes four static signals, \[\begin{align} \mathrm{Sup}(N)&=\sum_{p\in N}\mathrm{sup}(p),\\ \mathrm{Var}(N)&=|N|,\\ \mathrm{Coh}(N)&=\frac{1}{|N|(|N|-1)} \sum_{\substack{p,q\in N\\p\ne q}}J_T(p,q),\\ \mathrm{Conc}(N)&=-|\{F(p)\mid p\in N\}|, \end{align}\] with \(\mathrm{Coh}(N)=0\) for singletons, capturing how much pooled support, how many variants, how cohesive, and how file-concentrated the neighborhood is. Neighborhoods are ranked by a pairwise majority-Copeland vote over the four signals: the neighborhood that is larger on more of them wins each pairwise comparison, scored as wins minus losses, with ties broken by the ordinal signal tuple and a canonical-diff hash. PatchFusion takes the top-ranked neighborhood \(N^\star\), the repair surface on which all later representative changes must stay.
3.3 Step 3: Representative Selection↩︎
Step 3 picks one auditable representative inside the top-ranked neighborhood \(N^\star\), optionally upgrades it to a stronger local edit, and routes between these two options by pool structure alone. The default representative balances exact support with token centrality; for a candidate \(p\), \[C_T(p)=\frac{1}{|\widetilde{\mathcal{P}}_b|-1}\sum_{q\in\widetilde{\mathcal{P}}_b,q\ne p}J_T(p,q),\] and PatchFusion ranks members of \(N^\star\) by a pairwise majority vote over \(\mathrm{sup}(p)\) and \(C_T(p)\). It also considers replacing this representative with a stronger local edit candidate from the same neighborhood, admitted only under the same-surface guard: a local candidate \(p\) is eligible only when it stays on the representative’s surface, with its touched-file set contained in that of the current representative \(c\) (\(F(p)\subseteq F(c)\), an equal surface or a strict contraction) or confined to the same subsystem, so it never moves to an unrelated file. Among eligible local candidates, PatchFusion takes the best under a lexicographic support order (file-surface support, edit-region support, edit-token centrality, exact support, compactness, deterministic hash) and replaces the representative only when that candidate is strictly better.
The choice between the neighborhood representative and the local edit is routed by two pool-level confidences. Let \(\mu\) be the mean token centrality over the distinct pool and \(\phi\) the repair-neighborhood fragmentation ratio, the number of induced neighborhoods divided by the number of distinct candidates; then \[C_{\mathrm{nbr}}=\mu(1-\phi),\qquad C_{\mathrm{loc}}=(1-\mu)\phi .\] \(C_{\mathrm{nbr}}\) is high when a token-central pool fragments into few neighborhoods, and \(C_{\mathrm{loc}}\) when a token-diffuse pool fragments into many. The fragmentation \(\phi\), and hence both confidences, depends on the overlap graph, so we write \(C_{\mathrm{nbr}}(G)\) and \(C_{\mathrm{loc}}(G)\) when the graph matters. PatchFusion takes the neighborhood-first representative when \(C_{\mathrm{nbr}}\ge C_{\mathrm{loc}}\) and the same-surface local edit candidate otherwise. The same gap also fixes the Step-2 granularity: among the candidate graphs \(\mathcal{G}_b\), PatchFusion keeps the view \(G^\star=\arg\max_{G\in\mathcal{G}_b}|C_{\mathrm{nbr}}(G)-C_{\mathrm{loc}}(G)|\), the one whose routing is most decisive. In this diff-only path the chosen output is still one submitted candidate diff from the pool.
3.4 Step 4: Evidence-Constrained Fusion↩︎
Step 4 is the content-level stage: it rebuilds the representative from the edit atoms that recur across candidates, drops the unsupported ones, and accepts the result only when it clears the static acceptance guards. PatchFusion decomposes each candidate into scope-local edit atoms relative to the buggy scope, where an atom \(a=(I,R)\) pairs a contiguous buggy-scope interval \(I\) with its replacement text \(R\). Atoms vote only within the same scope, so edits from different methods, classes, or modules never replace one another. These scopes are built with language-aware parsers from candidate method bodies or AST boundaries in the checked-out repository, a Python AST locator and tree-sitter grammars for the other languages, falling back to a brace-balanced block only when a scope cannot be parsed.
Let \(\mathcal{S}_b\) be the repair scopes for bug \(b\), and for a candidate \(p\) and scope \(s\in\mathcal{S}_b\) let \(A_s(p)\) be its atom set; an atom’s candidate-pool support is \[\mathrm{sup}_s(a)=|\{p\in\widetilde{\mathcal{P}}_b \mid a\in A_s(p)\}|,\] and \(\mathcal{A}_s=\bigcup_{p\in\widetilde{\mathcal{P}}_b}A_s(p)\) is the scope’s atom vocabulary. For the selected representative \(c\), ECF admits an atom from \(\mathcal{A}_s\) only when it is scope-compatible with \(c\), meaning it edits a scope already touched by \(c\) and does not overlap an accepted atom on the same buggy interval, and is supported by another candidate. The fused atom set is chosen by a lexicographic evidence order rather than a weighted score: ECF first requires compatible, cross-candidate-supported atoms, then prefers larger aggregate support, and uses compactness only to break support-equivalent choices.
ECF accepts a reconstructed patch in one of two modes, both keeping only cross-candidate-supported atoms. The default contraction mode rewrites a single scope and is accepted only when it is non-expanding, strictly shorter, and evidence-dominant: \[\begin{align} &\mathrm{Surf}(\mathrm{ECF}(c))\subseteq \mathrm{Surf}(c),\\ &\mathrm{tok}(\mathrm{ECF}(c)) < \mathrm{tok}(c),\\ &\mathrm{ASup}(\mathrm{ECF}(c))>\mathrm{ASup}(c) \quad\text{or}\quad \mathrm{Exact}(\mathrm{ECF}(c))>1 , \end{align}\] where \(\mathrm{Surf}\) is the touched scope/file surface, \(\mathrm{ASup}\) sums edit-atom support, and \(\mathrm{Exact}\) counts exact candidate support when the reconstruction maps to an existing candidate. When the supported repair instead spans several scopes, ECF forms a supported scope-union: it unions up to \(K=3\) non-overlapping scope bodies whose edit atoms are each repeated across at least 2 candidates, accepted only under a compactness gate (bounded fused tokens and an edit-token overlap with the base revision below \(0.8\)).
4 Experimental Setup↩︎
4.1 Task and Decision-Time Boundary↩︎
We study fixed candidate-pool patch fusion after multiple repair runs have already produced candidate patches for the same bug. For a bug \(b\), let \(\mathcal{R}=\{r_1,\dots,r_m\}\) be the fixed set of available repair runs and let \(\mathcal{P}^{\mathrm{raw}}_b=\{p_{b,r}\mid r\in\mathcal{R}\}\) be the raw candidate pool. Because different runs can submit the same unified diff, PatchFusion collapses exact clones into a distinct-patch candidate pool \(\widetilde{\mathcal{P}}_b\) before selecting or reconstructing one final patch \(\tilde{p}^{\star}_b\). At decision time the selector uses no test outcome or run metadata: it may inspect candidate artifacts (unified diffs, hashes, and exposed method bodies), exact duplicate counts, and unlabeled pool structure (file and token overlap and the induced repair neighborhoods), but never test outcomes, official solved labels, leaderboard rank or run pass rate, or run identity and source order. Outcome labels are attached only after the final patch is produced.
4.2 Benchmark↩︎
We construct PatchFuseBench, a reusable patch-fusion benchmark that assembles fixed multi-system candidate pools from public leaderboard and repair runs on SWE-bench Verified, SWE-bench Multilingual, and Defects4J, each pool paired with cached official outcome labels that score any pooled candidate without rerunning a test, while patches generated outside the pool are scored by the official oracle. Tables use benchmark-facing names for its three pools: SWE-bench Verified is the 500-bug official Verified pool, SWE-bench Multilingual the 300-bug public multilingual pool, and Defects4J the primary Defects4J pass@10 pool.
We evaluate on two fixed cross-run SWE-bench candidate pools. SWE-bench Verified [10] uses the submitted patch predictions from 6 official SWE-bench Verified entries on the public leaderboard [28]: Live-SWE-agent with Claude Opus 4.5 and with Gemini 3 Pro Preview [29], TRAE with Doubao-Seed-Code [30], Atlassian Rovo Dev [31], EPAM AI/Run Developer Agent with Claude 4 Sonnet [32], and ACoder [33]. SWE-bench Multilingual [28] is formed from 7 public repair runs: Gemini 3 Flash, Claude Opus 4.6, Claude Opus 4.5, GLM-5, Gemini 3 Pro, MiniMax 2.5, and Kimi K2.5. These are the first-page leaderboard entries (snapshot April 2026) that provide downloadable, format-compatible patch predictions; first-page entries without usable prediction files are excluded. We additionally evaluate on Defects4J [34] by reusing Defects4J pass@10 candidate pools produced by MORepair [4], which contain 371 Java bugs and 10 generated candidate repairs per bug.
We release each source’s candidate count, duplicate rate, and per-source statistics with the artifact; where a source has an empty or missing prediction for an instance, that single entry is dropped only for that source.
4.3 Baselines↩︎
Our main comparisons use matched candidate-pool selectors: each receives the same unordered candidate pool as PatchFusion and obeys the same decision-time boundary, so any difference reflects the selection rule rather than the generation stack. Table 1 groups the baselines into families of post-generation selectors by granularity and decision-time properties; whole-diff selectors dominate, and among the families we evaluate, only PatchFusion fuses edit atoms from within candidate patches while staying test-free, model-free, and deterministic.
| Family | Granularity | Test-free | Model-free | Determ. | Representative |
|---|---|---|---|---|---|
| Minimization | whole patch | ✔ | ✔ | ✔ | Minimal-change [35] |
| Consensus | whole patch | ✔ | ✔ | ✔ | Token medoid [11] |
| Rank aggregation | whole patch | ✔ | ✔ | ✔ | Borda/Copeland/MC4 [19] |
| Learned ranker | whole patch | ✔ | \(\times\) | ✔ | LM naturalness [36] |
| LLM-as-judge | whole patch | ✔ | \(\times\) | \(\times\) | DeepSeek-V4-Pro listwise |
| LLM-generated | free-form | ✔ | \(\times\) | \(\times\) | DeepSeek-V4-Pro fusion |
| Test-based | whole patch | \(\times\) | ✔ | ✔ | Agentless [17] |
| Evidence fusion | edit atoms | ✔ | ✔ | ✔ | (ours) |
4pt
Two accounting rows frame the pool, the uniform-random expected solved count and the best single source, the latter a post-hoc reference because identifying it needs labels unavailable at decision time. The deterministic selectors are minimal-change (the shortest, new-file-avoiding patch, an APR minimization control [35]), token medoid (the distinct patch most central to the pool by token overlap), hunk consensus (the candidate with the strongest changed-line support, without PatchFusion’s neighborhoods or routing), the Borda, Copeland, and MC4 rank-aggregation controls [19], in which each candidate ranks the others by patch similarity weighted by its run support and the three methods aggregate those rankings (MC4 with a damped Markov chain), and the Agentless exact-identity vote [17]. The LM naturalness ranker is a frozen CodeGen-350M model that picks the candidate with the lowest mean negative log-likelihood over added lines, implementing LM-based patch prioritization [36] under the naturalness hypothesis for software [37]. We deliberately exclude supervised learned patch-correctness predictors [22], [23], [38] from the matched selectors, because training one needs labeled correct and incorrect patches that for these benchmarks would have to come either from the benchmarks themselves (contamination) or from an off-distribution released checkpoint, whereas the naturalness ranker is the learned-model selector that needs no such labels. Two model-based selectors run a DeepSeek-V4-Pro endpoint (temperature 0, candidates in hash order, JSON output): a listwise judge that chooses one submitted candidate, and a free-form fusion baseline that instead asks the model to emit a final patch.
As a single test-based reference point, the Agentless row restricts the exact-identity vote to candidates that pass the benchmark’s regression tests (the PASS_TO_PASS tests on SWE-bench and the relevant tests in the reused
Defects4J validation), voting over the survivors; its test-free counterpart is the Agentless w/o test row. It is the only row that consults test outcomes (one regression run per candidate), so it sits outside the matched test-free selector family,
and we report it only to check whether test access lets a strong baseline beat the test-free PatchFusion.
4.4 Evaluation Metrics and Protocol↩︎
Every selector emits one final patch per bug. We evaluate that final patch with each benchmark’s official outcome oracle, never a self-reported one: exact submitted candidates carry the official leaderboard evaluation of their run, and the new patches ECF emits are scored by the same official SWE-bench runner. On SWE-bench, the primary metric is solved count: the number of benchmark instances whose final patch passes the official SWE-bench evaluation. On Defects4J, the primary metric is plausible count: the number of final patches that pass the stored Defects4J validation tests in the reused MORepair artifacts. For a benchmark \(B\) with \(N\) bugs, let \(p_b^S\) be the patch emitted by selector \(S\) for bug \(b\), and let \(y_b(p)\in\{0,1\}\) denote the post-hoc benchmark outcome label. The headline count is: \[\mathrm{Count}(S)=\sum_{b\in B} y_b(p_b^S).\] The uniform-random expectation is computed on the same distinct candidate pool: \[\mathbb{E}[\mathrm{Rand}]= \sum_{b\in B}\frac{1}{|\widetilde{\mathcal{P}}_b|} \sum_{p\in\widetilde{\mathcal{P}}_b} y_b(p).\] In the main fixed candidate-pool comparison, \(\Delta_R\) is the count difference from this expectation: \[\Delta_R(S)=\mathrm{Count}(S)-\mathbb{E}[\mathrm{Rand}].\]
For paired comparisons, a win is an instance solved by PatchFusion but not by the comparator, and a loss is an instance solved by the comparator but not by PatchFusion. Instances where both methods have the same outcome are paired ties and are excluded from the W/L test statistic. For a comparator \(C\), the paired counts are: \[\begin{align} W(S,C)&=|\{b\mid y_b(p_b^S)=1\land y_b(p_b^C)=0\}|,\\ L(S,C)&=|\{b\mid y_b(p_b^S)=0\land y_b(p_b^C)=1\}|. \end{align}\] We report W/L counts and use an exact two-sided paired signed test over these outcome-discordant instances. Holm-Bonferroni correction is applied within each planned matched candidate-pool paired-baseline family for each SWE-bench candidate pool, with the corrected per-pool tests released in the artifact. Uniform-random and best-single-source are accounting quantities, not deployable selectors, so they are excluded from the matched candidate-pool paired family; we additionally report a per-instance comparison of PatchFusion against the best single source as a complementarity check (Section 5).
4.5 Research Questions↩︎
RQ-1: How effective is PatchFusion for final-patch production from fixed candidate pools? We compare PatchFusion with matched candidate-pool selectors on PatchFuseBench under the same decision-time boundary, reporting whole-benchmark counts and paired W/L tests against the ranking, consensus, Agentless, LM-naturalness, and DeepSeek-V4-Pro baselines, and analyzing why the same model’s free-form fusion underperforms its selection.
RQ-2: Which components account for the gains, and where do residual misses remain? RQ-2.1 ablates each design choice (repair-neighborhood fusion, local edit evidence, the same-surface guard, pool-level routing, and ECF) one at a time on the same pools. RQ-2.2 diagnoses the candidate-reachable bugs that the routed pre-ECF representative still misses.
RQ-3: What does the post-generation decision cost, and how does it compare with other selectors? We place every baseline on a cost-versus-repairs plane, comparing the deterministic selectors’ post-generation wall-clock per bug against the latency and dollar cost of the model-based rows.
RQ-4: How robust is PatchFusion to pool composition? We subsample each pool and track the fraction of candidate-reachable bugs solved at each pool size, separating system diversity from sampling randomness.
5 Experiments & Results↩︎
1.5pt
lcccccccccccccc & & & & &
(lr)4-11(lr)13-14 & & & & & & & & & & & & W/L & \(p\)
Random Expectation & – & 388.0 & 212.3 & 34.0 & 33.3 & 30.3 & 30.5 & 25.1 & 28.6 & 30.6 & 47.3 & – & –
Best single source & – & & & & & & & & & & & – & –
Minimal-change [35] & 0.02 & & & & & & & & & & & 120/24 & \(<0.05\)
Token medoid [11] & 0.02 & & & & & & & & & & & 60/6 & \(<0.05\)
Hunk consensus & 0.03 & & & & & & & & & & & 86/16 & \(<0.05\)
Patch Borda [19] & 0.22 & & & & & & & & & & & 63/6 & \(<0.05\)
Patch Copeland [19] & 0.25 & & & & & & & & & & & 65/8 & \(<0.05\)
Patch MC4 [19] & 0.53 & & & & & & & & & & & 69/7 & \(<0.05\)
LM naturalness ranker [36] & 77.1 & & & & & & & & & & & 141/23 & \(<0.05\)
DeepSeek-V4-Pro listwise & 1260 & & & & & & & & & & & 90/25 & \(<0.05\)
DeepSeek-V4-Pro fusion & 6024 & & & & & & & & & & & 221/16 & \(<0.05\)
Agentless & 386108 & & & & & & & & & & & 80/33 & \(<0.05\)
Agentless w/o test [17] & 0.07 & & & & & & & & & & & 96/22 & \(<0.05\)
& 3.28 & & & & & & & & &
& & – & –
5.1 RQ-1: Overall Fixed-Pool Results↩︎
[Experimental Design]: We run the full PatchFusion and the matched candidate-pool selectors on the three complete PatchFuseBench pools under the decision-time boundary of Section 4, reporting each whole-benchmark solved count with its gain \(\Delta_R\) over uniform-random selection (Table ¿tbl:tab:main-fixed-pool?). We compare PatchFusion against every baseline with W/L counts and exact paired sign tests, noting that the DeepSeek-V4-Pro fusion row generates a final patch rather than selecting one from the pool.
[Experimental Results]: Three patterns are visible in Table ¿tbl:tab:main-fixed-pool?. First, PatchFusion solves the most bugs among matched candidate-pool selectors across all three benchmark settings, adding 38.0, 23.7, and 39.7 bugs over uniform random selection on SWE-bench Verified, SWE-bench Multilingual, and Defects4J. Its strongest competitor is token medoid, which PatchFusion beats by 23, 17, and 14 bugs, with a combined 60/6 discordant-pair record across the three pools. The margins over the remaining selectors (rank aggregation, hunk consensus, Agentless w/o test, the LM naturalness ranker, and DeepSeek-V4-Pro listwise) are read directly from Table ¿tbl:tab:main-fixed-pool?. Exact two-sided paired sign tests over the outcome-discordant instances pooled across all three benchmarks (the W/L and \(p\) columns of Table ¿tbl:tab:main-fixed-pool?) show statistically significant gaps: PatchFusion beats all 9 matched test-free selectors at \(p<0.05\) on the pooled sign test, and each per-pool gap also holds under Holm-Bonferroni correction (released with the artifact). The per-pool W/L counts and confidence intervals are released with the artifact.
The best single-source row is a post-hoc reference, not a deployable selector. PatchFusion is also above this reference on all three benchmark settings, but the main deployable comparison is the gap over random selection and matched candidate-pool selectors. Per instance, PatchFusion solves 41 Verified and 27 Multilingual bugs that the best single source leaves unsolved while losing only 11 and 9 (net \(+30\) and \(+18\), \(p<0.05\) paired sign test), recovering repairs no single system supplies. For reference, a post-hoc oracle that keeps, for each bug, a candidate carrying the official solved label reaches the candidate-reachable ceiling (\(443\) and \(263\) on the two SWE-bench pools); PatchFusion approaches this ceiling (\(426\) and \(236\)) with no label or test consulted at decision time.
We further probe whether test access alone would let a strong baseline catch PatchFusion. The Agentless row in Table ¿tbl:tab:main-fixed-pool? keeps only candidates that pass the regression tests before the exact-identity vote, lifting the test-free Agentless w/o test from \(384/217/74\) to \(392/222/84\) on the three pools. Even with this test signal it trails PatchFusion by \(34\), \(14\), and \(3\) bugs and loses the pooled paired test (\(80/33\), \(p<0.05\)); the lift is largest on Defects4J, where roughly half of the candidates fail to compile and regression filtering removes the most failing candidates, yet test-free deterministic fusion still leads. Regression access thus narrows but never closes the gap, while forfeiting the decision-time, test-free property that keeps PatchFusion deployable: the row must run one regression suite per candidate, an estimated \(386{,}108\) ms per bug.
Second, DeepSeek-V4-Pro rows provide model-based post-generation baselines under the same decision-time boundary. The listwise judge remains below PatchFusion on all three benchmark settings while requiring model inference rather than deterministic candidate-pool evidence fusion. The free-form fusion row asks the model to generate a final patch rather than select one from the pool; even so, PatchFusion beats it \(221/16\) over the pooled discordant instances (\(p<0.05\)). Here, for SWE-bench we use official-runner outcomes for new diffs; for Defects4J, we keep the row candidate-aligned and only reuse cached labels for generated methods that match existing candidates. This is a different operating point from PatchFusion: it spends model inference time generating patches, whereas PatchFusion fuses static candidate evidence into an auditable first patch. Their decision-stage cost, where PatchFusion holds a further advantage, is quantified in RQ-3.
Third, the Multilingual language slices serve as a robustness check rather than as a basis for per-language claims. Each slice contains only 42-44 bugs, so we do not consider individual one- or two-bug differences significant. Across the slices, though, one pattern is consistent: PatchFusion is the only method whose per-language \(\Delta_R\) stays positive on every language, whereas every baseline regresses below uniform random on at least one, including the strongest baseline, token medoid, on JS/TS, Go, and C/C++. This uniform sign indicates that PatchFusion’s gain is broad across languages rather than concentrated in a few.
5.1.1 Selection versus generation: why free-form fusion loses↩︎
| DeepSeek-V4-Pro operating mode | Verified | Multilingual |
|---|---|---|
| Listwise (selects one candidate) | 396/500 | 214/300 |
| Free-form fusion (generates a patch) | 317/500 | 183/300 |
| Where fusion loses | ||
| Invalid, non-applying generated diffs | 96 | 38 |
| Just reproduces an existing candidate | 87 | 144 |
| Reachable bugs left unsolved | 126/443 | 80/263 |
| invented a failing novel patch | 92 | 49 |
4pt
The DeepSeek-V4-Pro rows let us compare selection and generation with one model held fixed: the listwise judge selects a submitted candidate, while the fusion baseline asks the same model to emit a final patch. Selection wins by 79 and 31 bugs (Table 2): the same model solves 396 and 214 by choosing versus 317 and 183 by generating. Fusion loses because generation re-opens failure modes selection eliminates by construction. First, 96 of 500 Verified diffs (and 38 of
300 Multilingual) do not even apply: the model emits malformed or mis-anchored hunks, often wrapped in a markdown or JSON envelope, that a selector can never produce. Second, on bugs a candidate already solves, the model still leaves 126/443 (Verified) and
80/263 (Multilingual) unsolved, and the main cause is self-inflicted: in 92 and 49 of these it generates a new patch that fails rather than choosing the correct candidate already in the pool. apache__druid-14136 is typical: the model wraps its
diff in a JSON envelope and proposes a plausible empty-interval guard that the tests reject, while a solving candidate was available. Half the time on Multilingual (\(144/300\)) it simply reproduces an existing candidate,
so even many of its successes are mere selection. Once correct patches already populate the pool, handing the decision to a strong generator is therefore worse than a deterministic selector: generation adds format errors, hallucinated edits, and the risk
of overwriting an available fix.
[RQ-1] Findings. (1) PatchFusion comes within 17 of the candidate-reachable ceiling on Verified (426/500) and beats every matched selector at \(p<0.05\). (2) Per instance it recovers repairs no single source solves (net \(+30\) and \(+18\) bugs). (3) Given the same decision, the evaluated DeepSeek-V4-Pro baseline does worse, not better: its free-form fusion loses 79 and 31 bugs, mostly by overwriting a correct candidate already in the pool. Insight. When a fixed pool already holds correct patches, the bottleneck moves from generation to selection; in this setting, a stronger generator does not help and can hurt.
5.2 RQ-2: Component Contributions and Residual Misses↩︎
[Experimental Design]: We ablate PatchFusion one internal design choice at a time on the same candidate pools, keeping candidate canonicalization and exact-support counting fixed. The ‘w/o ECF’ row disables the whole content-fusion module, so it measures ECF’s marginal contribution inside the same pipeline; the other rows each alter one pre-ECF decision that supplies ECF with a representative.
| Variant | Verified | Multi. | Defects4J |
|---|---|---|---|
| 426 | 236 | 87 | |
| Step 2: w/o repair-neighborhood | 421 | 214 | 62 |
| Step 3: w/o local edit evidence | 405 | 230 | 78 |
| Step 3: w/o same-surface guard | 411 | 214 | 65 |
| Step 3: w/o pool-level route | 421 | 230 | 78 |
| Step 4: w/o ECF | 421 | 230 | 78 |
3pt
| Setting | w/o ECF | with ECF | Net wins | Losses |
|---|---|---|---|---|
| SWE-bench Verified | 421/500 | 426/500 | +5 | 0 |
| SWE-bench Multilingual | 230/300 | 236/300 | +6 | 0 |
| Defects4J | 78/371 | 87/371 | +9 | 0 |
3pt
5.2.1 RQ-2.1: Which components account for the gains?↩︎
Table 3 shows a clear division of labor. Repair-neighborhood fusion is the backbone on Multilingual and Defects4J, the largest single drop there when removed (Table 3). On Verified, by contrast, the local edit path and its guards matter most, and representative selection with pool-level routing adapts the backbone to this per-pool structure. ECF sits on top as a sparse content-fusion layer that lifts the final counts by \(+5/+6/+9\), with no observed regression (Table 4).
Across the three benchmark settings, ECF makes 20 label-changing corrections. By construction, where the emitted diff is inspectable on the two SWE-bench pools, ECF’s correct outputs are patches it constructs rather than copies: the submitted
diff is a supported scope-union or contraction absent from the candidate pool in 8 cases (including django__django-14315), while 4 Multilingual outputs re-derive an already-solving candidate’s edit. Of these 12 inspectable correct outputs, 11
flip a previously unresolved instance and form the \(+5\) and \(+6\) SWE-bench net wins of Table 4, while the 12th re-applies a correct
construction on an instance the pre-ECF representative already solved and so leaves the count unchanged rather than adding a win.
ECF’s scope localization is not Python-specific: alongside the Python AST locator, which covers \(98.0\%\) of Verified patches, tree-sitter grammars resolve a real AST method or class scope for \(94.1\%\) of the non-Python Multilingual patches (Java, PHP, and Ruby at \(100\%\); Rust \(95.0\%\); Go \(92.5\%\); JS/TS \(82.8\%\); C/C++ \(82.3\%\)), leaving a brace-balanced block only as a residual fallback. The small Multilingual takeover count (\(9\), all resolved) is therefore bounded by ECF’s conservative support and compactness gates, not by coarse scoping.
5.2.2 RQ-2.2: What does the pipeline still miss?↩︎
We inspect pre-ECF candidate-reachable misses, bugs whose pool contains a solved patch while the routed pre-ECF representative is unsolved. Same-neighborhood representative choice dominates: it covers 42/55 of these misses (16/22 Verified, 26/33 Multilingual); the remaining 13 are isolated singletons, with none in a different non-singleton neighborhood, so the residual is not a missing repair surface but the wrong close variant chosen within it.
| Static relation to solved patch | Multi. | Verified |
|---|---|---|
| Same files | 23 | 12 |
| Higher exact support | 2 | 1 |
| Higher signature support | 2 | 1 |
| Solved shorter | 15 | 9 |
| Solved longer | 19 | 9 |
| More supported atoms | 11 | 8 |
| Fewer unsupported atoms | 7 | 10 |
| Lower token centrality | 26 | 12 |
| Selected dominates | 11 | 5 |
Table 5 breaks these by pre-ECF static relations: a solved alternative usually shares the file surface and is less token-central than the chosen representative, yet in a large share every static criterion still ranks the representative ahead of it. The next distinguishing signal is therefore edit necessity rather than another whole-diff score.
[RQ-2] Findings. (1) ECF makes 20 label-changing corrections with no regression, 8 by constructing a patch that appears in no candidate. (2) The remaining gap is not finding the repair but the choice within it: 42 of 55 residual misses pick the wrong close variant in the right neighborhood. Insight. The last gap is not coverage but a within-neighborhood choice, a single signal (edit necessity) that no whole-diff score can express.
5.3 RQ-3: Post-Generation Cost↩︎
[Experimental Design]: We place every method from Table ¿tbl:tab:main-fixed-pool? on a cost-versus-repairs plane: the \(x\)-axis is post-generation wall-clock per bug from Section 4, and the \(y\)-axis is the SWE-bench Verified solved count. We also read the dollar cost of the model-based rows from cached prompt sizes and note whether each method requires an online model and whether it is deterministic.
[Experimental Results]: Figure 3 puts PatchFusion in the top-left corner: it solves the most bugs (426/500) at 3.28 ms per bug with no model call, within 17 of the candidate-reachable ceiling. This 3.28 ms is the decision step in isolation: a median over 7 runs, measured after the candidate pool is loaded and its views are built, and it excludes candidate generation, any model or API call, official-runner execution, and the one-time preprocessing (pool loading, diff normalization, scope building) that precedes the decision; the comparison below is therefore of decision-stage latency, not end-to-end pipeline time, and every method on the plane is timed under the same post-preprocessing convention. The deterministic consensus and rank-aggregation selectors are equally cheap but capped below it (token medoid strongest at 403), while the model-based methods sit two to three orders of magnitude to the right without overtaking PatchFusion, free-form fusion being both the most expensive (6024 ms) and the lowest-scoring (317/500). The dollar gap is wider still: PatchFusion spends no model tokens, whereas each DeepSeek call consumes 4.0k input tokens (and a generated patch for fusion), adding a per-bug API charge and an online-model dependency at a step that should add milliseconds. PatchFusion is also deterministic, returning the same patch from the same pool on every run, while the model-based rows depend on sampling and an external endpoint.
With its decision-time constraints relaxed, a frontier model can be pushed toward a higher plausible-patch yield, but that is a different operating point: it is expensive, nondeterministic, and emits an unauditable program rather than a contraction of a submitted candidate. Under the fixed-pool decision-time budget studied here, that option is unavailable.
[RQ-3] Findings. (1) Accuracy does not cost more: PatchFusion is the most accurate selector yet decides in 3.28 ms with no model call. (2) The evaluated model-based rows do not improve accuracy: they cost two to three orders of magnitude more (1260 to 6024 ms vs 3.28 ms) without doing better, and the model-based fusion row is the most expensive (6024 ms) and least accurate (317/500). Insight. Under this fixed-pool setting there is no speed-accuracy tradeoff: the evaluated model-based selectors do not choose better, so the decision should stay cheap and deterministic.
5.4 RQ-4: Robustness to Pool Composition↩︎
[Experimental Design]: At every subset size \(k\) we evaluate all \(\binom{n}{k}\) subsets of each pool and record PatchFusion’s diff-level solved count as a fraction of that subset’s candidate-reachable ceiling, which rescales the three pools onto one axis. The SWE-bench pools are subsampled by source (Verified \(n=6\), Multilingual \(n=7\), each source a different system); the Defects4J pool is subsampled by pass@\(k\) sample (\(n=10\) stochastic samples of one fine-tuned model), a single-model control where any complementarity comes from sampling alone.
| Constant | Default | Swept | Effect |
|---|---|---|---|
| Base-overlap boundary | \(0.8\) | \([0.60,0.95]\) | D4J solved \(87\) (\(85\) at \(0.60\)) |
| Atom support | \(2\) | \(3\) | emitted patches \(-1\) |
| Scope-union cap \(K\) | \(3\) | \(2,\,4\) | emitted patches \(+1,\;0\) |
| Fused-token budget | \(160/180\) | \(\pm50\%\) | emitted patches \(0\) |
4pt
[Experimental Results]: On the diverse SWE-bench pools PatchFusion captures a near-constant high fraction of the reachable bugs at every pool size (91.9 to 95.0% on Verified and 86.5 to 91.0% on Multilingual), so its effectiveness is set by the complementarity the pool contains, not by a particular source count. On the single-model Defects4J pool the captured fraction is much lower and declines as samples accumulate (67.7% at 2 samples down to 57.8% at 10), because added samples of one model grow the reachable set faster than the selector keeps pace.
The single-model control isolates the source of that complementarity. Defects4J is a single-model pass@10 pool, yet PatchFusion still gains there: it reaches 87/371 plausible patches, well above the best single sample at 62 and uniform random at 47.3, and ECF lifts the pool from 78 to 87.
[RQ-4] Findings. (1) Complementarity does not require diverse systems: one model’s pass@10 sampling already fuses, lifting the single-model pool from 62 to 87. (2) The single-model pool’s declining captured share (67.7% to 57.8%) is a faster-rising reachable ceiling, not fusion degrading; diverse pools stay at a near-constant high share. Insight. Fusion depends on complementarity, not source count: even one model’s repeated sampling supplies it, while diverse systems make far more of it reachable.
6 Threats to Validity↩︎
Internal validity. The main threat is decision-time leakage: a selector could exploit test outcomes, labels, or run metadata rather than the patches themselves. We bound it with the candidate view of Section 3.1, which exposes only diff-derived fields, duplicate counts, and unlabeled pool structure, with labels attached only after the final patch is fixed. To limit benchmark overfitting, PatchFusion’s few numeric constants were frozen before evaluation with no development set, and the sensitivity sweep (Table 6) shows that no setting regresses.
External validity. The candidate pool is a public-leaderboard snapshot, so the results could be specific to it. We mitigate this by evaluating complete pools, by exceeding the best single source on all three pools (Table ¿tbl:tab:main-fixed-pool?), and by the RQ-4 complementarity control (Figure 4), which shows that the gain tracks pool complementarity rather than source count; we therefore scope our strongest captured-fraction results to multi-source pools, while the single-model Defects4J control indicates the gain does not require diverse systems.
Construct validity. On Defects4J, plausible does not imply correct, so we make the SWE-bench official-runner solved counts the primary result and treat Defects4J as a single-model control reported as a plausible count from MORepair’s stored validation. Every final patch, including the new diffs ECF emits, is scored by each benchmark’s official oracle, never a self-reported one.
7 Related Work↩︎
7.1 Program Repair, Coding Agents, and Candidate Pools↩︎
Automated program repair (APR) has progressed from search- and heuristic-based generation [35], [39], [40], through template- and pattern-based fixing [41], [42] and semantic or constraint-based synthesis [43], [44], to learning-based transformations [45]–[47]. LLM coding agents have since expanded the scale and diversity of candidate patches. Zero-shot repair [48], pretrained repair models [1], [2], code-completion repair [49], conversational repair [4], [50], retrieval-augmented generation [51], repository-aware repair [52], agentless pipelines [17], and software agents [3], [53], [54] all improve how candidate patches are produced. These systems define the upstream generators and trajectories from which a candidate pool is obtained. As generators improve, pass@\(k\) increasingly exposes reachable repairs, but deployment still needs one auditable patch before validation or review.
7.2 Patch Selection, Ranking, and Fusion↩︎
Patch correctness assessment and ranking use behavioral or plausibility signals [14], [22], dynamic impact [20], failing-test similarity [21], and naturalness [36]. They also use LLM judging [24], similarity- or history-based reranking [18], learned patch representations [23], [38], and rank aggregation [19]. PatchFusion differs by fusing evidence from exact and near-duplicate variants within a repair neighborhood before selecting an auditable representative.
Multi-sample code generation also uses consistency and clustering: AlphaCode clusters generated programs [11], self-consistency marginalizes sampled reasoning paths [25], CodeT selects code with generated tests [26], and Universal Self-Consistency uses an LLM to choose among free-form candidates [27]. Validation-aware agents such as CodeMonkeys and SWE-Search add generated tests, validation-aware selection, or search [12], [13]. In contrast, PatchFusion uses repeated edit atoms for evidence-constrained fusion while keeping the final patch auditable against submitted candidates.
Patch construction and multi-hunk repair systems synthesize or refine patches during generation: multi-edit synthesis [55], [56], iterative refinement [57], and large-change construction [58], [59]. Repository-scale APR and agent benchmarks then expose fixed multi-run candidate pools [10], [60]. PatchFusion starts after generation and turns that pool into one auditable patch.
8 Conclusion↩︎
We propose PatchFusion, a deterministic approach that fuses a fixed pool of candidate patches into a single auditable final patch via repair-neighborhood fusion, representative selection, and evidence-constrained fusion (ECF). We evaluate PatchFusion on PatchFuseBench, covering SWE-bench Verified, SWE-bench Multilingual, and Defects4J, where it solves 426/500 and 236/300 SWE-bench bugs and reaches 87/371 plausible Defects4J patches, outperforming consensus and LLM-based selectors at a 3.28 ms per-bug decision with no model cost. Ablations show that ECF is a content-fusion layer that recovers mis-selected repairs by constructing patches absent from the pool, with no observed regression. Future work can investigate combining our deterministic, test-free patch fusion with an LLM-based agentic workflow to recover more diverse and accurate repairs.