27 autonomous merges in two weeks. 97% success rate. One failed run out of 42. Average implementation time: 4 minutes per issue.
I run a software system that files its own issues, decomposes large tasks into buildable units, implements them with tests, opens PRs, and waits for me to merge. It runs on a $9/month VPS and a Claude subscription. The total infrastructure cost is $110/month. Average cost per implemented issue: $1.61.
This isn't a demo. It's been running in production since July 1, 2026.
The stack #
$100.00/month Claude Max 5x (triage + implementation via Claude Code CLI)
$ 9.99/month VPS (Hostinger, 2 vCPU, 8GB RAM, Ubuntu)
$ 0.00/month GitHub
─────────
$109.99/month Total
The system is called autoloop. It's open source. The entire configuration for a repository fits in one file:
repo = "your-org/your-repo"
triage_model = "sonnet"
impl_model = "claude-opus-4-6"
verify_cmd = "uv run pytest"
max_retries = 3
protected_paths = ["autoloop/", "autoloop.toml"]
Three systemd timers. No Kubernetes. No orchestration framework. No queue service.
OnCalendar=*-*-* 00:00:00 UTC # triage
OnCalendar=*-*-* 02:00:00 UTC # implement
OnCalendar=*-*-* 04:00:00 UTC # changelog
How a feature ships while I sleep #
A GitHub issue enters the queue. Here's what happens, unattended:
Triage (Sonnet, ~$0.10): The system reads the issue, validates the template, estimates story points, and assigns priority. If the template is incomplete, it rewrites the issue body to fix it and re-triages.
If an issue is too large, the system decomposes it into sub-issues with dependency ordering, files them, and triages each one. This is recursive. A 5-point issue becomes three 2-point issues. If one of those is still too large, it splits again. The system keeps decomposing until every piece is buildable.
Implement (Opus, ~$1.50): The system picks the top ready issue respecting dependency order, creates a branch, invokes Claude with the issue spec and repo context, runs verify_cmd
(tests must pass), runs lint, checks that test files were added, and opens a PR.
Verification gate: If tests fail or no test files were added, it retries up to 3 times, feeding the errors back into the next attempt. If all retries fail, it labels the issue needs-human
and moves on.
I review PRs on my phone via Claude Code remote control (a persistent session running in tmux on the VPS) and merge. When the queue is deep, I trigger the next implementation on-demand from the same session. If there's a merge conflict, I resolve it from the phone too. That's my entire contribution to the process.
When it fails #
Run #14 targeted a GitHub Actions workflow file with assumptions about its structure that didn't match reality. The system retried 3 times, each time failing verification, then labeled the issue needs-human
and moved on to the next item in the queue. I reworked the issue, re-labeled it ready
, and it succeeded on the next cycle.
The system doesn't pretend to be infallible. It fails, labels the failure, and gets out of the way. That's the right behavior.
The constraint that makes it work #
The system cannot modify itself.
protected_paths = ["autoloop/", "autoloop.toml"]
If an issue targets files under protected_paths
, triage routes it to needs-human
instead of ready
. The builder never touches its own triage logic, implementation pipeline, or configuration. This is checked at both triage (primary gate) and implementation (safety net).
** Self-improvement without self-modification.** The system improves the
product. It cannot improve the
process. That boundary is what makes it safe to run unattended.
What it actually produced #
Patina is a cognitive assistant: 7,200 lines of Python, 9,200 lines of tests, 31 MCP tools, v0.9.0.
I built the initial core architecture interactively with Claude Code. Once the foundation was solid, autoloop took over the backlog. Of the last 40 merged PRs, 27 were implemented autonomously.
The pipeline itself is 3,500 lines. It was originally embedded in Patina's repo, then extracted into a standalone package that can be applied to any repository with one command:
autoloop init --repo your-org/your-repo --verify-cmd "pytest"
autoloop triage
autoloop implement
Boundaries #
I want to be honest about where this applies.
This works for: solo builders, indie hackers, small teams. Repos where one person holds full context. Non-critical-path systems where a 24-hour fix cycle is acceptable.
This requires caution for: regulated environments that need stronger human gates. Multi-team codebases that need more than one reviewer. Customer-facing production with SLAs that need rollback mechanisms this setup doesn't provide.
The principle scales. The implementation doesn't. A Fortune 500 company shouldn't run this exact setup. But the pattern (observe, decompose, implement, verify, gate) applies at any scale with appropriate controls.
The shift #
Every platform shift democratized something that previously required scale:
- "You need a data center." After AWS: No, you don't.
- "You need bank relationships." After Stripe: No, you don't.
- "You need a DevOps team." After Vercel: No, you don't.
This is the same shift for software development itself. Self-improving software is no longer a funded-startup problem. It's a solo-builder problem. The bottleneck isn't compute cost or infrastructure complexity. It's taste, knowing what to build, what constraints to enforce, and when to let the system run.
The tools are available tonight. The only question is what you'd point them at.
The code is open source at github.com/Sanctum-Origo-Systems/autoloop. I intentionally separated observation from implementation because systems that evaluate themselves should not simultaneously modify themselves. Patina runs as two separated instances: one observes the human operator, the other builds code. That architecture will be in a future post. Next on the roadmap: scaffolding greenfield projects from spec to MVP. andywidjaja.com