Skip to content
Cheat sheets

CCAR-F · Domain 4: Prompt Engineering & Structured Output · 20% of the exam

Task 4.6: Design multi-instance and multi-pass review architectures

Why a fresh instance reviews better than the session that wrote the code, per-file passes plus a cross-file integration pass, and confidence scores that route findings to the right reviewer.

Study it

  • Independent reviewers and multi-pass reviews

    Partly covered by: LLM as a Judge

Sample questions

Try each one before opening the answer. Every option is explained, with the Anthropic documentation page that proves it.

Question 1 · choose 1

In your pipeline, the same Claude Code session that generates a fix is then asked to review it before the pull request opens. Reviews almost never find problems, but human reviewers keep catching subtle issues. What change makes the automated review more effective?

  1. AKeep the review in the same session but tell Claude to be highly critical of the code it just wrote
  2. BHave the same session review the change twice and keep only the findings that both passes report
  3. CRun the review in a separate Claude instance that has the diff but not the generating session
  4. DTurn on extended thinking so the generating session's self-review goes deeper
Show the answer and why

  • AKeep the review in the same session but tell Claude to be highly critical of the code it just wrote

    Incorrect

    The session still carries the reasoning that produced the code and tends to defend it.

  • BHave the same session review the change twice and keep only the findings that both passes report

    Incorrect

    Two passes with the same context tend to agree with each other and filter out the findings you want.

  • CRun the review in a separate Claude instance that has the diff but not the generating session

    Correct

    A fresh context is not anchored to the decisions it just made, so it is more likely to question them.

  • DTurn on extended thinking so the generating session's self-review goes deeper

    Incorrect

    More reasoning in the same context does not remove the bias toward its own earlier decisions.

Self-review is weak because the model keeps the reasoning that produced the code. An independent instance without that context catches issues the generator overlooks.

Anthropic documentation

Task 4.6Report a problem with this question

Question 2 · choose 1

A pull request touches 30 files: it changes the signature of a shared pricing function and updates some of its callers. Your single-pass review gives thorough comments on a few files, only skims the rest, and misses callers that were not updated. Which review design fixes both problems?

  1. AReview each file on its own for local issues, then run a separate cross-file integration pass
  2. BKeep one pass but ask it to list every file it reviewed with a one-line verdict before it finishes
  3. CKeep one pass but put the pricing function's new signature at the top of the prompt as a reminder
  4. DReview only the changed lines in each file so that every prompt stays short and the attention stays on what moved
Show the answer and why

  • AReview each file on its own for local issues, then run a separate cross-file integration pass

    Correct

    Per-file passes keep attention even across files, and the integration pass looks specifically at how changes flow between them.

  • BKeep one pass but ask it to list every file it reviewed with a one-line verdict before it finishes

    Incorrect

    A checklist of files is not attention: the single pass still skims most of them and can still miss the callers.

  • CKeep one pass but put the pricing function's new signature at the top of the prompt as a reminder

    Incorrect

    A reminder does not change that one pass spreads its attention across 30 files; the missed callers need a dedicated cross-file check.

  • DReview only the changed lines in each file so that every prompt stays short and the attention stays on what moved

    Incorrect

    Unchanged callers are exactly what is missed; looking only at changed lines makes that worse.

Split large reviews: focused per-file passes for local issues plus a dedicated integration pass for cross-file data flow. Each call then has a narrower job, which avoids attention dilution and contradictory findings.

Anthropic documentation

Task 4.6Report a problem with this question

Question 3 · choose 1

Your multi-pass review (per-concern finder passes, a verification pass and an integration pass) catches far more than a single pass, but it is expensive. Most of your repositories are documentation and internal tools, and two are payment services. How should you apply it?

  1. AScale the depth to the risk: a lighter review for the routine repositories and the full multi-pass review for the payment services
  2. BRun the full review everywhere but drop the verification pass to save cost
  3. CRun the full review once a week across all merged pull requests
  4. DLet authors request the full review when they think their change needs it
