SWE-Debate: Competitive Multi-Agent Issue Resolution

• SWE-Debate is a debate-based paradigm in software engineering where multiple agents use structured, evidence-based arguments to localize issues and select fix plans.
• It leverages graph-guided code dependency analysis to generate fault propagation chains and compare candidate solutions through competitive multi-round debates.
• Empirical findings demonstrate that integrating debate with MCTS-guided patch generation and multi-trace exploration improves issue resolution accuracy on software benchmarks.

SWE-Debate is a debate-based paradigm for software engineering in which multiple agents argue over issue localization, fix plans, or candidate solutions under constrained evidence and a downstream selection mechanism. In the most explicit repository-level formulation, “SWE-Debate: Competitive Multi-Agent Debate for Software Issue Resolution” introduces a graph-guided, competitive multi-agent debate framework for repository-level issue resolution; adjacent work uses debate to supervise unreliable experts with certified evidence, to select among candidate patches inside MCTS-based search, and to provide proposer-critic oversight in programmatically verifiable code settings (Li et al., 31 Jul 2025).

1. Terminological scope and intellectual lineage

The software-engineering use of debate descends from the broader proposal of zero-sum AI debate, in which two agents alternate short statements, a judge selects the winner, and precommitment plus adversarial scrutiny are intended to make “it harder to lie than to refute a lie.” In that formulation, debate is defined over questions $Q$, answers $A$, and statements $S$, with a judge function $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$ and training directed toward an approximate Nash equilibrium in the induced zero-sum game. The same literature emphasizes short, verifiable evidence reveals, precommitment to claims, and judge-side constraints as the mechanisms that make shallow debates informative on hard tasks (Irving et al., 2018).

A later empirical line instantiated this logic with unreliable experts and a weak judge. “Debate Helps Supervise Unreliable Experts” studies a setting with two equally informed experts, one assigned to defend the correct answer and the other the best distractor, while a non-expert judge cannot access the full source material and relies on arguments plus selectively revealed certified quotes. Against a consultancy baseline in which a single consultant argues for one answer chosen at random—correct $50\%$ of the time—debate achieved $84\%$ judge accuracy versus consultancy’s $74\%$, and human debate averaged $2.7$ rounds versus $4.0$ for human consultancy (Michael et al., 2023).

Within software engineering, these ideas bifurcate into at least three technically distinct uses. One use treats debate as scalable oversight over tool-using expert agents and recommends replacing textual quotes with certified artifacts such as code diffs, specific lines, test outputs, logs, traces, deterministic command invocations, and witness counterexamples. A second use, exemplified by DebateLoc, makes debate a core repository-level reasoning module for selecting fault-propagation traces and consolidating fix plans. A third use makes debate a terminal or near-terminal selector over candidate solutions, as in proposer-critic oversight or MCTS-based discrimination. This suggests that “SWE-Debate” is best understood not as a single protocol, but as a family of adversarial coordination schemes whose common invariant is that disagreement is structured around verifiable software artifacts rather than free-form persuasion.

2. Graph-guided repository-level architecture

In the repository-level issue-resolution literature, SWE-Debate is formalized as a three-stage pipeline: code dependency graph construction with multi-trace localization proposals, a competitive multi-round debate that selects and refines a fix plan, and integration with an MCTS-based code modification agent. The task setting is defined as follows: given an issue description $p$ and a codebase composed of code entities $A$0, an agent must identify a subset of entities to modify $A$1 through an exploration chain $A$2, where at time step $A$3, action $A$4 leads to observation $A$5. The repository is formalized as $A$6, optionally with test suite $A$7 (Li et al., 31 Jul 2025).

The framework builds a static code dependency graph $A$8. Nodes represent files, classes, functions, and variables; edges encode function calls, class inheritance, module imports, and variable references. Construction uses static analysis with Python’s ast library, specifically CPython 3.13 Lib/ast.py, plus metadata to produce an adjacency representation. From the issue description, the system extracts structural identifiers explicitly referenced in text and selects the top-$A$9 high-confidence entities $S$0 that have direct textual correspondence to $S$1.

