The Third Pass

Not every project needs three pairs of eyes. Most don’t. But when the business domain is complex enough that experienced humans miss edge cases — when the cost of a subtle bug is measured in compliance violations or financial discrepancies — you want coverage. Real coverage.

This is how I ship code when it matters.

Two Agents, One Workflow

This workflow uses Claude Code for implementation and Codex for a separate review.

The implementation agent reads the repository, works from the requirements, makes changes and runs checks. Its role is to build a reviewable result.

The reviewing agent reads the original requirements and the proposed change with a fresh context. Its role is to find defects and missing evidence.

The value comes from distinct responsibilities and verifiable evidence, not from personal subscription or usage details.

Claude Code: The Builder

My terminal alias:

alias c="claude --dangerously-skip-permissions --effort max"

One letter. Maximum firepower. No friction.

Global settings in ~/.claude/settings.json:

{
  "permissions": { "allow": ["*"], "deny": [] },
  "alwaysThinkingEnabled": true,
  "effortLevel": "max",
  "skipDangerousModePermissionPrompt": true
}

The historical implementation example uses a high-effort model with broad authorized workspace access. Bypass mode changes permission prompting; it does not remove every managed restriction or make external actions reversible.

Every repo has a CLAUDE.md that gives Claude full context — conventions, architecture, API access, PR format, the works. One file, and the agent knows how to operate in that codebase. I wrote about this approach in Spec-Driven Agentic Development.

The CLAUDE.md also contains instructions for creating pull requests with full descriptions, using the gh CLI for all GitHub operations, and connecting to Linear via API for ticket context. When Claude Code finishes implementing, the PR is ready for review the moment it’s created — complete with what changed, why, and a link to the ticket.

Codex: The Reviewer

Configuration in ~/.codex/config.toml:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
approval_policy = "never"
sandbox_mode = "danger-full-access"

A different provider and model reviews the same change. This is useful diversity, but it does not establish a different underlying architecture or eliminate shared blind spots.

The only additional setup per repo: a thin AGENTS.md file:

Read `./CLAUDE.md` before doing any work in this repository.
`CLAUDE.md` is the canonical source of truth for all repository instructions.

An AGENTS.md pointer can direct Codex to the same written repository rules. Native imports, tools, skills, connections and permission settings still need their own supported configuration; two lines do not reproduce an entire agent environment.

The Workflow

The process, step by step:

1. I provide the requirement. A Linear ticket, a prompt, a problem description. The human language is the programming language.

2. Claude Code implements. Reads the spec, writes the code, runs the tests, creates the PR with full description and ticket link.

3. Prepare a review handoff containing the change, original requirements, branch and relevant validation evidence. Separate the implementer’s interpretation from source evidence.

4. The reviewer independently inspects those original sources and the diff. It checks the implementation against the requirements and reports concrete findings.

5. The human performs the third pass: inspect the findings, relevant code and test evidence, then decide what is ready. This is one implementation pass, one separate review and human verification.

6. We iterate until it ships.

An implementer-authored handoff saves navigation time, but it can also carry the implementer’s assumptions. Give the reviewer original evidence and enough access to challenge that framing.

The Orchestrator’s Job

This is the part nobody talks about when they demo AI coding tools.

The hard work isn’t “hey Claude, build this feature.” That’s the easy part. The hard work is orchestration. Knowing which projects need dual-agent review and which don’t. Crafting prompts that transfer full context between agents without losing signal. Understanding when Codex’s review contradicts Claude’s implementation — and deciding who’s right. Recognizing blind spots that both agents share.

This isn’t “AI writes my code for me.” This is a fundamentally different way of working — one where the architect’s role shifts from writing every line to orchestrating multiple intelligences, each seeing the problem from a different angle. The human becomes the conductor, not the soloist.

And the workflow isn’t fixed. Sometimes Codex reviews Claude’s PR. Sometimes Claude reviews Codex’s work. Sometimes I ask both agents to independently solve the same problem and compare approaches. The structure adapts to what the work demands. The only constant is that no single brain — human or AI — gets the final word alone.

Not Every Project

I don’t run this workflow on every repo. Review depth should reflect the change’s risk and complexity; a second provider is one possible review layer.

For complex domains, a separate review and a human check can expose mistakes the implementation pass missed. Different providers may still share blind spots, so agreement alone is not proof.

For straightforward work, review depth can scale with risk and complexity. A second agent is one option; meaningful tests and an accountable final check remain useful.

But when it matters? Three passes. Three perspectives. Then it ships.