The tools are new — AI agents that write, test, and review code. The discipline is old: tests first, adversarial review, small merges, nothing declared done until it's proven working. The practice is the combination.
Four agents, walled off from each other — so no AI ever grades its own homework.
The biggest failure mode of AI-written code is an agent grading its own homework: it writes tests that its own implementation conveniently passes. So the phases are split across four agents that cannot see each other's work.
The final agent's instructions are to hunt for reasons the work is wrong — a shortcut, a test that passes for the wrong reason — and to send it back when it finds one. It regularly does.
Independent work runs as parallel agent sessions; an orchestrator merges one branch at a time, testing between merges.
Independent work runs in parallel — each agent session in its own git worktree, on its own branch, with its own dev server and port. An orchestrator session plans the work, hands each piece its context, then merges branches one at a time with a full review-and-test gate between each merge.
On a good day it feels less like “using a coding assistant” and more like coordinating an uneven but surprisingly productive team.
I built a local board so I can supervise many Claude Code sessions without living inside terminal scrollback.
Claude Code is powerful in a terminal. It gets awkward when the work becomes a fleet: orchestrators, implementation sessions, review sessions, multiple repos, all running inside Docker development containers. Terminal tabs are a poor way to stay on top of which sessions need attention and which are related to which others. They also look like terminal sessions, not a user-friendly interface. Yet they are the way I know to run sessions that don't prompt me constantly for permissions.
So I built a small local web app I call the Orch Board. It reads the Claude session files, groups sessions by state, shows which ones need input, gives me a calmer reading pane, and keeps a durable notices feed for blockers, completions, auth prompts, and merge decisions. The sessions still run in the Docker sandbox; the board just gives me a better way to see and manage them. I have no doubt there are better ways to do this. I would like to compare notes with people who have solved the problem differently.
An automated browser uses the product like a person; an AI reviewer compares what it sees against what should be true.
Beyond unit tests: an automated browser drives the actual product through real user journeys — clicking, typing, navigating like a person would — screenshotting every step. An AI reviewer then compares the screenshots against a living document of what the product is supposed to do, and files what it finds as a ranked report of bugs and gaps.
QA that runs while I sleep, and never gets bored of clicking.
Agents get broad permissions inside Docker containers, where the blast radius is contained.
Agents run with broad permissions — that's what makes them fast — inside Docker containers where the blast radius is contained: production credentials absent, source repos mounted read-only, secrets loaded per-app. The security boundary is the container, not the agent's judgment.
Agents forget; the system doesn't — a git-synced task graph, session summaries, and living architecture docs.
Agents forget; the system doesn't. A git-synced issue tracker holds the task graph, every session ends with a written summary, and architecture documents are updated in the same commit as the code that changed them. Any new session — human or agent — can pick up exactly where the last one left off.
None of this is about trusting AI. It's about building a system where AI doesn't have to be trusted — where every piece of work is independently tested, adversarially reviewed, and proven in a running product before it counts.
I put these processes together myself, mostly while carrying a demanding client workload — much of it spent building Otis. I have no doubt this tooling can be improved, and frankly, much of it will be built into Claude Code, Codex, and standard developer tooling before long.
I am still the sole technical lead on most of this work, but I do not expect that to be the permanent shape of it. Part of what I am trying to learn is which parts of this practice scale to collaborators, partners, and contractors — and which parts are just local scaffolding I built because I needed them.
Which is exactly why this page exists. If you've solved these problems differently — or better — I want to hear how. If you could use any of this, I'll share the protocols, the hooks, the lessons. The practice got built by borrowing shamelessly; it'll get better the same way. Email me →