Code review with Claude Opus 5.5: a prompt to find bugs before merging

The revision of the code is the use case where Claude Opus 5.5 gives the most surprising result, and not for the maximum level of effort: Anthropic reports that a first user has seen Opus 5.5 at the lowest effort level find more bugs than Opus 5 at the top level, with fewer false alarms. If it is also true about your code — and it occurs in one afternoon — the pre-merge revision becomes a pass at almost no cost.

The method lies all in one prompt, that of the official guide, and one rule: each report must tell how to make the code fail. Verified data on 23 September 2026.

The official prompt, line by line

Translated from Anthropic's guide:

"Review the diff of this branch over main. Only list the problems you would block the merge for. For each one, give me the file and line, why it's wrong, and how to prove it fails."

The last line is the one that separates this revision from a generic comment. If the model fails to tell how the problem reproduces, reporting is not a bug: it's an opinion, and treat her as such.

Why Low Effort Level Can Be Enough

Opus 5.5 has five levels of reasoning, from low to max, and the default is medium. The instinct says: to find bugs you need the maximum. The data reported by Anthropic says the opposite for the revision: at the lowest level found more bugs than Opus 5 at the high level, with fewer false positives.

The plausible explanation is that reviewing a diff is a task of attention, not deep reasoning: reading well every line counts more than thinking long. The high level serves when the bug is in the interaction between distant parts of the system, not in the wrong line.

The economic consequence is that the pre-merge review becomes almost free: low level, short prompt, limited diff. How they set up and what they cost the levels is in the reasoning levels of Opus 5.5.

The four-step method

1. First passed to low level with the official prompt. Get a short list of reports, each with its own demonstration.
2. Test the demonstrations: in Claude Code the model can run the test it proposes; in the app you run it. What does not fail as described is discarded.
3. Second pass at high level only if needed: when the diff touches distributed logic, competition, or distant parts between them.
4. Human review of what remains: architecture, readability, product choices. Things that a test does not measure.

What to ask and what not to ask

A separate case is the description of the pull request: Opus 5.5 explains its changes in plain language, and Anthropic points it out as one of the differences from Opus 5. Ask it to write it down: "Describe what changes this diff and why, so that those who haven't seen the code can decide whether to approve."

Turning reports into tests

The value of a revision is not in the list: it is in what you do with it. Each verified report already contains the raw material of a test, because the prompt asked "how to prove that it fails": that input, that sequence, that limit case.

1. Take the demonstration proposed by the model — the amount with three decimal places, the empty field, the request repeated twice.
2. Ask for the test: "Write a test that reproduces this problem and that today fails." In Claude Code the model performs it and confirms that it fails.
3. Correct, and ask to rerun: the test must pass, and the rest of the suite also.
4. Leave the test in the repository. That's how the bug doesn't come back, and that's how the suite grows on real cases instead of imagined ones.

In a month this cycle produces a suite that covers exactly the errors your code tends to make, not the ones in the manuals. For setting up work in Claude Code — stop rules, file checklists, subs — see Opus 5.5 in Claude Code; to understand why the low level can suffice and what it costs to raise it, the levels of reasoning.

Verification of reports remains necessary in specialised services as well. Anthropic OSS Scanner for open source maintainers produces results to be confirmed: availability is selective and a raw report is not yet a proven vulnerability.

Non-your own code revision

A frequent case in SMEs: the provider delivers a form, or a freelancer leaves a project, and no one in the company is able to judge it. The review prompt also works here, with a change: instead of the diff over main, the perimeter is the whole module, and the request is added "also report anything that depends on external services, credentials or configurations that I don't see".

The result is not a judgment on the quality of the supplier. It's a list of concrete things to ask before acceptance: that value written in the code, that call without error management, that test that's missing. Those who do not program can take it to a meeting, as explained in Claude for the code.

Practical examples

Software house, 8 developers, Bologna. Pull request of 600 lines on a billing form. First passed to low level: four reports, three with reproducible test, one without (discarded). One of the three was a wrong rounding of the totals with VAT: the test proposed by the model was an amount with three decimal places. Total time: twelve minutes, including ten to run tests.

Single developer, tailor-made e-commerce, Rimini. Use the prompt in the app by pasting the diff before each deployment, because it doesn't work in Claude Code. The model cannot perform the tests, but the "how to prove it fails" request still produces the exact input to try. He stopped asking for "find errors" —which returned twenty style observations —and only asks for blockers.

Checks before and after a change

If the rule must prevent a writing, the guide to PreToolUse and protected files explains the check before the tool. For feedback on a change that has already happened, PostToolUse with formatter and test deals with order and execution. Before conclusion, one Stop hook with conditions and limits can collect a proof: none of these steps replace the diff review.

Mistakes to Avoid

• Asking for all comments. The two real bugs disappear among the twenty preferences.
• Accepting reports without demonstration. Without a way to make it fail, it's not a bug.
• Starting at the maximum level. It costs more and, for review, you don't have to find more.
• Revisiting the entire repository instead of diff. Wide perimeter, weak reports.
• Skipping Human Review because "AI has already looked." He looked at mechanical bugs, not choices.
• Asking for internal reasoning to "understand how he found the bug". It is reported and the request switches to an earlier model.

How to apply it in the company

For a team, review with Opus 5.5 works if it becomes a fixed pass, not an initiative of the individual:

1. The official prompt in a shared file of the repository, so everyone uses the same.
2. First mandatory pass before opening the pull request, at the low level.
3. Demonstrations become tests: each bug found adds a case to the suite, so it doesn't come back.
4. Human review reads short list, not the whole diff. The reviewer's time goes on the choices.

For the overall picture of the work in Claude Code — long runs, stop rules, subagent — see Opus 5.5 in Claude Code. For comparison with other instruments, Claude for the code.

Conclusion

The revision of the code with Opus 5.5 applies for a precise reason: It costs almost nothing and produces verifiable reports. The prompt is three lines, the effort level can stay low, and the "tell me how to make it fail" rule turns every entry into something you control in a minute. The human auditor remains, but reads a list of four things instead of six hundred lines.

If you want to go from testing with ChatGPT to an AI system integrated into business processes, Giallo Studio custom designed agents and automations.