Seven lanes. Two Macs. One fleet — building itself.
What you’re looking at: a tool running its own product organization for a day. Engineering, architecture, GTM, docs, and executive validation — seven concurrent AI lanes on two Macs, coordinated by the thing they were building. The launch you’re reading about was shipped this way.
The mission
Build the tool with the tool. On 2026-08-14, the cait fleet (running as its private predecessor icodex v0.3.0-rc.43) coordinated its own next release, its v0.4 roadmap, and the entire public launch program — brand, site, namespace claims, GTM plans — across seven concurrent lanes on two Macs, without the lanes ever colliding.
The fleet manifest
| LANE | HOST · PROVIDER | ROLE | WHAT IT DID | EVIDENCE |
|---|---|---|---|---|
| ICODEX-RC44 | maclaptop · codex | DEVELOPER | rc.44 exact-reattach implementation; live bin/ + tests churn observed during the day | ● verified |
| ICODEX-ARCH | macstudio · codex | ARCHITECT | v0.4 acceleration roadmap; the “jetfuel” sequencing later adopted into the plan backlog | ● verified |
| GTM-OUTREACH | maclaptop · claude | GTM / BRAND | This site (seven design generations), namespace claims, launch runbook — and this case study | ● verified |
| DOCS | macstudio · codex | DOCS LEAD | Led the Sociail structural reorg (see the companion case) | ● verified |
| CEO | macstudio · codex | VALIDATION | Independent acceptance of the reorg — implementation and acceptance kept separate | ● verified |
| 2 platform lanes | macstudio · codex | PLATFORM | Ongoing infrastructure and application work in parallel repos | ● attested |
Census re-verified over the mesh, evening of 2026-08-14 — studio lanes observed by name: DOCS · CEO · ICODEX-ARCH · CTO-ADM · NETWORK-INFRA · ASSISTANT · TRAIN · GIT · 3× ICODEX-PU (primary/docs/qa) — the role model, running as real sessions. ● verified
The topology it ran on
Two machines, seven lanes, three clone fences, one origin. Observation crosses the mesh read-only; work lands only in idle sessions; each clone has one writer; validation is a separate lane. The moves below are the ones receipted on 2026-08-14.
How it ran
- Cross-machine observation, live. The GTM lane on the laptop read the architect’s progress summary on the studio over the registered SSH mesh — redacted, read-only, receipted — and used it to shape the roadmap debate the same morning. ● verified
- One writer per boundary, enforced. While the rc.44 lane held live source churn in the product repo, the GTM lane committed exactly two plan documents into the same repo — verified clean before and after, zero collisions. ● verified
- Roles over sessions. Lanes map to a provider-neutral team model — DEVELOPER, ARCHITECT, DOCS, CEO — with escalation paths, not vibes. The architect proposed; a separate analysis challenged the sequencing; the owner ratified; the backlog was renumbered. ● verified
- Governance held under load. Signed immutable releases (rc.42.1: 1063/1063 suite green; rc.43: 1071/1071) rolled out host-by-host with stop-on-failure gates and sessions_mutated: false proofs — the working lanes never felt an upgrade. ● verified
Honest limits — and what’s next
This fleet ran on the pre-rename, pre-v0.4 core. The operator was still the scheduler: handoffs were authored by a human, one dirty checkout still means one writer per repository, and remote liveness can go stale — in fact, while drafting this page the studio was briefly unreachable, which is why two rows above say attested rather than verified. Those exact gaps are the next tranche of work, already planned: an acceptance seam and measurement first, then isolated workcells, then bounded coordination — each gated, each receipted.