← Selected work

Case study / Personal practice

Cross-Model Pair Programming

Harness Engineering Across Claude Code and Codex

My role

Designed it and use it

Engagement

Ongoing

Team

Claude Code (Opus) and Codex (Sol), with me on business logic

One task, two agents
  1. Claude Code on Opus drives. One session owns the task, starting from a reviewed spec.
  2. Codex on Sol navigates. It reads the code in a fresh context of its own.
  3. What it finds goes into map.md, and Claude Code builds from that.
  4. A choice the spec doesn’t cover comes to me as D1.
  5. Claude Code writes my answer into decisions.md, where Codex will read it too.
  6. v1 goes to Codex for review, in another fresh context, with the spec and decisions.md.
  7. Codex records F1 in the review ledger. Claude Code fixes it and sends v2.
  8. A new Codex context checks v2 and marks F1 verified.
  9. A clean result: no open findings, and the checks pass on v2.

Simplified, but the roles, files and rules are how I work.

01 Context

The work, at a glance.

I pair two AI agents from two providers on larger coding tasks. Claude Code on Opus drives: it owns the implementation. Codex on Sol navigates: it reads the code before the build and reviews it after, in a fresh context each time. The part I engineered is the harness around them: what each agent is told, what it can’t do, how its work is checked and how it gets corrected.

Claude CodeOpus 5.5CodexGPT-6.1 SolCLAUDE.mdmap.mddecisions.md

02 The challenge

What needed to change.

On a big codebase, working out what a change touches can take as long as making it. I was doing that investigation, the decisions and the review follow-ups in one conversation, or carrying them between chats myself, and things got lost.

  • I’d trace a request through a couple of services, read the tests and dig through the history in the same chat I was building in. On some changes I was compacting before the first edit.
  • Dead ends came along with the useful findings.
  • A choice about what the feature should do could hide inside a long plan I’d otherwise agreed with.
  • I’d answer a scope question, we’d carry on, and several steps later I’d have to find that answer again.
  • Review was a relay. A finding came back, I took it to the builder, waited for the fix, asked for another review and kept track of which version had been checked.

03 The approach

Decisions that moved it forward.

Claude Code and Codex are harnesses: each wraps a model with tools, context and permissions. My work is the layer around both. OpenAI and Anthropic both wrote about this harness engineering in 2026: the environment, context and feedback loops that make agents reliable. I split mine into four jobs: constrain, inform, verify and correct. Both tools now ship subagents, plan mode, hooks and code review. My CLAUDE.md decides how they work together across two providers.

01

Constrain: Who Can Do What

An agent with unclear limits makes decisions that aren’t its to make. Claude Code owns the implementation. Codex investigates and reviews, and never commits, pushes or posts. New business logic is the only thing that comes to me.

  • Opus settles most choices from the reviewed spec. A choice the spec doesn’t cover comes to me as a short question with options and a recommendation.
  • Say an export fails halfway. Should it retry on its own? Retrying means more behavior to build and test. Leaving it out keeps the feature smaller. I pick one and the work carries on.
  • I use the full setup when I expect a long investigation or several review rounds. A small edit in familiar code stays with Claude Code.
02

Inform: Context Built for the Next Step

Investigation fills a conversation with search history and dead ends. Chroma’s context rot research found models get less reliable as input grows, and both Claude Code and Codex now suggest moving exploration into a subagent. So investigation runs in its own Codex context and comes back as map.md, and Claude Code builds from conclusions instead of search history.

  • Every task starts from a spec a human has reviewed, plus the task definition and any extra context.
  • map.md covers how the code behaves today and what the change touches, with links into the code and tests. Anything Codex couldn’t confirm stays a question, and an inference is labelled as one.
  • decisions.md keeps each question with its current answer, like a lightweight decision record. It lives on disk, outside any context window, and every new session and reviewer is told to read it.
03

Verify: A Reviewer That Didn’t Write the Code

A model reviewing its own work can go easy on it. LLM evaluators have been shown to favor their own output (Panickssery et al., NeurIPS 2024), and Anthropic’s 2026 harness work found even a separate evaluator needs concrete criteria to stay skeptical. So the review comes from a model that didn’t write the code, in a fresh context, against a fixed version, with the checks spelled out.

  • Each round gets the exact version of the code, the expected behavior, the current decisions and the checks to run.
  • Codex runs the checks and brings in fresh reviewers each round. A finding can also turn out to be outside the agreed scope; the reason is recorded with its outcome.
  • A check that couldn’t run is marked incomplete. If an agent blames a failure on existing code, it has to reproduce it there first.
04

Correct: A Loop With a Stopping Rule

A review loop needs a defined end, or it stops too early or never stops. Every finding gets a recorded outcome, and the loop ends on one condition: independent review of the current change, no open blocking or should-fix findings, and required checks passing on that same version.

  • A finding goes back to Claude Code for a fix and a test, and the next round verifies it on the new version.
  • Later rounds often find a path the earlier ones missed, so review keeps looking past the known findings.
  • A clean result means review found nothing blocking, not that the code is bug-free.

04 The outcome

What the work made possible.

I can tell where a task stands without scrolling back through a chat.

Driver
Claude Code on Opus
Navigator
Codex on Sol, fresh context each time
Comes to me
New business logic
Done means
A clean review of the current code
  • Claude Code starts from the reviewed spec and map.md, without Codex’s dead ends.
  • Each question has one current answer that both agents can find.
  • Every review round ends with evidence I can inspect: the version checked, the findings and their outcomes, and the checks that ran.

Another story

AI Change Propagation for Compliance Content

Have something in mind?

Let’s build
something that matters.