Speculative Branching

Speculative branching is competitive execution applied to uncertain decisions. When you face a fork in your architecture — should the service use REST or GraphQL? Should the database be PostgreSQL or DynamoDB? Should the auth layer use sessions or JWTs? — you can pursue both paths simultaneously. Each branch runs in its own microVM, implementing the full solution with its chosen approach. You evaluate both implementations against real criteria (performance benchmarks, code complexity, migration effort) rather than debating hypotheticals.

The economics of speculative branching only work when the cost of running two parallel tasks is less than the cost of choosing wrong and refactoring later. For a 15-minute Codex task costing a few dollars, running two branches costs twice that. For a wrong architectural decision that requires two weeks of human refactoring, the speculative branch that prevents it is absurdly cheap. The breakeven calculation is simple: if the rework cost of a wrong decision exceeds 10x the parallel execution cost, speculative branching is justified.

# Speculative branching: REST vs GraphQL
codex cloud --branch "spec/rest-api" \
  "implement the product catalog API using REST with \
   OpenAPI spec. Include CRUD endpoints, pagination, \
   filtering, and comprehensive tests." &

codex cloud --branch "spec/graphql-api" \
  "implement the product catalog API using GraphQL \
   with schema-first design. Include queries, mutations, \
   pagination, filtering, and comprehensive tests." &

wait

# Compare: code complexity, test coverage, performance
codex cloud "compare branches spec/rest-api and spec/graphql-api. \
  Evaluate: lines of code, test count, query complexity, \
  type safety, and client ergonomics. Produce a comparison table."