Skip to content

Autonomous Issue Resolver: Towards Zero-Touch Code Maintenance

🕒 Published (v1): 2025-12-09 11:11 UTC · Source: Arxiv · link

Ask a follow-up

Open an assistant pre-loaded with this paper's context.

💬 Ask ChatGPT✦ Ask Claude

TL;DR

AIR (Autonomous Issue Resolver) is a multi-agent system for repository-scale automated program repair that replaces file-first navigation with a Data-First Transformation Graph (DTG), where data states are nodes and transformations are edges. An RL-trained control policy navigates the DTG to localize faults causally rather than lexically, then coordinates editing and test-driven validation. AIR achieves 87.1% on SWE-bench Verified and resolves 70/100 issues in an exploratory OSS study.

Problem

Repository-scale automated program repair (APR) fails because bug causes and symptoms are distributed across files and abstraction layers, yet LLM agents are forced to navigate repositories as file systems under strict context limits. Existing retrieval-augmented approaches use semantic similarity (lexical or embedding-based), which does not capture causal data lineage—a generic sanitizer function causing a bug may share no textual similarity with the failing component. The paper calls this the "context crisis of repository-scale APR."

Method

AIR constructs a DTG from the repository using Tree-sitter AST parsing: variable declarations, function arguments, local variables, and return values become typed, schema-annotated nodes (data states); function calls and operators become edges (transformations). The graph is stored in Neo4j with ChromaDB for semantic search over nodes/edges.

Four specialized agents operate in a decoupled "Plan-Navigate-Execute" loop: - Context Agent: navigates the DTG graph (upstream/downstream traversal, node inspection, transformation reads, test execution with taint tracking) to localize the fault subgraph without ever opening files. - Maintenance Agent: receives the fault subgraph and formulates a high-level repair plan. - Editor Agent: translates the plan into concrete syntax-level edits. - Validation Agent: executes repository tests and CI tools to confirm the patch.

A DQN-based RL control policy governs navigation and stopping decisions: rewards are tied to successful resolution, regression avoidance, and edit minimality, penalizing broad or unstable patches.

Key Contributions

  • DTG representation: directed multigraph of data states (nodes with type, schema, constraints, source metadata) and transformations (edges with semantics, source references), compressing CPG bloat to causally relevant lineage.
  • AIR multi-agent architecture: decoupled Context/Maintenance/Editor/Validation agents with a risk-aware RL control policy as the orchestrator.
  • Empirical evaluation: SWE-bench Verified/Lite + 100-issue OSS study across 10 Python repositories, with ablations isolating DTG vs. RL contributions.

Results

  • 87.1% resolved on SWE-bench Verified vs. 79.8% (OpenHands + GPT-5), 66.6% (SWE-agent + Claude 4 Sonnet).
  • 73.5% on SWE-bench Lite vs. 56.67% (SWE-agent + Claude 4 Sonnet), 37.3% (AutoCodeRover + GPT-4o).
  • 70/100 issues resolved in OSS study vs. 41/100 (Gemini-2.5 Pro) and 28/100 (Claude 4 Sonnet).
  • Ablation — removing RL: 82.5% resolved (MTTR drops from 8.9 to 1.5 min, indicating premature termination, not efficiency gain).
  • Ablation — removing DTG (file-first fallback): 56.2% resolved, confirming DTG as the dominant performance driver.
  • Pillow (C-extension heavy): AIR scores 4/10 vs. 0/10 for both commercial models, exposing the cross-language boundary limit.

Limitations

  • DTG builder primarily targets Python; C/C++ extension boundaries are treated as opaque edges, breaking data lineage in hybrid-runtime repositories (evidenced by poor Pillow performance).
  • OSS study uses a curated, pre-selected issue set with reconstructed context from final PRs, introducing selection bias toward resolvable coding issues.
  • No formal correctness guarantees beyond repository tests and static/dynamic validation signals; AIR is an empirical system, not a verified one.
  • RL component uses a simple DQN; the paper acknowledges it could be replaced by MCTS-style traversal without loss of core functionality.

Relevance to Harnesses / Meta-Harnesses

AIR is a concrete instantiation of a multi-agent harness where a central orchestration policy (RL control) coordinates four specialized sub-agents (Context, Maintenance, Editor, Validation) over a structured shared state (the DTG). This decoupled "Plan-Navigate-Execute" loop directly demonstrates how meta-harness design—assigning roles, managing context windows, and enforcing feedback loops—enables capabilities (87.1% SWE-bench) that monolithic agents cannot reach. The DTG itself functions as the harness's shared working memory, replacing the ad hoc file-system interface that most agentic frameworks rely on. The ablation result (removing the orchestration policy drops performance by 4.6 pp; removing the shared representation drops it by 30.9 pp) provides rare empirical decomposition of which harness component carries the most weight—a directly actionable finding for anyone designing agentic harness architectures.