The Challenge: Unattended Work You Can Still Trust
The team already wrote good technical plans, and those plans already became issues. The bottleneck was everything after that.
Coding agents could produce implementations. What nobody could produce was a reason to trust an implementation that nobody watched.
The repository made it harder. It was effectively greenfield, with no application code and no established stack, so there was nothing concrete to build a pipeline against. We designed the swarm against a check contract instead of a stack. Whichever of lint, format, typecheck, test and test:e2e a project defines, the runner runs. It skips the ones that are missing. The same pipeline works on day one of a repository and on year three of one.
The Design: The Runner Owns Every Gate
One principle decides the architecture. The runner owns every gate, not the agent. The agent never marks its own homework. Everything below follows from that:
- 01
A nightly schedule and a label, sharing one launcher
Issues enter the swarm on a nightly run, or the moment a developer applies a label. A launcher enforces a hard concurrency cap and refuses to start a second worker for an issue already in flight. We started the cap at one, deliberately.
- 02
A feedback loop the agent cannot skip
The runner executes the project's checks and feeds every failure back into the session until they pass. The agent never decides it is finished. Passing checks decide. Without this the signal that code works arrives in CI minutes later, or from a tester days later. That is why unattended work usually fails.
- 03
A review session with no memory of writing the code
A second session opens on the same diff with fresh context and reviews it against a severity-ranked schema. Findings above a threshold go back into the implementation session. Then the whole check suite runs again from the top.
- 04
Powers the agent is never given
It cannot edit the orchestrator that runs it. It cannot push, merge, or change a remote. It never holds the credential the runner uses to talk to GitHub. It edits files and commits locally. Every remote operation belongs to the runner.
- 05
Four separate ceilings on a single run
Iterations, conversation turns, wall-clock time, and money. Any one of them ends the run. A swarm that cannot stop itself is not unattended, it is unsupervised.
- 06
Not converging is a designed outcome
When the loop cannot get to green, the worker pushes what it has, opens a draft pull request describing what it tried and what still fails, labels the issue blocked, and pings a human. It never opens a confident pull request it cannot support.
Results, and How We Know They Are Real
- More Development Throughput
- 70%More Development Throughput
- Of the Code Agent-Generated
- 85%Of the Code Agent-Generated
- Of Pull Requests Reviewed by a Human
- 100%Of Pull Requests Reviewed by a Human
Development throughput went up 70%, and 85% of the code was agent-generated. Only 15% was written by hand.
The test we care about most is a negative one. Label a deliberately vague issue and watch what happens. The expected result is a blocked issue and a draft pull request explaining the ambiguity. If a vague issue turns into a clean pull request, the loop is not gating on anything. It is producing confident output nobody should trust.
Every run writes its full transcript to object storage with tracing and structured logs, so a pull request that looks wrong can be read back to the decision that produced it. Workers never merge. Every pull request still meets a human.