Cross-Family Code Review: An Operational Control Without Comparative Evidence

Cross-family code review separates implementation from review. This article sets out what that separation controls, what evidence reviewers need and how to test whether it detects more defects than same-family review. The available evidence does not establish that advantage.

A model reviewing its own output may preserve assumptions made during implementation. A misunderstood business rule, unsuitable abstraction or missed edge case can survive a second pass. Another model family introduces a different perspective, but difference does not prove independence or correctness.

Cross-family review creates useful disagreement, but its advantage over same-family review remains unproven.

Undated routing snapshot

The documented workflow assigns implementation and code review to different model families.

Risk level	Implementation	Code review
LOW	gpt-5.6-sol	claude-sonnet-5
STANDARD	claude-sonnet-5	gpt-5.3-codex
HIGH	claude-sonnet-5	gpt-5.6-sol
CRITICAL_FINANCIAL	claude-opus-5	gpt-5.6-sol

Other responsibilities are assigned as follows:

• gpt-5.3-codex challenges plans for LOW, STANDARD and HIGH-risk work.
• gpt-5.6-sol challenges plans for CRITICAL_FINANCIAL work.
• gemini-3.1-pro provides visual review for UI work.
• claude-opus-5 performs verification at every risk level and handles escalation where required.

Plan challenge, implementation, code review and verification remain separate controls. Each examines an artefact it did not produce.

This table has no effective date or model-version context. It should therefore be treated as an undated operational snapshot, not a durable routing specification.

Evidence available to reviewers

A different model name is not enough. Reviewers need explicit business rules, repository context and reproducible checks to distinguish defects from intentional constraints.

The described repository readiness checks cover:

• pinned runtimes;
• lockfiles;
• architecture maps;
• testing guidance;
• common failures;
• one-command validation.

These controls provide observable conditions against which to assess a change. A failing test, inconsistent business rule or missing validation path gives a firmer basis for a finding than a preference about naming, formatting or architecture.

The supplied material does not include reviewer prompts, context packages, tool permissions or deterministic validation commands. It also omits the risk taxonomy, classification procedure, fallback behaviour, escalation criteria and severity calibration.

Limits of the reported evidence

The internal measures cover first-pass performance, readiness checks, approved-plan coverage, agent-tool support, default-branch protection and finding severity. Their reported rates are omitted here because the material does not provide the underlying counts, denominators, definitions or collection dates.

These measures describe parts of the current process. They cannot test whether cross-family review performs better than same-family review.

The material also lacks:

• a defined repository and change population;
• inclusion and exclusion criteria;
• finding-level audit records;
• false-positive, disagreement and override rates;
• escaped-defect rates;
• a controlled same-family versus cross-family comparison;
• an end-to-end case linking a change, finding, correction and verification result.

Agreement between reviewers does not establish correctness. Model families may also share training patterns. Neither model naming nor reviewer agreement is a substitute for adjudicated outcomes.

Comparative evaluation

The experimental unit should be one eligible code change reviewed under both defined conditions, or assigned to one condition through a recorded allocation procedure. Where the same repository or model contributes multiple changes or review runs, those observations must not be treated as independent.

Equivalent review conditions require the same:

• code change or matched change criteria;
• business requirements;
• repository state and context;
• reviewer instructions;
• tool permissions;
• deterministic checks;
• time and execution limits;
• finding format;
• adjudication criteria.

Model identity should be removed from finding records before adjudication where practical. Reviewers should not see findings from the other condition before submitting their own.

Outcome records

Outcome	Required evidence	Adjudication requirement
Accepted defect	Finding linked to the change and supporting rule, test or check	Confirm defect and severity
Rejected finding	Finding linked to the change and contrary evidence	Record rejection reason
Overridden finding	Original finding and authorised override evidence	Record decision owner and rationale
Duplicate finding	Links to findings describing the same defect	Identify the retained record
Deterministic-check finding	Reproducible command and observed result	Confirm that the check establishes the defect
Model-only finding	Finding without a decisive deterministic check	Assess against requirements and repository evidence
Escaped defect	Later defect record linked to the reviewed change	Reassess the earlier review outcome

Severity levels and consequential-defect criteria need to be defined before collection starts. Style preferences and other non-blocking observations should remain separate from correctness defects.

Statistical analysis

Sample size should be determined from the comparison being tested, the outcome rate of interest and the required precision. The source material does not provide the inputs needed to calculate it.

Analysis should account for clustered observations when repositories, changes or models contribute repeated results. Confidence intervals should accompany comparative rates. If multiple model runs are used, the protocol should define how run-to-run variation is recorded and whether results are combined or reported separately.

The analysis should also distinguish a planned primary comparison from secondary measures. False positives, escaped defects, disagreements and overrides should be reported separately rather than combined into one success rate.

What this means

Cross-family review provides operational separation, but the current material does not establish an advantage over same-family review. A valid comparison requires defined review conditions, auditable adjudication and analysis that accounts for repeated observations.

---

Originally published at AFT Group Engineering Insights.