Show the answer and why

  • AScale the depth to the risk: a lighter review for the routine repositories and the full multi-pass review for the payment services

    Correct

    Review depth is a cost trade-off; Anthropic's own Code Review offers lighter and deeper levels per repository for exactly this reason.

  • BRun the full review everywhere but drop the verification pass to save cost

    Incorrect

    Without verification, more false positives reach developers in every repository, including the critical ones.

  • CRun the full review once a week across all merged pull requests

    Incorrect

    A weekly review after merge finds problems only once they are already in the main branch.

  • DLet authors request the full review when they think their change needs it

    Incorrect

    This relies on each author judging the risk of their own change, so payment changes can go unreviewed.

Multi-pass review costs more per pull request. Match the depth to the risk of the code: a quick pass where problems are cheap, the most thorough review where a missed bug is expensive.

Anthropic documentation

Task 4.6Report a problem with this question

Question 4 · choose 1

Your per-file passes sometimes report the same underlying problem in five files, and developers get five near-identical comments. How should the pipeline handle this?

  1. AStop running per-file passes
  2. BAdd a final pass that merges duplicate findings
  3. CPost only the first finding and drop the others silently
  4. DAsk each per-file pass to guess what the others found
Show the answer and why

  • AStop running per-file passes

    Incorrect

    The duplicates come from how findings are posted, not from the passes.

  • BAdd a final pass that merges duplicate findings

    Correct

    A consolidation step keeps the per-file depth while avoiding repeated noise.

  • CPost only the first finding and drop the others silently

    Incorrect

    Dropping occurrences hides where else the problem appears.

  • DAsk each per-file pass to guess what the others found

    Incorrect

    Passes cannot see each other.

Multi-pass reviews benefit from a final step that consolidates findings across passes, so developers get one clear comment per issue.

Anthropic documentation

Task 4.6Report a problem with this question

Question 5 · choose 1

Your per-file passes flag a pattern as a problem in one file and accept the same pattern in another. Each pass was given slightly different instructions, assembled on the fly. What should you fix first?

  1. AUse the same criteria for every pass
  2. BMerge all files back into a single pass
  3. CLet developers decide which pass to trust
  4. DRandomize which instructions each pass receives
Show the answer and why

  • AUse the same criteria for every pass

    Correct

    Identical criteria are the basis for consistent decisions across passes.

  • BMerge all files back into a single pass

    Incorrect

    That discards the passes instead of fixing their criteria.

  • CLet developers decide which pass to trust

    Incorrect

    This pushes the inconsistency onto developers.

  • DRandomize which instructions each pass receives

    Incorrect

    Randomness makes consistency worse.

Per-file passes need one shared set of criteria; otherwise splitting the review produces contradictory findings.

Anthropic documentation

Task 4.6Report a problem with this question

Question 6 · choose 1

Your automated reviewer is given only each pull request's diff. It misses bugs where a changed helper's new behavior breaks code that the diff does not show, such as other functions in the same module that rely on the helper's old contract. What should change?

  1. AGive the reviewer a longer checklist that asks it to look for broken contracts
  2. BAsk authors to split pull requests so that each diff contains everything it touches
  3. CLet the reviewer read the surrounding code of each change, with read-only tools, not only the diff
  4. DRun the same diff-only reviewer twice and merge the results
Show the answer and why

  • AGive the reviewer a longer checklist that asks it to look for broken contracts

    Incorrect

    A checklist cannot make the reviewer see code that is not in front of it; the functions that rely on the helper stay outside the diff.

  • BAsk authors to split pull requests so that each diff contains everything it touches

    Incorrect

    This shifts the burden to developers and still leaves dependencies outside the diff unseen.

  • CLet the reviewer read the surrounding code of each change, with read-only tools, not only the diff

    Correct

    Reviewing a change alongside the surrounding code is how the reviewer sees what depends on the helper's old behavior.

  • DRun the same diff-only reviewer twice and merge the results

    Incorrect

    Two passes over the same diff share the same blind spot.

A reviewer that sees only the diff cannot judge what a change does to code outside it. Anthropic's Code Review has its agents read each change alongside the surrounding code; give your reviewer read-only access to the code around each change.

Anthropic documentation

Task 4.6Report a problem with this question

Practise domain 4 →Practise all domains →