The Two-Pass Review Workflow

Review used to be one activity because one person could carry both jobs: checking correctness and judging quality. AI volume split those jobs apart. Telemetry across 10,000+ developers reported an association between high AI use, more merged PRs, and longer review time in a third-party 2026 summary; it does not establish that AI caused either outcome, and 38% of developers finding AI code harder to review than a colleague’s. When the same scarce minutes must carry style nits, type errors, scope checks, and architecture judgment, the mechanical work crowds out the judgment - which is the part humans were actually needed for.

JetBrains’ engineering blog states the fix bluntly: stop sending machine-catchable errors to human review at all. The two-pass workflow is that principle, systematized.

Where the boundary between the two jobs runs - what review is for and what verification actually covers - is laid out in code review vs. verification.

Pass one runs on every push, as a required status check - nothing reaches a human that failed it:

1. Deterministic gates. Formatting, lint, types, build, and the test suite - including tests written before the run, so the generating model did not author its own judge. Whether those gates actually ran, rather than being reported as run, is its own record: the exit codes observed per command.
2. Boundary check. The diff compared against the declared task boundaries - files and behavior that must not change. Off-scope edits fail the pass.
3. Spec comparison. The spec-vs-implementation check against the task’s acceptance criteria, with the outcome recorded.
4. Optional: AI pre-review as hypothesis filter. An AI reviewer flags likely issues across the diff. Cloudflare’s orchestration documents one production implementation at scale. It is an operational example, not evidence that the same design will improve every team - and its output remains a screening signal, never the verdict.

The reviewer receives the diff plus the pass-one results: what was checked, what passed, what was skipped. The job changes from reconstructing intent to exercising judgment - is this the right approach, does it fit the architecture, should this exist at all. The clean division:

• Alibi automation. A green pass-one badge is an input to review, not a substitute for it. If approvals become reflexive, the workflow has failed quietly.
• Noisy pre-review. An AI reviewer that cries wolf trains the team to ignore pass one entirely. Tune for precision over recall; deterministic gates carry the authority.
• No written intent. Without a task specification, pass one shrinks to style and tests - real value, but the strongest checks (boundaries, criteria) need a written Soll.
• Treating pass one as optional. A pre-check that can be skipped under deadline pressure will be - required status checks exist for a reason.

These sources describe particular surveys, products, and operating contexts as retrieved in July 2026. A passing first pass proves only that the declared checks passed; it does not prove correctness, suitability, approval, or release readiness. A human decision must interpret the evidence and residual risk before merge or deployment.

Reality Graph is a structured pass one with intent: task boundaries and acceptance criteria defined before the run, the diff checked against them after it, validation the model did not author, and an evidence report as the hand-off artifact into pass two - the missing piece between generic CI checks and the human reviewer, inside the broader verification loop.