Is Changing Session, Skill, or Model the Same? Why Claude Code’s Self‑Review Fails

The author observes that Claude Code writes code well but cannot reliably review its own output because the model retains the original writing context, leading to a false sense of security. This mirrors human code review, where the author’s bias can hide subtle bugs.

Four proposed actions—starting a new session, switching a review Skill, changing the model, and employing Sub‑Agent or Worktree—target four separate issues: context pollution, review perspective, model‑specific blind spots, and task isolation. They operate on different layers and cannot replace each other.

New session clears the accumulated context so the model evaluates code without prior affirmations. It works for minor edits, copy‑editing, or simple bug checks but cannot overcome the model’s inherent blind spots, making it unsuitable for high‑risk logic changes.

Switching Skill replaces the review checklist, forcing the model to examine aspects such as null handling, permission checks, rollback behavior, test coverage, performance, and data consistency. While it broadens the inspection scope, it cannot address blind spots not covered by the checklist because the underlying model remains unchanged.

Changing model introduces a heterogeneous perspective. For example, using Codex to review Claude‑generated code uncovered a pagination edge‑case where an extra request for an empty page would be issued—something Claude missed. However, this incurs higher token costs, slower responses, and potential opinion conflicts between models.

The author also distinguishes genuine multi‑Agent setups from pseudo‑multi‑Agent configurations. True multi‑Agent requires distinct roles, isolated contexts, separate checklists, and verifiable handoffs; merely naming multiple agents without these properties yields no real benefit.

Sub‑Agent splits a large task into isolated contexts, while Worktree isolates file‑level changes, preventing contamination of the main branch. Neither guarantees better review quality if the same model and checklist are used.

Based on risk levels, the author proposes a tiered review process: small changes get a quick self‑check; medium changes use a new session plus a specialized Skill; critical logic combines new sessions, cross‑model review, and isolated Worktree execution; high‑risk operations (e.g., data‑writes) add full testing, cross‑review, and manual final approval.

The key takeaway is that AI‑assisted development succeeds when the workflow—not any single tool—is robust, with clear inputs, outputs, verification steps, and rollback plans, allowing seamless substitution of models or agents when needed.