Fault propagation traces are then generated in two phases. For each seed entity $S$2, the method performs breadth-first expansion to choose the top-$S$3 neighbors balancing semantic relevance and structural variety, then depth-first search to depth $S$4, selecting the most promising next entity at each step. Node selection is guided by a composite score

$S$5

where $S$6 is LM-based semantic similarity and $S$7 reflects structural importance. Chain ranking is described by

$S$8

followed by diversity filtering with semantic embeddings.

The resulting debate structure is specialized rather than homogeneous. In experiments, $S$9 specialized agents are instantiated via different system prompts to embody distinct reasoning perspectives. From the $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$0 pool, the system chooses $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$1 diverse chains, defined in experiments as the longest chain plus the $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$2 most distinct by semantic embeddings, with $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$3.

Component	Mechanism	Experimental setting
Graph construction	Static code dependency graph $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$4	ast, CPython 3.13 Lib/ast.py
Trace generation	Top-$J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$5 entry points, breadth width $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$6, depth limit $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$7	$J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$8, $J(q,a_1,a_2,s_0,\dots,s_{T-1}) \to \{1,2\}$9, $50\%$0
Debate agents	Specialized reasoning perspectives	$50\%$1, $50\%$2 chains

This architecture is explicitly motivated as a remedy for the failure mode of independent exploration. A single agent can prematurely converge to superficially relevant sites, while defects may propagate across call chains, inheritance, and data flow. The graph-guided trace pool therefore acts as a structural prior over cross-module reasoning, and the debate stage is designed to keep multiple plausible propagation hypotheses alive long enough to compare them.

3. Debate rounds and MCTS-guided patch generation

The debate protocol itself has three rounds. In Round A, agents rank the candidate localization chains and vote for one chain. If agent $50\%$3 casts vote $50\%$4 with confidence $50\%$5, chain scores are defined as

$50\%$6

The selected chain is $50\%$7, with ties broken by $50\%$8.

In Round B, each agent independently produces a structured JSON plan conditioned on the selected chain. These plans specify exact code entities and locations to modify, modification types (fix_bug, add_feature, refactor, optimize), priorities, and implementation reasoning with detailed steps. In Round C, agents critique all proposals, defend their own plans, and integrate cross-agent insights into refined plans. A discriminator agent then synthesizes a final consolidated plan, resolving conflicts and emitting ordered, concrete modification steps using only action verbs such as Add, Modify, Replace, and Insert (Li et al., 31 Jul 2025).

The consolidated plan is then passed to an MCTS-based modification agent. States represent codebase states together with patch state; actions are $50\%$9. Search retrieves context, Plan reasons and schedules edits, and Edit applies concrete code changes at specified locations from the final plan. Rollouts are guided by the consolidated fix plan priors, and evaluation includes running existing tests and optionally creating new tests. The selection rule is described as a modified Upper Confidence Bound for Trees; the paper presents a derived UCT form and uses Appendix hyperparameters including $84\%$0, max_expansions = 2, max_iterations = 20, best_first = True, and max_depth = 20 (Li et al., 31 Jul 2025).

The interaction between debate and search is therefore asymmetric. Debate is not merely a post hoc vote over complete patches; it is an upstream planner that constrains MCTS branching by injecting action priors, edit-order preferences, and location biases. This suggests that the principal computational role of debate in DebateLoc is search shaping rather than pure consensus formation.

4. Empirical performance and ablation structure

On SWE-Bench-Verified, DebateLoc with DeepSeek-V3-0324 achieved $84\%$1 Pass@1, corresponding to $84\%$2 issues. Under the same model, SWE-Agent scored $84\%$3, SWE-Search $84\%$4, and OpenHands $84\%$5. The paper reports this as state-of-the-art among open-source agent frameworks with the same model and as a $84\%$6 percentage-point improvement over the strongest baseline, from $84\%$7 to $84\%$8 (Li et al., 31 Jul 2025).

