Built with Claude Code
This lab is built by AI, and that is the interesting part only because of the discipline around it. An orchestrator directs several parallel Claude Code sessions, each in its own isolated copy of the code. One human plans the work, reads every change, and performs every merge. The rules the sessions follow are the same ones a careful team would follow: decide in a design doc before writing code, one change per pull request, and a written runbook for anything that touches live infrastructure.
The orchestrator and parallel sessions
The work is split across several Claude Code sessions running at once, coordinated by an orchestrator that hands each one a task a step at a time. Every session works in its own isolated copy of the repository, branched from the mainline, so two sessions can never edit the same working files or collide on a branch. The orchestrator keeps the sessions pointed at different parts of the backlog and relays each task and result through one human. That is what makes running several AI workers in parallel safe rather than chaotic: they are isolated by construction and sequenced by a person.
Sole merge authority
No session merges its own work. Every change lands as a pull request that one human reads and merges, against the same branch protection and automated checks any other contributor would face. A machine wrote the code, which is exactly why the review gate is not relaxed: the author being fast and tireless is a reason for more scrutiny at the merge, not less. The human is the single point where work becomes part of the lab.
A design doc before code
Decisions are written down before they are built. A design that matters gets a committed decision record, reviewed on its own, and only then does code implement it. The effect is that the diff implements a decision that already exists rather than deciding it in passing. It keeps the thinking human-owned and legible, and it means a change can be argued with at the level of the decision, not just the code.
One PR per change
Each change is its own small, reviewable pull request: one backlog item, one branch, one PR. Nothing is bundled. That keeps review a real gate rather than a rubber stamp on a pile of unrelated edits, and it keeps the history legible, so the story of why something changed can be read one step at a time later.
A runbook for every pipeline
Anything applied to live infrastructure ships as a guided runbook: the host it runs on, the exact command or the exact field to set, the output to expect, the independent check that it worked, and what to do if it did not. Nothing is applied from memory. A change to a config file is not the same as a running system, so the runbook is how a committed change becomes a proven one, with a human driving each step.
How changes are tested
A change is not trusted because it looks right. Small, offline tests run on every pull request, a runner discovers and executes them automatically, and the automated checks have to pass before a human will merge. Just as important is the habit of proving the result rather than asserting it: a claim that something is fixed comes with the command output that shows it, and anything that can only be confirmed on live infrastructure is labelled as needing that confirmation before it counts as done. The point of the whole workflow is that "the AI did it" is never the evidence; the test run, the review, and the runbook are.