A code review needs the problem statement as well as the diff

A clean change can answer the wrong question.

A small patch may be readable, idiomatic, and covered by tests while still solving a different problem from the one the user had. Review has to connect the patch to its purpose. A coding agent cannot reliably make that connection when the purpose is only implicit in earlier conversations.

Google’s engineering review guidance includes design, intended functionality, edge cases, and whether tests are useful. Those concerns extend beyond checking the appearance of changed lines. Context does not replace that review work; it helps identify what the reviewer needs to inspect.

A fictional change that looks familiar.

Imagine a patch adds retries to an order client. The loop has a limit, the errors are handled, and a unit test confirms that a second attempt occurs after a timeout. Those checks say something useful about the client, but not whether the retry can create another order.

The earlier contract says one request ID identifies one accepted creation. A past incident says the response can disappear after acceptance. That context changes the central review question from “does it retry?” to “what result does the retry recover?”

The reviewer must inspect where the request ID is generated, whether it remains stable across attempts, and how the service handles overlapping requests. A test that only checks invocation count may pass even if the domain behavior is wrong.

Context changes the review target.

Useful context narrows attention toward behavior that matters. It should not instruct the reviewer to find a preselected defect or assume the author is wrong. Give the contract and its evidence, then let inspection establish whether the implementation meets it.

Treat the review workflow as something to evaluate.

Our working hypothesis is that a coding agent can produce a more useful review when it has this information. That does not establish that one model, coding assistant, or dedicated review product is superior. Tools such as CodeRabbit may already incorporate several forms of context; a fair comparison needs to inspect the actual workflow being compared.

To test the contribution of context, hold the code, model, and review request fixed while changing the background supplied. Have a separate reviewer audit actionable findings, unsupported findings, and important misses against the source and implementation. Also record the effort needed to prepare and interpret the context.

The important result is whether the intervention helps resolve the engineering problem. More comments are not automatically a better review. A correct observation that nobody can act on may have limited value, while an omitted critical constraint can invalidate an otherwise polished response.

Preserve what the reviewer does not know.

In the retry example, the same request ID with a different body needs an explicit policy. If the sources do not establish it, the reviewer should flag the missing contract. It should not invent a conflict rule and then judge the implementation against that invented rule.

Likewise, a proposed design is not an accepted requirement. A passed unit test does not prove that a production incident cannot recur. A report that a consumer check remains pending must stay pending in the review brief. These distinctions prevent source context from becoming false confidence.

Prepare the review before requesting it.

Before your next agent-assisted review, write five short lines: the problem, the behavior that must remain true, the applicable decision, the known failure, and the unanswered question. Attach the sources and point to the actual change. Ask for findings grounded in that contract, with a way to verify each finding.

Keep normal tests, static checks, and accountable human review. The opportunity is to make those checks better informed. It is not to replace evidence of behavior with a persuasive explanation of what the code probably does.