On SWE-Bench-Lite, the framework reported $84\%$9 Acc@1 at file-level localization. The strongest baseline in the table, LocAgent with Claude-3.5 Sonnet, reported $74\%$0, so the reported gain is $74\%$1. These gains are complemented by ablations that isolate the architecture’s contributions. Removing multiple chain generation drops Pass@1 from $74\%$2 to $74\%$3; removing multi-agent debate drops it to $74\%$4; removing the edit plan drops it to $74\%$5. The largest absolute degradation is therefore the removal of multi-trace generation, at $74\%$6.

Sensitivity analysis on SWE-Bench-Verified-S shows that increasing chain depth from $74\%$7 to $74\%$8 boosts Acc@1(File), peaking at $74\%$9 at $2.7$0, while depths greater than $2.7$1 yield diminishing returns and slight degradation due to added distractors. The default configuration used in experiments is $2.7$2, $2.7$3, $2.7$4, $2.7$5, $2.7$6, with DeepSeek-V3-0324 across experiments.

The qualitative case studies illuminate what the numerical ablations mean operationally. In SymPy-13974, the selected chain captured tensor_product_simp_Mul, tensor_product_simp, and TensorProduct.eval_expand_tensorproduct, thereby mapping the symbolic rewriting pipeline. The debate plan contained four steps: modify simplification logic, add power support, extend expand behavior, and implement _eval_power in TensorProduct. In the Django-11999 motivation example, a single-agent baseline mislocalized the issue to _get_FIELD_display in django/db/models/base.py, whereas competitive debate identified Field.contribute_to_class in django/db/models/fields/__init__.py as the root cause and proposed adding existence checks around lines 765–767 to prevent overwriting user-defined methods during class construction (Li et al., 31 Jul 2025).

These findings support a narrow but important claim: in this framework, debate contributes materially, but it is not the dominant source of improvement in isolation. The empirical record assigns larger effect size to multi-trace generation than to the debate module alone, while still showing that the debate stage reduces ambiguity and premature convergence.

5. Verification-oriented variants and judge behavior

Other software-engineering debate systems use materially different protocols. In SWE-Search, the Discriminator Agent is a final-stage decision module rather than a planner. It evaluates up to five candidate solutions produced by the search process via a structured multi-agent debate. Hyperparameters specify number_of_agents = 5, number_of_round = 3, and discriminator_temperature = 1.0. On instances where the correct solution existed among candidates, the value function selected the correct solution $2.7$7 of the time, while the Discriminator improved selection to $2.7$8 (Antoniades et al., 2024).

A more judge-centric variant appears in proposer-critic oversight for verifiable domains. There, the proposer generates a candidate solution, the critic outputs AGREE or DISAGREE plus a verification-oriented argument, and the judge decides whether the proposer’s solution is correct. On the three of five pairings where the critic’s classifier macro-F1 exceeded the judge’s opening-only macro-F1 and judges continued to verify claims, full debate improved macro-F1 over consultancy by $2.7$9 percentage points for Qwen3.5-122B/35B on code, $4.0$0 for Gemini 3.1 Pro/Flash on logic, and $4.0$1 for Opus 4.6/4.5 on logic. On the two pairings where critic and judge classification ability were within noise, debate produced null effects, and judge verification rates dropped sharply when a critic entered the transcript (Elasky et al., 26 May 2026).

This literature also reports that rebuttal rounds can be dispensable. In the responder pairings, openings-only debate and full debate were statistically indistinguishable and agreed on approximately $4.0$2–$4.0$3 of verdicts. The practical implication is the “answer, critique, judge” primitive: one solution, one independent critique, and a judge that treats the critique as a claim to verify rather than testimony to summarize (Elasky et al., 26 May 2026).

The software-engineering oversight adaptation of “Debate Helps Supervise Unreliable Experts” reinforces the same principle at the evidence level. It recommends replacing textual quotes with certified artifacts such as code diffs, specific lines, test outputs, logs, traces, deterministic command invocations, runtime checks, property tests, and witness counterexamples; deduplicating artifacts across turns; and presenting them in a side panel ordered by file, line number, and time. The judge is instructed to demand executable proof: “Show me the failure by test; show me the exact code path; quote the surrounding lines; run the minimal reproduction” (Michael et al., 2023).

