What This Stack Does
This stack creates a controlled issue-to-patch loop with three different software engineering agents. OpenHands handles a broad autonomous lane, SWE-Agent focuses on a structured issue and repository repair loop, and Aider provides an interactive Git-native lane for guided implementation or recovery. Ollama is an optional local inference path, while tmux keeps agents, tests, logs, and the human approval step visible in one terminal control plane.
Autonomous does not mean unattended production authority. The stack should begin from a disposable worktree or sandbox, use non-production credentials, and stop at a reviewed patch. It is suitable for reproducing bugs, proposing fixes, generating tests, and comparing repair strategies. Deployment, schema migration, secret rotation, and merging remain separate human-owned actions unless a stronger control system has been reviewed and explicitly authorized.
Choose the Right Agent for the Task
Use OpenHands for broad repository exploration and multi-step implementation when the environment can be sandboxed. Use SWE-Agent for a tightly described issue with a known test harness and a clear repository boundary. Use Aider when a developer wants continuous steering, small Git commits, and a practical repair loop after tests fail. The tools overlap, but assigning roles makes their differences useful instead of running three agents that all attempt the same unrestricted task.
Ollama can support local experiments or low-cost iterations when an appropriate model fits the hardware, but local inference is not automatically strong enough for every repair. Start with repository mapping or test explanation, then escalate deliberately if the local lane stalls. Keep the cloud and local transcripts separate, remove sensitive context before switching providers, and record which model path produced each candidate patch.
Sandbox and Repository Setup
Create a clean worktree per agent from the same commit and mount only the repository, temporary build cache, and test fixtures required for the task. Deny access to the host home directory, SSH agent, browser data, production kubeconfig, cloud credentials, and unrelated services. If Docker or another sandbox is used, run as a non-root user, cap CPU and memory, and treat network access as a permission that must be justified by dependency or test requirements.
Prepare an issue contract containing the observed failure, expected behavior, affected paths, approved commands, validation suite, and stop conditions. Include what the agent must not do: no dependency upgrades unless necessary, no disabled tests, no broad formatting, and no push or merge. Put the same contract in every worktree. A reproducible failing test is the strongest starting point; without one, require the agent to create a minimal reproduction before editing production code.
Run the Issue-to-Patch Loop
In tmux, dedicate windows to OpenHands, SWE-Agent, Aider, tests, resource monitoring, and operator review. Let each autonomous lane inspect and propose a plan before granting write access. Once approved, run within the worktree and capture commands. Aider can be the guided repair lane when an autonomous candidate is close but needs targeted correction. Never let one agent operate directly on another agent’s branch during the independent phase.
After a patch, run the exact validation suite from a neutral test pane. Require failures to remain visible and limit retries so an agent cannot spend indefinitely or mutate the environment until tests pass accidentally. Compare candidate diffs, test evidence, new dependencies, error handling, and scope. The final patch may be one candidate or a new human-composed change, but it must be understandable without the agent transcript.
Security, Reliability, and Failure Handling
Agent-generated shell commands can delete data, exfiltrate secrets, or alter shared infrastructure even when the code task seems harmless. Use read-only credentials, mock external systems, and require confirmation for package installation, network calls, database operations, or commands outside the repository. Scan the final diff for secrets, disabled safeguards, hidden telemetry, generated binaries, and test changes that weaken the acceptance criteria.
Define failure states before the run: repeated identical errors, scope expansion, unexplained destructive commands, test regressions outside the target, or resource exhaustion. Stop and reset the worktree when a lane reaches the threshold. Do not reward an agent for recovering from damage it caused. Preserve a concise incident note and the failing approach, then restart from the clean commit with a revised contract or a different agent role.
Cost, Performance, and Human Review
Measure time to a passing, reviewable patch rather than raw autonomy. Track model usage, retries, environment setup, test duration, and human review time. Local Ollama runs may reduce provider spend but consume hardware and can be slower or less capable for complex repositories. Hosted models may solve difficult tasks faster while changing the data and budget boundary. Treat those as engineering tradeoffs, not as a single leaderboard.
Human review is the final control, not a ceremonial click. The reviewer should reproduce the failure, inspect the patch, run tests from a clean environment, and confirm that the issue contract is satisfied. High-confidence agents can reduce repetitive investigation, but they do not own product intent or production risk. If the reviewer cannot explain the change, the patch is not ready to merge regardless of passing tests.
When to Use It and the Bottom Line
Use this stack for well-scoped backlog issues, benchmark-style repair tasks, test generation, dependency investigation, and internal experiments with autonomous coding. Avoid it for live incident response with fragile shared state, repositories without a reliable build, or changes that require undocumented business decisions. The more authority an agent receives, the stronger the sandbox, logging, and rollback expectations must become.
The safe architecture is OpenHands and SWE-Agent for isolated autonomous proposals, Aider for guided implementation and repair, Ollama for optional local inference, and tmux for continuous operator visibility. Keep production outside the sandbox, require deterministic evidence, and stop at a human-reviewed patch. That boundary captures the value of autonomous SWE tools without confusing code generation with operational ownership.