“Review this code” is the least useful prompt you can send an LLM, and also the one most people default to. It’s not that the model can’t review code — it’s that with no constraints, it optimizes for sounding thorough: a paragraph on naming, a paragraph on error handling, a paragraph on tests, regardless of whether any of that is the actual problem. Here’s what has consistently gotten better results.

Tell it what kind of review you want

A security review, a correctness review, and a “does this match our conventions” review are different tasks that happen to look the same on the surface. If you don’t specify, the model splits the difference and does a shallow version of all three.

Review this diff for correctness only. Ignore style, naming,
and test coverage — assume those are handled elsewhere. I want
concrete failure scenarios: given inputs X, what breaks and why.

That last sentence matters more than it looks. Asking for “concrete failure scenarios” instead of “issues” pushes the model away from vague hedging (“this could potentially cause problems in some cases”) toward something falsifiable you can actually check.

Give it the part of the codebase it can’t see

A diff in isolation is missing the caller, the type definitions, and the invariants that made the original author write it that way. If a change touches a function with non-obvious preconditions, paste the function it’s called from, not just the function itself. The single biggest source of wrong review feedback isn’t the model being wrong about the code in front of it — it’s the model being right about code it can’t see and never asking to see it.

Ask for a verdict, not just a list

Left alone, the model will list findings whether or not there’s anything real to report — a review that always finds five things reads the same whether the code is fine or on fire. Two prompt patterns fix this:

• Force a severity ranking. “Order findings most severe first, and state your confidence for each.” Low-confidence findings sort to the bottom instead of getting equal billing with a real bug.
• Allow an empty result explicitly. “If you find nothing worth flagging, say so — don’t manufacture a minor style comment to have something to report.” This alone cuts a surprising amount of noise.

Separate “found” from “verified”

For anything non-trivial, a two-pass structure beats a single pass: have the model list candidate issues first, then in a second turn, ask it to argue against each one — construct the input that would make the claimed bug not actually happen. Findings that survive that second pass are the ones worth a comment on the PR. It costs one extra round trip and removes most of the false positives that make reviewers stop trusting the tool.

None of this is exotic prompt engineering. It’s the same thing you’d do briefing a human reviewer who’s new to the codebase: tell them what to look for, give them the context they’re missing, and ask for their confidence, not just their opinion.