Turbo Rig

The idea

Agents build.
A different model family reviews.
Humans merge.

One rig, multiple harnesses. The builder — whichever model is on builder duty — works in isolated worktrees. Every PR then passes an adversarial review gate run by a different model family, which must end its review with a parseable verdict. Verdicts that do not parse count as rejections; the gate fails closed. Only a human merges.

The moving parts

• The review gate — one portable bash script calling reviewer CLIs (Claude, Codex, GLM) with an append-only log. No daemons, no services. Details.
• The constitution — eleven written laws the agents operate under, injected into every review. The governance model.
• Git-versioned agent memory — cross-session state lives in the repository, so context is auditable, diffable, and roll-back-able like code.
• The roster — builder and reviewer roles are harness-agnostic; models are swapped without touching the machinery.
• Automations — scheduled digests, merge-qa sweeps, and canaries feed the same logs the gate writes.

Why it exists

Because its predecessor proved the wrong lesson. Turbo Flow showed how much agentic horsepower one developer could command — and that more agents did not mean better engineering. Turbo Rig is the redesign: fewer moving parts, one strong gate, and the discipline recorded in the Turbo Flow story.

The receipts

The rig publishes its own weekly metrics — PR counts, gate runs, tokens, cache hit rate — derived from the append-only logs, not estimated. For the audited week of September 21–28, 2026: 180 merged PRs across 16 repositories, 967 gate reviews, 6.57 billion tokens, 96.5% prompt-cache hit rate.

Figures below come from one audited production week (September 21–28, 2026) across my own GitHub account — merged-PR counts, gate logs, and token accounting, published weekly on the Turbo Rig stats page. They are measurements of my own workflow, not industry averages.

The full narrative: case study — one week inside the rig.