The Hardest Part of Parallel AI Development Was State Management

Tomohiro Iida · Published: September 9, 2026Last updated: October 18, 2026

Codex and Claude Code can generate code, tests and pull requests faster than a person can manage a long queue of handoffs. Over roughly three months of parallel AI development, a different problem became more expensive: working out who owned a task, what had actually passed review and how to recover safely after interruption.

More agents increased the coordination burden

We began by separating tasks such as implementation and review. As repositories, branches and pull requests multiplied, agents could modify overlapping areas, review outdated commit SHAs, redo already resolved work or wait without a durable explanation. Development had accelerated but the human operator was still reconstructing status and deciding which agent could act.

That observation changed the goal. We needed a controller to maintain task state and permissions, not merely another agent capable of writing code. A useful system must say which work is assigned, which evidence applies, which transitions are blocked and what would permit a safe resumption.

Reconstruct current state before acting

Conversation history is useful context but becomes stale immediately when someone pushes a new commit or a CI run completes. Our rule is Reconstruct before Act: read the current GitHub and durable controller records before changing anything. A recovery checkpoint needs the repository, current exact HEAD, owned scope, outstanding review, known effects, stop reasons and next safe decision.

One writer, exact-head review, and separate authority

Separate Git worktrees help isolate files but do not make overlapping changes safe. We allow one mutating writer within a shared responsibility area. The reviewer must independently evaluate the candidate that will actually merge. A green check against an earlier SHA has no authority over a changed head; implementation, review, merge and deployment permissions are deliberately separate.

This gives the organisation a reason to reject a change even when a test is green. An independently found high-severity correctness issue must block the release. The result belongs to the exact patch and environment reviewed, not to the pull request number in general.

One 24-hour operating record, from September 8 at 13:16 to September 9 at 13:16 (Japan time), illustrates why rejecting work can be evidence of progress. In one workflow, hosted Linux and Darwin CI passed before independent compatibility QC found a high-severity blocker, so the candidate was rejected. In a separate SIGNAL pull request, intermediate heads were superseded and fresh checks on the final head were required before merge. A MiyakodeIT performance patch reduced a measured operation by about one second, from roughly eight to seven seconds, but was not merged after an independent correctness concern.

Those are observed engineering decisions, not three successful releases. GitHub history cannot reliably reconstruct how many minutes the human operator spent intervening during that window, so no intervention-time estimate is presented here.

Unknown is a third result, distinct from success and failure

A connection can fail just after sending an instruction to push, deploy, migrate data or change billing. The remote operation might have succeeded. Blindly repeating it risks duplicate side effects. The controller therefore records an uncertain outcome and checks the real external state before authorising another attempt.

A process stopping is not, by itself, a failure of autonomy. The relevant question is whether task ownership, stop decisions, evidence and possible side effects survive the stop and can be reconstructed for the next run. Human intervention should focus on genuinely uncertain or consequential decisions rather than routinely pressing Resume.

October 2026: source correctness did not equal OS acceptance

A subsequent migration to a new Controller encountered a macOS Installer and credential-admission problem after code and continuous-integration checks had succeeded. The acceptance layers are different: reviewed source, a reproducible package, the actual installation, credential scope, a real process and production behaviour. The operating record available on October 17 did not establish that the new Controller was formally running in production.

Repeating a previously failed installation or bypassing a trusted host-policy check is not a substitute for diagnosis. A recovery requires evidence about the failed state, a minimal source correction, a new independent quality review, a fresh package and authorised device-level validation. Published examples omit private machine credentials and customer-specific details.

What another team can adopt

Before adding another coding agent, define a task ledger, one writer per overlapping scope, immutable candidate evidence, a separate reviewer and a procedure for reconciling uncertain external operations. Measure completion and safe recovery rather than counting agents or green badges. Adopt the native runtime only after its actual device and permission boundaries have passed.

Why exact SHA matters when reviewing a pull request

How CI triggered by AI development can be made more meaningful