Taken together, these variants distinguish two regimes. One regime uses debate as a planning-and-consolidation mechanism before code editing, as in DebateLoc. The other uses debate as a verification-and-selection layer, in which gains depend less on rhetorical diversity than on whether critics can produce executable, judge-checkable falsification signals.

6. Failure modes, negative results, and open research directions

The most important criticism of SWE-Debate comes from studies of unguided homogeneous multi-agent debate. In a controlled study with homogeneous teams of $4.0$4 identical agents, $4.0$5 rounds, communication density $4.0$6, and plurality voting, debate consumed $4.0$7–$4.0$8 more tokens than isolated self-correction for equal or lower accuracy. The study decomposed failure into sycophantic conformity, contextual fragility, and consensus collapse. Reported maxima include modal adoption up to $4.0$9, vulnerability rate up to $p$0, and oracle gap up to $p$1 percentage points. Across all configurations, unguided homogeneous debate did not exceed self-correction accuracy, and the authors recommend isolated self-correction or self-consistency plus test-based oracle selection unless role structure, filtering, and external validators are added (Bertalanič et al., 29 Apr 2026).

This negative result is not directly inconsistent with DebateLoc, because the protocols differ on nearly every consequential variable. DebateLoc is heterogeneous, role-conditioned, graph-guided, and embedded in a repository toolchain; the failure paper studies homogeneous teams with no personas, no role structure, and no external orchestration. A plausible implication is that many positive SWE-Debate results should be attributed not to “more agents” in the abstract, but to specialized roles, constrained evidence channels, structured aggregation, and programmatic validators.

Broader SWE evidence also points to the centrality of external signals. Oracle-SWE isolates five information signals—Reproduction Test, Regression Test, Edit Location, Execution Context, and API Usage—and reports a stable ranking in which Reproduction Test is most valuable across newer benchmarks, with all five oracle signals combined pushing success rates above $p$2 across model-benchmark pairs. This suggests that debate protocols in software engineering are likely to remain brittle unless they can surface or synthesize the same kinds of executable signals that dominate oracle-based agent performance (Li et al., 9 Apr 2026).

The benchmark picture is consistent with this diagnosis. APEX-SWE evaluates economically meaningful software engineering work on Integration and Observability tasks and reports that Gemini 3 Pro (Thinking = High) performs best with Pass@1 of $p$3. The accompanying qualitative analysis argues that strong performance is primarily driven by epistemic reasoning—the ability to distinguish between assumptions and verified facts—combined with agency to resolve uncertainty prior to acting. This suggests a natural convergence between debate-based oversight and benchmark-driven agent design: debate is most plausible when it forces closed-loop verification rather than open-loop argumentative fluency (Kottamasu et al., 13 Jan 2026).

Open problems therefore cluster around tractability, verification, and scaling. The software-engineering debate literature explicitly asks how to scale to very large codebases and complex system interactions while keeping debates tractable; how to train AI judges to rely on artifacts rather than priors; how to measure and mitigate obfuscated arguments; and how to preserve judge calibration under high-confidence pressure. The broader alignment literature adds further questions about exploration guarantees, online training to maintain honesty, and the conditions under which good debate performance implies mostly honest behavior during deployment (Buhl et al., 6 May 2025).

In current usage, SWE-Debate is thus neither a settled algorithm nor a single architecture. It is a design space defined by adversarial comparison, constrained evidence, and a downstream decision rule. Its strongest positive results arise when debate is embedded in graph-guided localization, structured role specialization, or executable judge verification; its strongest negative results arise when identical agents exchange unguided rationales and aggregate by majority. The central technical question is no longer whether debate helps in the abstract, but which debate protocol preserves minority-correct solutions, elicits decisive artifacts, and converts disagreement into verifiable software evidence rather than collective rhetorical drift.