Looper

The deciding trait is that the roles are separate and named. A planner, a reviewer, a fixer and a worker each own one job, so when the output is wrong you can usually tell which stage produced the mistake instead of blaming a single opaque run. That attribution is what makes an autonomous tool correctable rather than merely impressive.

What it needs from you is discipline upstream. Vague issues produce confident nonsense here, faster than elsewhere. Pick it if your tickets are already precise. Pick something supervised if you write the specification while you code.

Two unbounded loops facing each other is the failure mode, and the row describes it as a feature. A reviewer that re-reads on every commit and a fixer that commits in response is a system whose termination depends on two models agreeing, and models disagree cheaply and repeatedly. Nothing documented caps the iterations, the tokens or the wall clock, and this runs as a daemon.

What it does right is refuse a fixed step count. Success criteria are a better stopping rule than an arbitrary limit, when something else is watching the bill.

1. Externalising state to the forge is the strongest design decision here. Issues, threads and pull requests are durable, already backed up and already understood, so the agent holds no private record whose loss would make a run unreconstructible. 2. Emitting a specification for review before implementation separates the two failure classes, so a wrong plan is caught before it becomes a wrong diff.

2. No evaluation is published and none is claimed, which is consistent, if unfortunate for a tool whose output is unsupervised code.

Autonomous engineering is the most expensive category to compete in and this row has none of the inputs. No funding, no hosted product, no sales motion, and buyers in this segment purchase reassurance as much as capability. Free removes the price objection and does not touch the trust objection, which is the binding one.

Moat: none, though self-hosting appeals to the buyers the funded vendors cannot serve. Likely path: it stays a capable open alternative that a niche adopts and nobody acquires. Position: run it if you would have built it, and expect to maintain it yourself.

This is the rare one that fits where work already happens: a background process on our hosts, watching registered repositories, producing pull requests into the review process we already run. That is measurable, which is more than most of this board offers.

The condition is the credential. A machine account holding write access to our repositories is a thing security will want scoped, rotated and logged, and the row provides no audit trail of its own to help. There is no identity integration either. Approved with conditions: one repository, a scoped token, and branch protection that no bot can bypass.

Forgejo support is the detail that earns my attention. Almost everything in this category assumes one commercial forge and stops, which quietly makes self-hosting a second-class choice. Here the autonomous loop runs against a forge on my own hardware, under a permissive licence, installed with one Go command and no runtime.

What is missing is the model side. No MCP client, so my servers stay outside the loop, and no local endpoint, so the one part I cannot bring home is the inference. Everything else about this is a machine I own.