- In short
- Claude Code incremental review is the practice of including the previous review findings in the context of each re-run so Claude reports only new or still-unaddressed issues. It prevents a review that re-runs on every commit from re-posting comments developers have already handled, which is what keeps the feedback trustworthy enough to act on.
What Claude Code incremental review is
Claude Code incremental review is what you do when a review runs more than once on the same pull request. On a long-lived PR, code changes commit by commit, and many teams trigger a fresh review on every push. The naive version of that re-runs the review with a clean slate each time, which means it re-discovers and re-posts every issue it found before, including the ones already fixed or explained. Incremental review fixes this by feeding the prior review findings into each new run and instructing Claude to report only what is new or still unaddressed. The reviewer still examines the latest state of the code, but it now knows what has already been said.
The distinction matters because the two failure modes pull in opposite directions. The previous knowledge point warned against sharing the generation context with the reviewer. This one says the reviewer should share the review context across rounds. Those are not in tension: independence is about not defending the author's decisions, while incrementality is about not repeating the reviewer's own earlier comments. A good CI reviewer is independent of how the code was written and aware of how the review has unfolded.
- Incremental review
- Re-running a review with the prior findings supplied as context, and instructing the model to surface only new or still-unaddressed issues, so successive reviews on an evolving pull request converge instead of repeating themselves.
Why duplicate comments are so damaging
It is tempting to treat duplicate comments as harmless clutter. They are not. Code review is a trust relationship, and trust is fragile. The first time a reviewer re-posts a comment the author already resolved, the author shrugs. The third time, they start skimming. By the fifth, they have learned that the reviewer does not track what they have done, and they begin ignoring all of its feedback, including the genuinely new, genuinely important finding buried in the repetition. A reviewer that cries wolf about settled issues trains the team to stop listening, which defeats the entire purpose of automating the review.
This is why incremental review is framed as an applied skill rather than a nice-to-have. The goal of CI review is to change behaviour: to get real bugs fixed before merge. A reviewer that floods the PR with stale comments fails at that goal no matter how accurate any single comment is. Preventing duplication is therefore not polish; it is what makes the whole mechanism usable on a real, evolving pull request.
How you supply the prior context
There are two practical ways to give a re-run the history it needs. The first is to continue the same review conversation rather than starting cold: Claude Code supports --continue to pick up the most recent conversation and --resume with a session ID to continue a specific one. If you captured the session ID from the first review's JSON output, you can resume exactly that thread so the model already remembers what it raised. The second is to pass the prior findings explicitly, for example, reading them from a stored artefact and including them in the prompt, and instruct the model to report only issues that are new or not yet addressed. Either way, the operative move is the same: the new run is anchored by the old findings.
Anthropic's managed Code Review encodes the same idea. With after-every-push reviews, it catches new issues as the PR evolves and auto-resolves threads when you fix the flagged issue, so a resolved comment does not keep reappearing. The docs even suggest a review instruction like "after the first review, suppress new nits and post Important findings only", which is convergence behaviour expressed as policy: as a PR matures, the reviewer should get quieter about small stuff and reserve fresh comments for what genuinely matters. Whether you build the loop yourself or use the managed service, the contract is identical, feed the history forward and ask for deltas, not a full re-list.
Where incremental review sits in the workflow
Incremental review only becomes relevant once two earlier pieces are in place. You need headless invocation so the review runs unattended on each push, and you benefit from structured output so the prior findings are stored in a parseable form you can feed back in. It also assumes the reviewer is independent of the author in the sense of the previous concept. Stack those together and you get a reviewer that runs on every commit, judges the latest code without authorship bias, and speaks up only about what has changed or remains open. That combination is what a mature CI review feels like from the developer's seat: present, but never noisy.
Resuming a session versus replaying the findings
The two ways to carry history forward are not interchangeable, and knowing their trade-offs is the applied core of this concept. Resuming a session keeps the reviewer's own prior reasoning intact: you capture the session_id from the first review's JSON output, then continue that exact thread with --resume, or pick up the most recent conversation with --continue. The model already remembers what it raised and why, so the delta it reports is grounded in its earlier analysis rather than re-derived from scratch. The cost is coupling. You depend on that session remaining available, and you are continuing one specific conversation rather than re-examining the latest code from a clean footing.
Replaying the findings is the more explicit alternative. Here you store the previous findings as an artefact, often the structured JSON from the earlier run, and inject them into a fresh prompt with an instruction to report only issues that are new or still unaddressed. The reviewer starts without the prior session but is handed its conclusions as data. This keeps each run self-contained and storage-backed, which suits a pipeline that cannot guarantee a session survives between jobs on ephemeral runners. Either way the operative instruction is identical: here is what was already raised, report only the deltas. The choice is about how you transport that context across runs, not whether you supply it, and a run that supplies nothing is the duplication bug by construction.
Convergence as policy with REVIEW.md
The managed Code Review encodes incrementality as written policy rather than per-run plumbing. A repository can carry a REVIEW.md whose contents are injected into every review agent as the highest-priority instruction block, ahead of the default review guidance. Anthropic lists re-review convergence among the behaviours teams tune there: a rule that tells the reviewer, once a pull request has already been reviewed, to hold back fresh nits and raise only the issues that genuinely matter. That is incremental review expressed as behaviour, as a pull request matures, the reviewer grows quieter about small stuff and reserves new comments for what is important, so a trivial later fix never drags a thread to its seventh round on style alone.
Teams reach for the same file to cap how many nits a single review posts and to redefine what severity even means for their repository, all of which serve convergence: a review that stays loud about settled or low-value issues is the exact failure this knowledge point guards against. Paired with after-every-push reviews, the managed service also auto-resolves a thread once you fix the flagged issue, so a resolved comment stops reappearing without anyone marking it by hand. Whether you express convergence as a REVIEW.md rule or build the resume-and-delta loop yourself, the contract is identical: feed the review history forward and ask for what changed, never a fresh full re-list of everything.
How this knowledge point is tested
Scenario 5 items for this concept usually describe the symptom of the missing technique: a push-triggered review that keeps re-posting the same comments, developers losing patience, and a request for the right fix. The tempting wrong answers reduce the volume of reviews or hide the duplicates, review less often, post a single summary, disable inline comments. A particularly sharp distractor recommends running each review in a brand-new session with no memory, which is the exact opposite of the answer and is dressed up to sound like good hygiene. The correct response is to carry the prior findings forward and ask for only new or unaddressed issues. Watch for that inverted distractor; distinguishing "independent of authorship" from "amnesiac about prior reviews" is the precise understanding this question tests.
Worked example
A push-triggered review runs on every commit of a long-lived PR and keeps re-posting comments developers already addressed.
A feature branch has been open for two weeks. The team configured Claude to review after every push, which felt thorough. By the fifth commit the PR has the same three comments posted five times each. Two of the three issues were fixed on commit two; the third the author replied to with a justification the team accepted. None of that registered. The author has stopped reading Claude's comments altogether, and nobody notices when the sixth review raises a genuine new null-dereference.
The fix is to make each review aware of the last one. When the first review runs, its findings are captured from the JSON output along with the session ID. On the next push, instead of a cold run, the pipeline resumes that session (or includes the stored findings in the prompt) and instructs: "here are the prior findings; report only issues that are new or still unaddressed in the current diff". Now the second review sees that two issues are resolved and one was explained, says nothing about them, and posts only the new null-dereference.
The behavioural change is immediate. The PR no longer accumulates repeated comments, so when a new comment appears it means something, and the author reads it. Crucially, the reviewer did not become less rigorous. It still examined the whole current diff. It simply stopped repeating itself, which is the difference between a reviewer the team trusts and one it has learned to mute.
Misconceptions worth pinning down
The two traps below are the inverse-fix and the volume-fix that the exam likes to offer.
Misconception
To keep reviews fair, each re-review should run in a completely fresh session with no memory of earlier rounds.
What's actually true
Misconception
Duplicate comments are just noise, so reviewing less often or posting one summary comment is an adequate fix.
What's actually true
Misconception
With managed Code Review I have to mark each thread resolved by hand once I fix the issue it flagged.
What's actually true
A push-triggered review runs on every commit of a long-lived PR. By the fifth commit, developers complain that Claude keeps re-posting the same three comments they already addressed, and they have started ignoring all of its feedback. What should you change?
People also ask
How does incremental review work in CI?
Should each review run in a fresh session?
How do I stop Claude reposting the same review comments?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Anthropic's NEW Claude Code Review Agent (Full Open Source Workflow)
Why watch: Shows the open-source review workflow that explicitly checks prior PR comments and deduplicates findings so re-runs surface only new or still-unaddressed issues rather than re-posting duplicates that erode developer trust.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.