Repository-level automated code repair agent using SWE-Bench dataset
Fixing bugs in real-world codebases requires understanding how code works across multiple files, not just at the function level. Most automated repair tools operate on isolated functions or small patches, which limits their effectiveness on production repositories. This project uses the SWE-Bench dataset to train and evaluate agents that can navigate entire repositories, locate relevant code, understand context, and generate fixes that actually work in practice.
graph TD
A[SWE-Bench Issue] --> B[Issue Parser]
B --> C[Repository Navigator]
C --> D[Context Gatherer]
D --> E[Code Analyzer]
E --> F[Repair Generator]
F --> G[Patch Validator]
G --> H{Tests Pass?}
H -->|No| I[Feedback Loop]
I --> E
H -->|Yes| J[Patch Output]
subgraph "Context Layer"
C
D
E
end
subgraph "Repair Layer"
F
G
end
pip install repair-agent
from repair_agent import RepairAgent
# Initialize agent with repository path
agent = RepairAgent(repo_path="./my-project")
# Load issue from SWE-Bench format
issue = agent.load_issue("issue_data.json")
# Generate repair
patch = agent.repair(issue)
# Validate against_v2 test suite
if agent.validate(patch):
agent.apply_patch(patch)
print(f"Repair applied successfully: {patch.stats()}")The agent operates in several phases. First, it parses the issue description to extract key information about the bug, including error messages, expected behavior, and affected components. Next, it navigates the repository structure to identify relevant files using a combination of static analysis and semantic search. The context gatherer collects related code, including function definitions, class hierarchies, and import chains.
Once context is assembled, the code analyzer builds a program model to understand data flow and control dependencies. The repair generator uses this model to propose patches, which are then validated against_v2 the repository's test suite. If tests fail, feedback is extracted from the test output and fed back into the repair process for iterative refinement.
Configuration is managed through a repair_config.yaml file or environment variables:
# Model settings
model:
provider: openai # or anthropic, local
name: gpt-4
temperature: 0.2
max_tokens: 4096
# Search and context
context:
max_files: 20
max_lines_per_file: 500
semantic_search: true
# Validation
validation:
max_iterations: 5
timeout_seconds: 300
run_full_suite: false
# Paths
repository:
base_path: "."
test_command: "pytest"
exclude_patterns:
- "*.pyc"
- "__pycache__"
- ".git"Environment variables override config file settings:
export REPAIR_AGENT_MODEL_PROVIDER=anthropic
export REPAIR_AGENT_MODEL_NAME=claude-3-opus-20240229Q: Does this work on languages other than Python?
A: Currently Python only, but the architecture is designed to be language-agnostic. Support for JavaScript and Java is planned.
Q: How long does a typical repair take?
A: Between 2-10 minutes depending on repository size and issue complexity. Most time is spent in context gathering and test validation.
Q: Can I use local models instead of API providers?
A: Yes, set model.provider to local and point to a compatible OpenAI-style endpoint. Models smaller than 7B parameters typically struggle with repository-level reasoning.
Q: What's the success rate on SWE-Bench?
A: Current evaluation shows ~25% of issues fully resolved on SWE-Bench Lite. This is comparable to other repository-level agents but still far from human performance.
Q: How do I debug failed repairs?
A: Enable verbose logging with --log-level DEBUG. The agent saves intermediate outputs (context, proposed patches, test results) to .repair_agent/logs/.
MIT