Session Isolation for Reviews

When Claude generates code and then reviews it in the same session, the review is compromised. The model still holds its own reasoning in context, so it tends to defend its choices instead of challenging them.

This is the same-session self-review anti-pattern. The author retains the rationale for every decision and rarely flags its own assumptions as suspect.

The exam principle is blunt: independent, fresh-instance review beats same-session self-review. In CI/CD, that means the reviewer should never share context with the generator.

A reviewer that starts from a blank context window approaches the diff like an outsider. It has no investment in why a function was written a certain way, so it evaluates the code on its merits alone.

• Generation context = the prompts, exploration, and reasoning that produced the code.
• Review context = just the code, the standards, and the review criteria.

Keeping these separate removes the confirmation bias that makes a self-review wave its own work through. Session isolation is the mechanism that enforces this separation in a pipeline.

Pipelines have no terminal to type into, so Claude Code must run in non-interactive (print) mode. Use -p (or --print) to pass a single prompt and get a single result back, then exit.

This is the foundation for an isolated review step: each invocation is a fresh process with its own clean context, completely separate from any generation step that ran earlier.

A CI step needs machine-readable results, not prose. Add --output-format json so the pipeline can parse findings and decide whether to pass or fail the build.

Pairing JSON output with a schema makes the result deterministic to consume: your gate script reads structured fields instead of grepping free text for words like "LGTM" or "done" — which is an anti-pattern.

The cleanest isolation pattern in CI/CD is to split generation and review into two separate Claude Code invocations. The generation job writes code; a later, independent -p job reviews it.

Because each invocation is its own process, the reviewer never inherits the generator's conversation history. This mirrors the multi-agent rule from the exam: subagents do not inherit a coordinator's history — context must be passed explicitly, never assumed.

It is tempting to --resume the generation session and ask it to review its own work. Don't. A resumed session carries the original reasoning back into context — that is exactly the self-review bias you want to avoid.

There is a second hazard: resumed tool results can be stale if the codebase changed since they were captured. Sometimes a fresh session seeded with a structured summary beats resuming a named session outright.

For unbiased review, default to a fresh session every time.

An isolated reviewer should receive a tight, relevant payload: the diff to inspect plus the standards to apply. Trim verbose tool output to the fields that matter — bloated context triggers the lost-in-the-middle effect, where the model attends to the start and end far more than the middle.

Keep the review criteria near the start or end of the prompt so they are not buried mid-context.

An isolated session has no shared assumptions to fall back on, so the criteria must be explicit. Precise rules dramatically cut false positives.

• Vague: "be more precise" — produces noisy, inconsistent flags.
• Explicit: "flag a comment only when it contradicts the code it describes" — produces actionable findings.

For CI reviews specifically, the goal is to minimize false positives — a reviewer that cries wolf gets ignored and erodes trust in the gate.

To make an isolated reviewer behave consistently across runs, add 2-4 targeted few-shot examples covering the ambiguous cases. The model generalizes from them — it doesn't just echo them back.

Few-shot is the right tool for consistency, edge cases, output format, and reducing hallucinated findings. A couple of well-chosen flag / do-not-flag examples align the reviewer's judgment with your team's bar.

Force the reviewer to emit a structured verdict via a tool and JSON Schema. Set tool_choice to "any" so the model must call a tool — this guarantees structured output instead of free prose.

Mark a field required only when it is always present. Never require a possibly-absent field, or the model will fabricate a value. Use an enum with an "other" option plus a free-text detail field so new finding types stay representable.

When a pull request is updated and the review re-runs, a fresh session would re-flag everything from scratch — including already-acknowledged items. That creates noise.

The exam pattern: when re-running, include the prior results and report only new or still-unfixed issues. You preserve session isolation (still a clean reviewer) while passing the prior findings in explicitly as input — context handed over deliberately, not inherited from a resumed generation session.

Test your grasp of the core decision behind isolated reviews.

Key takeaways for session-isolated reviews in CI/CD:

• Fresh instance beats self-review — the author defends its own work; an outsider doesn't.
• Separate processes — review with a distinct claude -p invocation; never --resume the generation session for review.
• Non-interactive + JSON — -p with --output-format json gives clean context and parseable results; never grep text for completion signals.
• Explicit criteria + 2-4 few-shot examples minimize false positives and keep verdicts consistent.
• tool_choice "any" forces structured output; require only always-present fields.
• On re-runs, pass prior findings explicitly and report only new or unfixed issues.
• Never route blocking pre-merge reviews through the Batch API.