Review the change.
Verify the result.

A coding agent needs observable acceptance criteria: tests, a build, expected outputs or a running interface. Anthropic recommends giving Claude checks it can execute and using the results to guide corrections. This creates a feedback loop with evidence about the outcome. [01]

My interpretation is that passing checks provides evidence within their scope. A successful build says little about authorization rules; a browser test covers the journey it exercises. The agent checking its own work is also different from another reviewer examining the change.

Claude Code Review examines changes in repository context and reports findings. Its managed review does not approve or block a pull request; the check concludes neutrally. Findings require a separately configured gate to stop a merge. Claude can also initiate its local /code-review skill itself. [02]

Anthropic’s SDLC playbook combines automated findings and correction loops with code-owner approval enforced through branch protection. This is a documented workflow; its controls need to be deliberately configured in a project. [03]

GitHub recommends using Copilot review alongside careful human review and checking its suggested changes. [04]

OpenAI describes a different experiment: agents review and sometimes merge their own changes, while people define goals and validate outcomes. The report limits generalization to environments with comparable tooling and investment. It is an engineering practice report with a specific scope. [05]

These sources describe different products, environments and responsibilities. They do not support a single blanket answer about manually reading every line.

BSI and ANSSI’s 2024 guidance emphasizes developers checking and understanding generated code, with automated tests and security checks as additional layers. [06]

NIST’s SSDF 1.1 takes a broader approach: PW.7.1 lets organizations choose human review, tool analysis, or both; PW.7.2 calls for carrying out that choice, recording findings and triaging them. These different scopes do not establish that any LLM reviewer is sufficient or that every line always needs manual review. [07]

For my own research, I favour small, reviewable changes, executable checks and a separate review perspective. I want review to concentrate on intent, architecture, permissions, data boundaries and assumptions that tests may omit.

I distinguish a review comment from permission to merge or deploy. Retry limits and escalation rules keep correction loops bounded; production changes need a clear owner and an explicit acceptance decision.