Cross-Lineage Review in Practice

I put one line in the policy document.

No code change is complete until an agent of a DIFFERENT lineage than the
author has reviewed it and the findings are addressed.

Codex reviews code written by a Claude worker. deep-reasoner reviews code written by Codex. A review within the same lineage does not satisfy this rule, and the orchestrator reviewing its own work does not count either.

flowchart LR
  accTitle: Review path split by authoring lineage
  accDescr: When a Claude worker writes the code, Codex reviews it; when Codex writes it, deep-reasoner reviews it. When Codex is unavailable, deep-reasoner reviews instead and the deviation is recorded in the commit.
  TASK[Implementation task] --> WHO{Authoring lineage}
  WHO -->|Claude worker| RC[Codex review]
  WHO -->|Codex| RD[deep-reasoner review]
  RC -.Codex quota exhausted.-> FB[deep-reasoner fallback review<br/>deviation recorded in commit]
  RC --> FIX[Findings addressed]
  RD --> FIX
  FB --> FIX
  FIX --> DONE([Commit])
  SELF[Same-lineage self review] -.Not accepted.-> DONE

Review Sequence for the Thermal Feature

I applied this flow when I added thermal handling to a camera app. When the device gets hot, the feature lowers the preview frame rate and shows a banner.

deep-reasoner looked at the design first. The open questions were where to lower the frame rate and how to inject a thermal state in tests. This agent returns a decision and its reasoning without implementing it. We put the thermal decision inside the engine so it would also run in the simulator, which has no camera.

A worker took the implementation. Several files changed and nineteen tests were added. One bug surfaced at this stage. The code announced the initial thermal state only when camera setup succeeded, so on the simulator, which has no camera, the banner never appeared. I fixed it to emit the initial state first, regardless of camera availability. The simulator had already been considered during design, and the implementation still tripped in the same place.

After implementation, Codex performed cross-lineage review of the Claude worker’s code. I scoped the review to the entire pre-commit working-tree diff and passed along what to look for: threading discipline, places that diverge from the patterns in the existing code, whether the tests actually exercise the real execution path, and whether repository conventions were followed.

The review comes back as numbered findings with severities, plus a verdict on whether the change is safe to commit. I commit only after addressing the findings. In the final state, 541 tests passed, including the nineteen new ones.

Passing Along What to Look For

When I requested only “review this” without defining the scope, the response mostly contained a code summary and minor style comments.

Specifying the inspection points produced concrete findings. For the commit that fixed the preview freeze bug, I passed a list of items: whether stream creation and subscription happen atomically, whether the points that cross actor boundaries are safe, and whether a stale initialization could be suspended and then resumed and cancel a newer subscription. The last item was the race I actually suspected, and the reviewer flagged exactly that spot.

For high-risk changes I used a separate adversarial review. I asked an ordinary review to check the implementation against the requirement and an adversarial review to find failure and bypass paths. I attached it only to areas where errors are expensive: authentication, data loss, rollback, and races.

When Codex Is Unavailable

This rule rested on Codex being available. During operation the quota ran out. With no review possible, no commit was possible either.

Proceeding without review would have broken the rule, so I added a substitute reviewer. The policy now sends reviews that Codex would have handled to deep-reasoner. For adversarial reviews, it also receives a separate instruction to enumerate attack angles and challenge the author’s claims.

I attached conditions in exchange. The substitute reviewer must be a different context from the author. Any departure from the rule is recorded in the commit body. When quota returns, a follow-up review is proposed. And quota exhaustion is not a reason to turn on the kill switch.

When I waited until the quota ran out to choose a path, I reconsidered turning the rule off. After the fallback was written into the policy, I followed that procedure in the same situation.

When an Agent Offers to Review Itself

Late in the operation, Codex read the repository’s policy while handling a large implementation. It split the work across subagents, attached an internal independent review, and then reported this.

I'm delegating the implementation and independent cross-lineage review as
required by the repository's orchestration contract.

The report makes it appear that the policy’s required review is complete. Under the policy’s lineage definition, however, subagents created inside Codex all belong to Codex. The rule did not count an internal review by the same model as cross-lineage review, so another review was required.

So I added one more line to the policy. Even when the implementation model reports an internal review, a review from a lineage different from the author’s is obtained separately.

The Cost That Remains

Every code change carries one more review, so work finishes later. Each request also needs a clear scope and explicit risk areas; otherwise the response tends toward summaries and minor style comments.

In my work, an author rereading a change and a reviewer seeing it in a different context found different problems. The thermal feature omitted a simulator condition that the design had already considered. After that case, I treated the extra review time as the time needed to look for this kind of omission.