AI code review and coding-agent verification solve related problems, but they do not produce the same kind of evidence.
Review searches a change for risks and explains suspicious code. Verification asks whether the requested behavior works in practice and preserves the evidence behind that verdict. When I am evaluating agent-written code, I usually need both.
| Question | AI code review | Agent verification |
|---|---|---|
| Primary input | Diff and repository context | Task, exact change, environment, and checks |
| Main output | Findings and explanations | Pass, fail, or unverified with evidence |
| Strong at | Breadth, suspicious patterns, maintainability clues | Reproducing behavior and proving closure |
| Main limitation | A plausible finding may not reproduce | A check can miss risks outside its behavioral boundary |
| Best use | Risk discovery and reviewer focus | Acceptance, regression protection, and auditability |
Why review alone is not enough
A reviewer can notice an authorization branch that looks unsafe. Only an authoritative check can show whether an unauthorized request is accepted.
A model can praise a state update while a browser journey still loses user input. Review remains useful because it tells me where to look and what to test. It should not be promoted into runtime proof.
Why a green suite is not enough either
A passing suite can be irrelevant to the requested task, stale, or incomplete. Verification makes test output stronger by binding it to the task, revision, environment, and expected behavior.
It also keeps unknowns explicit. If no check addresses a requirement, that requirement stays unverified instead of quietly becoming a pass.
The combined loop I use
- Review the diff and repository context to identify risk.
- Translate material risks and acceptance criteria into focused checks.
- Run repository-owned tests plus the smallest missing behavioral check.
- Package review findings and execution results separately.
- Re-run after fixes and retain the before-and-after evidence.
CodeVetter is moving toward this combined evidence loop, with execution-backed verification as the authority. Its public recognition benchmark covers one narrow review dimension and explicitly does not claim to prove production pull-request performance.
The complete comparison and workflow are at https://codevetter.com/ai-code-review-vs-verification.
Top comments (3)
Unverified deserves to be a first-class result here. If the repository test suite never exercises the requested behavior, a reviewer should not be forced to choose pass or fail. I would also keep the verification record immutable across later fixes: the before result, tested revision, environment, and the exact missing behavioral check are what make the after result credible.
One property worth adding to the verification column: the check should not travel through the same credential or code path as the action it is verifying. I had a publishing script treat a write response as proof that a document was public, and the field it keyed on turned out to be absent from that representation, so the retry branch fired on a success. Reading the document back as an anonymous client made it a real check, and it fails closed — the same request for a private draft returns 404 even when I send my own key. That is also the cheapest way I know to keep "unverified" honest: if the check can only pass, it is not evidence.
The “unverified” result is the piece most systems skip. A result should not become a pass simply because the available check is convenient—or because the action itself returned success.
The same applies to environmental metrics: carbon, energy, and water figures need the workload, region, time window, and measured-vs-modeled basis attached. Otherwise the number travels farther than its evidence. Verification is not just a verdict; it is a reproducible record of what was checked, under which conditions, and what remains unknown.