Cross-Model Async PR Stack

When two coding models are useful

Running Claude Code and Codex in parallel is valuable only when their work can be separated and evaluated. The goal is not to produce twice as much unreviewed code. One model can own the primary implementation while the other explores a competing design, reviews the diff, builds tests, or investigates a risky subsystem. Agent Orchestrator provides the control plane for isolated sessions and worktrees; reviewdog translates deterministic diagnostics into pull-request feedback; GitHub Actions supplies the shared acceptance gate. The resulting unit of work is a small, attributable PR with evidence, not a transcript showing that several agents were busy.

This stack fits teams with a healthy test suite and enough review capacity to benefit from concurrency. It is particularly useful when a task has independent backend and frontend lanes, when a migration needs an implementation and a separate verification pass, or when a second model can challenge architectural assumptions without touching the same files. It is a poor fit for tightly coupled changes where workers would continuously overwrite each other, and it should not be used to bypass a maintainer who owns the affected interface. Parallelism improves throughput only after task boundaries, merge order, and conflict ownership are explicit.

Architecture and ownership

Agent Orchestrator receives a task graph, creates isolated Git worktrees and branches, and records which worker owns each deliverable. Claude Code is the default deep implementation lane in this configuration; Codex is an independent implementation, test, or review lane selected according to the task. Each worker reads the same acceptance criteria but receives a different responsibility and allowed path set. reviewdog publishes supported linter and analyzer results as structured PR annotations, while GitHub Actions runs the canonical repository checks on every branch and again after integration.

The human lead remains responsible for decomposition, interface contracts, and merge authority. Before dispatch, define file ownership and any shared types or API shapes. If both models must touch the same interface, sequence the work: one lane lands the contract, then the second rebases and implements against it. Give every lane a branch name, worktree, required commands, output artifact, and deadline. The orchestrator may report status and collect handoffs, but it should not infer that a completed process is safe to merge. Only the PR diff, requested evidence, review state, and CI result can satisfy the delivery contract.

Plan a bounded parallel run

Turn the issue into a dependency graph before starting agents. Independent nodes may run together; shared-schema or shared-file nodes must be ordered. A practical first batch uses two workers: Claude Code implements the main path while Codex writes adversarial tests or reviews the surrounding failure modes. For larger features, add lanes only when each has a distinct output that can be reviewed on its own. Record inputs such as the base commit, task text, model role, allowed paths, and test command so an unexpected result can be reproduced rather than explained from memory.

Use worktrees to isolate files, dependencies, and Git state, but remember that external resources may still collide. Assign separate ports, databases, fixture namespaces, and temporary credentials where integration tests run concurrently. Never share a mutable local database by accident. Establish a handoff format containing summary, changed files, decisions, commands run, failures, and unresolved questions. A worker that encounters unclear requirements or an unexpected cross-lane dependency should stop and escalate. Quietly expanding scope creates integration debt that erases the time saved by parallel execution.

Review and integration sequence

Open one focused PR per deliverable or use a clearly ordered stack of PRs. reviewdog should report lint and analyzer findings close to the affected lines, but maintainers must distinguish deterministic diagnostics from model-generated opinions. GitHub Actions runs unit, integration, type, lint, security, and build checks appropriate to the repository. The second model can inspect the first model's diff after implementation, looking for broken invariants, missing tests, or unsupported claims. It should cite concrete files and behavior rather than offering a generic score.

Integrate from the dependency root outward. Rebase each worktree onto the accepted base, rerun the relevant focused checks, then run the workspace-level suite on the combined commit. Resolve conflicts in the lane that owns the interface, not in an unattended merge script. Keep a human merge gate even when all automated checks pass, especially for migrations, authentication, billing, or public API changes. After merge, archive the task graph and evidence long enough to diagnose regressions. This turns the orchestration record into an audit trail without treating agent chat as a substitute for code review.

Failure modes and controls

The largest risk is false independence. Two tasks can use different files yet depend on the same behavior, schema, or generated output. Detect this during planning by naming invariants and downstream consumers, and serialize work when ownership is unclear. A second risk is review saturation: five agents can create more diffs than one maintainer can evaluate. Limit active lanes to the team's measured review capacity and prioritize the critical path. A third risk is model agreement being mistaken for proof. Claude Code and Codex may share the same blind spot, so deterministic tests and live behavior checks remain mandatory.

Other controls cover environment and cost. Pin the base commit, avoid long-lived worktrees, delete temporary credentials, and prevent agents from pushing directly to protected branches. Cap model and CI spend per task, stop duplicate investigations once evidence converges, and require approval before a lane expands into adjacent systems. reviewdog annotations can become noisy, so enable only actionable tools and keep repository configuration reviewed. If a worker times out, preserve its branch and handoff, then decide whether to retry, reassign, or reduce scope; repeated autonomous retries can multiply cost without adding evidence.

Cost and rollout plan

Budget includes two model lanes, orchestration overhead, CI minutes, and human review. Begin with a two-lane pilot on low-risk issues where the baseline delivery time is known. Measure accepted cycle time, PR rework, conflict rate, test failures found by the independent lane, and reviewer wait time. More concurrent sessions are justified only when accepted throughput rises without increasing escaped defects or review backlog. A single strong implementation lane plus an independent test lane often outperforms several overlapping implementation attempts.

Create reusable task templates for implementation, verification, and review, but keep repository-specific commands and owners current. Review the first ten runs manually, then automate stable routing rules. The stack is mature when a maintainer can see who owns each branch, what evidence is missing, and why a PR is blocked without opening every agent transcript. Keep model choice replaceable: the operational contract, worktree boundaries, reviewdog configuration, and GitHub Actions checks should survive a model change. That prevents the workflow from becoming a fragile demo tied to one provider.