Più passaggi e revisione indipendente

You ask Claude to generate a function, then ask the same conversation to review it. It says "looks good." Why? Because the author already holds its own reasoning in context — it agrees with itself.

This is same-session self-review, and it is a classic anti-pattern. The model that wrote the code will not genuinely challenge it; it rationalizes the choices it just made.

The fix is independent review: a fresh instance, with no memory of the generation, inspects the output cold. A fresh pair of eyes finds issues the author misses.

A same-session reviewer is biased by the generation context: the justifications, assumptions, and shortcuts it already committed to are still in the message history.

An independent instance receives only the artifact (and the rules), not the author's internal narrative. It evaluates what is actually there, not what the author intended.

• Author retains reasoning → won't dispute itself.
• Fresh instance → no sunk-cost loyalty → real scrutiny.

Rule of thumb: independent / fresh-instance review beats same-session self-review.

To run an independent review, start a new request with fresh messages — do not append to the generation history. Pass only the artifact and explicit review criteria.

Notice: no prior assistant turns, no "here's why I wrote it this way." The reviewer sees the code as a stranger would.

"Be more precise" tells the reviewer nothing. Explicit criteria beat vague instructions.

Give the reviewer concrete, testable rules so its findings are reproducible and low-noise:

• Vague: "review carefully."
• Explicit: "flag a comment ONLY when it contradicts the code."

Precise criteria are what separate a reviewer that surfaces real defects from one that floods you with style nitpicks and false positives.

A single pass that tries to check everything at once dilutes attention — the model spreads thin and misses defects.

Better: run multiple focused passes, each with a narrow mandate. One pass for security, one for correctness, one for the public API contract. Each pass attends fully to its lens.

This is the same principle behind multi-pass code review: separating concerns sharpens the model's focus on each one.

For a multi-file change, do NOT review every file in one giant single pass — that dilutes attention across files.

Use a two-stage structure:

• Local pass: review each file on its own for internal correctness.
• Integration pass: a separate pass over how the files fit together — call sites, shared types, contract mismatches.

Single-pass multi-file review is an anti-pattern. Per-file local passes plus a dedicated cross-file integration pass catch what either alone would miss.

In a pipeline, run the review in an isolated session — separate from whatever generated the change. The isolated reviewer is less biased by the generation context, so it produces fewer rubber-stamps and fewer false positives.

Use non-interactive mode and a parseable format so the pipeline can act on results.

Reviews iterate. When you re-run a review after the author fixes some findings, do not start blind — and do not re-report everything.

Include the prior results in the new run and instruct the reviewer to report only new or still-unfixed issues. This keeps each iteration signal-rich instead of repeating noise the team already triaged.

A wall of review prose is hard to gate on. Force the reviewer to emit structured output so the pipeline can route each finding deterministically.

Use tool_choice set to "any" to guarantee the model returns a tool call (structured JSON) rather than free text. Mark a field required ONLY if it is always present — never require an optional field, or the model will fabricate it.

Independent review is not the same as a validation retry. Know which tool fits which problem.

• Retry-with-feedback fixes format, structural, or arithmetic errors: send the original input, the wrong output, and the exact validation error so the model corrects itself.
• Independent review catches judgment defects: contradicted assumptions, missed edge cases, contract drift — things a validator can't express as a schema rule.

Neither helps when information is simply absent from the source. A retry can't conjure a value that was never there; a reviewer can only flag the gap.

When you reopen a review, beware stale context. Resuming a named session with --resume brings back old tool results — but if the codebase changed since, those results may be stale and the review wrong.

Often a fresh session with a structured summary of the current state beats a resumed one. The fresh instance reads the code as it is now, with no outdated baggage — exactly the independence advantage that makes fresh review powerful.

An architect has Claude generate a 6-file refactor. To validate it before merge, which review setup is strongest?

Key takeaways for multi-pass and independent review:

• Fresh beats self: independent / fresh-instance review beats same-session self-review — the author won't challenge its own reasoning.
• Run it isolated: in CI/CD, review in an isolated session for less bias and fewer false positives; use -p and --output-format json.
• Multi-pass: one lens per pass; for multi-file changes do per-file local passes THEN a separate cross-file integration pass. Single-pass multi-file dilutes attention.
• Explicit criteria ("flag X only when Y") beat vague ones.
• Re-runs: include prior results, report only new or unfixed issues.
• Right tool: retry-with-feedback fixes format/arithmetic errors; review catches judgment defects; neither invents absent info.