How I got 24 AI agents to develop my codebase while I sleep

Trevion crossed 144K lines of code sometime in May and I hit the wall every solo builder hits: the backlog was growing faster than I could type. I had 53 database tables, 410 REST endpoints, seven services — and a roadmap file that only ever got longer. The math doesn't work. One person cannot maintain a platform that size and also keep building it.

So I stopped trying to be the workforce and started building one. The Build Engine is an always-on daemon that reads a task queue, picks the next piece of work, and dispatches a headless Claude agent into an isolated git worktree. The agent plans, writes code, runs the tests for its area, and opens a PR. There are 24 of these roles now — six build squads for different parts of the system, plus specialists: an architect, a security sentinel, a QA-chaos prober that deliberately tries to break things, a regression gate, trackers for staleness and consistency, and Matty, an ops agent I can talk to from a chat panel when something needs a kick.

The number that matters: 105 PRs merged, 84 tasks shipped, roughly 4 commits a day — sustained, including nights, including the days I don't open the laptop.

The part that makes it work isn't the agents

It's the regression gate. Every PR runs its area's gate before it's allowed to open. If the gate fails, the engine reverts the change automatically — no human involved in the revert, only in the merge. Before this existed, the agent loop was a toy: it produced code that looked plausible and broke something two services away. After it, the loop could run overnight without me waking up to a broken main branch. If you're building anything like this, build the gate first, not the agents.

What broke

Two things, both educational. First, throughput: I route agents through the local Claude CLI because the subscription makes per-token cost zero. The trade-off is the CLI throttles hard — the engine runs a concurrency semaphore of 2, and a call that takes 5 seconds when quiet can balloon to 2 minutes under load. Cheap and slow beats fast and expensive for background work, but you have to design for the slow case.

Second, the pile-up. In late June I checked the review queue and found 50 open PRs. The engine had been happily producing work faster than I was reviewing it, and open PRs rot — they drift from main, grow conflicts, and become worthless. The fix was three PRs of its own: a MAX_OPEN_REVIEW ceiling so the engine stops dispatching when the queue is full, a merge-train driver that safely drains reviewable PRs in order, and a rebase-or-close pass that cleared seven rotted ones. There's also now a hard daily run ceiling and a kill switch, because an autonomous system without a kill switch is not an autonomous system, it's a liability.

# the rule that ended the pile-up, conceptually
if open_prs_in_review() >= MAX_OPEN_REVIEW:
    return Idle(reason="review queue full — human is the bottleneck")

That comment is the honest part. The bottleneck is me. The agents can produce more than I can responsibly review, so the system now throttles to my pace instead of pretending I'm not in the loop.

What I'd tell you if you're building this

Don't chase full autonomy. Humans still review every PR here, and that's not a temporary limitation I'm embarrassed about — it's the design. The agents earn trust an area at a time as their gates get stronger. Maybe someday small-blast-radius changes merge themselves. Not yet.