Software Engineering Agents (SWE-Agents)
- SWE-agents are iterative LLM-based systems that autonomously solve software tasks by interacting with repositories, running tests, and refining code.
- They leverage a specialized agent-computer interface to execute commands, navigate files, and combine reasoning with tool use for robust debugging.
- SWE-agents integrate verifier scaling, multi-agent strategies, and human collaboration to progressively enhance patch quality and system reliability.
Software engineering agents (SWE-agents) are large-language-model-based systems that autonomously solve software tasks by combining reasoning with tool use such as repository navigation, code editing, search, and test execution. In the repository-level formulation that became standard in the literature, they do not merely generate code in one shot; they interact iteratively with a code environment, read files, run commands and tests, inspect outputs, revise code, and submit improved solutions. The field has consequently developed as a joint study of agent-computer interfaces, executable training environments, verifier-guided inference, human-agent collaboration, and increasingly broader forms of multi-agent organization (Yang et al., 2024, Liang et al., 21 Mar 2026).
1. Definition, scope, and task structure
The defining property of a SWE-agent is iterative interaction with a software environment. One line of work describes these systems as auto-regressive LLM-based software engineering agents that combine reasoning, tool calls or environment interaction, and self-reflection; another emphasizes that they read files, run commands/tests, inspect outputs, revise code, and submit improved solutions rather than emitting a single patch (Bula et al., 11 Apr 2025, Boulet et al., 24 Oct 2025). This places them between classical program synthesis and interactive debugging systems: the agent must act inside a repository, not merely predict text conditioned on a prompt.
The canonical task family is repository-level GitHub issue resolution. SWE-agent evaluates on the original SWE-bench, which contains 2,294 test instances from 12 repositories, and on SWE-bench Lite, a 300-instance subset focused on self-contained functional bug fixes; later work standardizes SWE-bench Verified as a curated 500-instance subset of real-world GitHub issues across 12 Python repositories. In this setting, resolve rate or pass@1 denotes the percentage of tasks whose final patch passes the benchmark evaluation (Yang et al., 2024, Song et al., 3 Feb 2026, Liang et al., 21 Mar 2026).
Trace-based analysis across AutoCodeRover, Agentless, MASAI, SWE-Agent, and OpenHands-CodeAct shows that apparently diverse systems still share a common backbone of localization, patch generation, and validation. The same study identifies two dominant decision styles: iterative refinement, in which a single candidate is progressively improved, and parallel sampling, in which many candidates are generated and one is selected (Ceka et al., 10 Jun 2025). This common structure explains why later work can intervene at several different layers—interface, data, search, verification, or collaboration—without changing the underlying task definition.
The scope of SWE-agents is also widening. Controller generation for embodied Minigrid tasks recasts the agent as a “code-agent” that writes a Python controller-agent for an MDP-like environment, making controller generation a benchmark for embodied reasoning under partial observability and sensorimotor constraints rather than only for conventional repository repair (Boulet et al., 24 Oct 2025). A broader architectural literature further extends SWE-agents to design, testing, deployment, and maintenance within Human-AI software teams (Dam et al., 2 Dec 2025).
2. Interfaces, tools, and workflow design
A foundational claim of the field is that agent performance depends strongly on interface design. SWE-agent formalizes this through the notion of an agent-computer interface (ACI), arguing that LMs should not be forced to use a raw shell designed for humans. Its ACI design principles state that actions should be simple and easy to understand, compact and efficient, environment feedback should be informative but concise, and guardrails should mitigate error propagation and hasten recovery. Concretely, the interface provides summarized search/navigation commands (find_file, search_file, search_dir), a stateful file viewer (open, goto, scroll_down, scroll_up), and an edit <n>:<m> operation that replaces a whole line range in one action. Each search returns at most 50 results, the viewer shows at most 100 lines at a time, and edits to Python files are lint-checked with selected flake8 error codes before they are applied (Yang et al., 2024).
Subsequent systems retain the same basic interaction loop while varying the scaffold. SWE-Gym trains agents under OpenHands CodeActAgent, a general-purpose, ReAct-style agent that can use a bash shell and file editor, and under MoatlessTools, a more specialized workflow scaffold with predefined stages (Pan et al., 2024). SWE-Master later extends the tool layer with language-server-based navigation—go-to-definition, references, call hierarchy, document symbols, and workspace symbol search—so that the agent acquires IDE-grade semantic understanding instead of relying only on grep/find text search (Song et al., 3 Feb 2026).
The interaction traces produced by these systems are not arbitrary. The early SWE-agent analysis shows that trajectories usually begin with reproduction or localization, middle turns often form an edit → python or pytest loop, and later turns either submit or continue cleanup. The traceability taxonomy generalizes this into three broad phases—project understanding, context understanding, and patching/testing—across multiple agent families (Yang et al., 2024, Ceka et al., 10 Jun 2025). In this sense, the interface is not only an execution substrate but also a shaping force for the observable decision process.
3. Executable environments, data construction, and post-training
A central bottleneck in SWE-agent research is the scarcity of large, executable, and verifiable training data. SWE-Gym addresses this by releasing 2,438 Python task instances drawn from 11 popular open-source repositories, each instance containing a codebase snapshot, a pre-configured executable environment with dependencies, unit tests, and a natural-language task specification. It also releases SWE-Gym Raw with 66,894 Python GitHub-issue-style instances from 358 repositories and SWE-Gym Lite with 230 instances, making executable feedback a training resource rather than only an evaluation protocol (Pan et al., 2024).
SWE-Next reframes data collection as an execution-grounded mining problem over real merged pull requests. For each candidate base/merged commit pair, it runs the repository test command on both commits, parses per-test outcomes, and retains only “self-verifying” instances whose merged commit strictly improves behavior without regressions. Formally, a candidate is labeled iff and . From 102,582 executed candidate commit pairs mined from 3,971 seed repositories, only 2,308 instances survive, a 2.2% yield; 74.5% show unchanged test behavior, 2.5% fail during setup, and 20.8% fail during test execution. The same paper introduces repo-quarter profiles, , so that nearby commits can reuse the same environment; with this mechanism the full run used 30 hours and 639 GB of environment storage, whereas disabling reuse is estimated at about 30.8 TB under a 300 MB-per-image assumption (Liang et al., 21 Mar 2026).
OpenSWE, framed as daVinci-Env, scales environment synthesis further. It reports 45,320 executable Docker environments spanning 12.8k repositories, with all Dockerfiles, evaluation scripts, and infrastructure open-sourced. The synthesis pipeline is multi-agent and distributed across a 64-node cluster, and the paper states that environment construction cost about $891K, trajectory sampling and difficulty-aware curation another$576K, and the full project about $1.47M, yielding about 13,000 curated trajectories from roughly 9,000 quality-guaranteed environments (Fu et al., 13 Mar 2026). MEnvAgent pushes the same problem into the polyglot setting with a Planning-Execution-Verification architecture and an Environment Reuse Mechanism that incrementally patches historical environments; on MEnvBench, a 1,000-task benchmark across 10 languages, it improves Fail-to-Pass rates by 8.6% while reducing time costs by 43%, and it constructs MEnvData-SWE with 3,005 task instances, 942 repositories, 10 languages, and 3,872 verified solution trajectories (Guo et al., 30 Jan 2026).
The systems problem has also been attacked directly. SWE-MiniSandbox removes the dependency on per-task containers by using isolated workspaces backed by mount namespaces and chroot, reporting disk usage of about 5% of container-based pipelines and environment preparation time of about 25% of the container baseline while maintaining comparable evaluation performance (Yuan et al., 11 Feb 2026). SWE-Dev addresses the reward-signal bottleneck by synthesizing test cases in stages—repository information extraction, Gherkin-style scenario generation, executable test synthesis, and optional traceback-guided revision—and reports 2,097 fail-to-pass test functions from a 26k-instance subset, 4,630 total tests when combined with existing tests, and resolve rates of 23.4% and 36.6% for its 7B and 32B models on SWE-bench-Verified (Wang et al., 9 Jun 2025).
A complementary direction separates semantic learning from execution. SWE-ZERO to SWE-HERO first distills 300k execution-free trajectories to learn repository-level reasoning without runnable task-specific environments, then refines on 13k execution-backed trajectories to ground those behaviors in verification. The resulting SWE-HERO-32B reaches 62.2% on SWE-bench Verified and 44.1% on SWE-bench Multilingual despite being trained exclusively on Python (Ludwig et al., 2 Apr 2026).
4. Search, verification, and inference-time scaling
One recurring observation is that no single SWE-agent is uniformly best across all issues. DEI turns this diversity into a meta-policy: it collects candidate patches from multiple agents or multiple runs, presents issue description, relevant context, pre-patch code, and post-patch code to an LLM-based review committee, asks for ordered explanations of issue, context, location, fix, and conflicts, assigns a score from 1 to 10, averages multiple votes when used, and selects the highest-scoring patch. On SWE-bench Lite, an open group whose best individual agent achieved 27.3% resolve rate reached 34.3% with DEI, and the best-performing group reached 55.0% (Zhang et al., 2024).
SWE-Search internalizes exploration within a single episode by combining a SWE-Agent with Monte Carlo Tree Search, a Value Agent that returns both a scalar value and a textual critique, and a Discriminator Agent that conducts multi-agent debate over up to five candidate final solutions. The framework reports a 23% mean relative improvement in resolve rate over an adapted moatless baseline across GPT-4o, GPT-4o-mini, Qwen-2.5-72B-Instruct, DeepSeek-V2.5, and Llama-3.1-70B-Instruct, and explicitly interprets performance gains as a consequence of backtracking, self-feedback, and deeper inference-time search rather than larger model size (Antoniades et al., 2024).
Verifier-centric work separates generation from selection. SWE-Gym trains outcome-supervised verifiers on trajectories sampled from its executable training environment and uses them for inference-time scaling: in the OpenHands setting, Pass@K rises from 20.6% at to 37.8% at and 42.8% at , while Best@K rises from 20.6% to 29.8% and 32.0%; the final combined agent-plus-verifier reaches 32.0% on SWE-bench Verified and 26.0% on SWE-bench Lite, which the paper presents as a new state-of-the-art among open-weight SWE agents (Pan et al., 2024).
SWE-RM argues that test-time scaling alone is not a sufficient criterion for a verifier because reinforcement learning depends not only on top-1 ranking but also on global discrimination and calibration. It therefore evaluates reward models with TTS, AUC, and expected calibration error, trains a 30B mixture-of-experts verifier with 3B activated parameters and 256k context, and reports SWE-Bench Verified gains from 51.6% to 62.0% for Qwen3-Coder-Flash and from 67.0% to 74.6% for Qwen3-Coder-Max. In RL, hybrid feedback that combines execution-based outcome with execution-free score is reported as stronger than execution-based-only feedback, at 54.8% vs. 51.8% (Shum et al., 26 Dec 2025).
At the high end of open post-training stacks, SWE-Master combines teacher-trajectory synthesis, long-horizon SFT, RL with real execution feedback, and test-time scaling. Under identical experimental settings it reports 61.4% resolve rate with Qwen2.5-Coder-32B and 70.8% at TTS@8, while also integrating LSP-based code navigation and reward shaping for long-horizon RLVR (Song et al., 3 Feb 2026).
5. Human collaboration, economics, and multi-agent organization
A major shift in the literature is from autonomous patch generation toward sustained collaboration with humans. ToM-SWE implements this as a dual-agent architecture: a primary SWE agent performs code generation, editing, command execution, and debugging, while a lightweight theory-of-mind partner models user goals, constraints, preferences, interaction style, and coding style through a three-tier persistent memory system. On Ambiguous SWE-bench with Claude Sonnet 4, ToMCodeAct reports 63.4% versus 51.9% for CodeAct. On Stateful SWE-bench, the main comparison reports 57.4% versus 13.5%, while the abstract highlights 59.7% versus 18.1%; in a three-week study with 17 professional developers and 209 sessions, ToM suggestions were useful 86.2% of the time (Zhou et al., 24 Oct 2025).
Direct observation of developers using in-IDE agents supports the same theme. In a study of 19 professional software developers using Cursor Agent with Claude 3.5 Sonnet on 33 open issues in repositories to which they had previously contributed, the overall success rate was 55%. Delegation style mattered sharply: one-shot resolution succeeded 38% of the time, whereas incremental resolution succeeded 83% of the time. Successful issues also involved more interaction on average, 10.3 prompts versus 7.1 for unsuccessful issues. The reported difficulties were not only code quality but trust, tacit repository knowledge, unsolicited actions, weak debugging/localization, and poor support for testing (Kumar et al., 14 Jun 2025).
A different line of work treats SWE-agents as economic actors. GHIssueMarket proposes a Docker-based sandbox for “Intelligent Software Engineering Economics (ISEE)” in which agents participate in reverse auctions for GitHub issues, communicate via IPFS PubSub, receive instant cryptocurrency micropayments through a Lightning regtest network, and query a built-in RAG interface for situational awareness. The contribution is explicitly a testbed rather than a benchmark result, intended to study budgets, competition, specialization, and outsourcing behavior under market incentives (Fouad et al., 2024).
Normative multi-agent systems extend the same idea from markets to governance. A 2035-oriented architecture paper defines SWE-agents as situated, autonomous, reactive, pro-active, and socially able software-engineering entities built on BDI reasoning with memory, LLM support, and a normative reasoner. Coordination is expressed with deontic norms—obligations, prohibitions, permissions—and commitments of the form , where agent commits to agent 0 that if antecedent 1 holds then consequent 2 will be realized. This line of work is explicitly visionary rather than empirically validated at benchmark scale, but it situates SWE-agents within longer-term Human-AI software engineering teams rather than single-task automation (Dam et al., 2 Dec 2025).
6. Evaluation, observability, and open problems
As SWE-agent trajectories have become longer and more complex, analysis itself has become a research problem. SeaView addresses this with a visualization and analysis system for experiment health, experiment comparison, experiment summarization, and experiment reporting. Its motivation is that some trajectories exceed 128k tokens and failures may stem from the LLM, the runtime environment, dependencies, connectivity, or configuration. In a user study with 10 researchers and developers, experienced users typically spent 10 to 30 minutes gathering the information SeaView provides, while less experienced researchers could spend 30 minutes to 1 hour diagnosing experiments manually (Bula et al., 11 Apr 2025).
Traceability studies push beyond pass/fail measurement. A large-scale empirical analysis of AutoCodeRover, Agentless, MASAI, SWE-Agent, and OpenHands-CodeAct argues that localization, patch generation, and reproduction test generation are the three core components of success. It also shows that agent performance drops sharply as issue difficulty increases and that successful agent-generated patches often differ structurally from developer-written fixes: agents tend to prefer localized, in-place edits, whereas developers more often refactor broadly, alter APIs, update multiple call sites, or shift logic to a more appropriate abstraction level (Ceka et al., 10 Jun 2025).
Ada treats repository understanding itself as an observational object. Operating in a bounded, read-only environment over six real repositories, it records 408 trajectories and projects them through five observation lenses: surface activity, journey arc, action policy, automatic adjudication, and codebase footprint. The reported results show that budget pressure compresses turns, lines of code viewed, files visited, and elapsed time while increasing per-turn effort, whereas the coach-judge condition increases activity without improving grounded conclusions (Zhuo et al., 7 Jun 2026). This suggests that faithful trajectory data can support systematic behavioral science for SWE-agents, but only when interpreted through explicit methodological lenses.
Benchmark integrity and leakage control remain recurrent concerns. SWE-Next responds with non-leaky prompting and strict submit gating so that agents are not given curated FAIL_TO_PASS/PASS_TO_PASS test lists and may submit only after producing a non-empty diff and running at least one test command (Liang et al., 21 Mar 2026). SWE-Master explicitly blocks git log and git show to prevent “git hacking” or leakage of hidden solutions (Song et al., 3 Feb 2026). In embodied controller generation, early Minigrid experiments revealed illegitimate strategies using inspect, call-stack introspection, env.unwrapped, and seed-matched internal environments; prompt constraints and rejection of unsafe packages were then added, and the resulting study found that dynamic exploration mattered much more than static code reading in fully observable settings, while partially observable tasks exposed a strong embodiment gap (Boulet et al., 24 Oct 2025).
Taken together, the literature presents SWE-agents less as a single model class than as a layered research program organized around interfaces, executable data, environment synthesis, verifier quality, collaboration protocols, and behavioral observability. A plausible implication is that future progress will depend as much on how agents gather and verify evidence, how they are embedded in human and multi-agent workflows, and how their trajectories are analyzed, as on raw backbone scaling alone.