A coding agent hands you a patch, a confident explanation, and a passing test report. None of those is an acceptance decision. Your job is to connect the requested behavior to the actual changes, then gather enough evidence to trust them. Use this walkthrough before accepting an agent-generated diff.
1. Write the acceptance criteria before opening the diff
Restate the task in observable terms: what should change, what must remain unchanged, and which failure cases matter. For a password reset fix, that might mean expired tokens fail, valid tokens work once, and responses do not reveal whether an account exists.
Ask the agent to map its changes to those criteria. Treat that explanation as a navigation aid, not proof. Anything outside the agreed behavior needs a separate justification.
2. Check the changed-file list for scope drift
Start with git status --short and git diff --stat. These show the shape of the work before individual lines distract you. Check staged changes separately with git diff --cached --stat; inspect untracked files too.
- Does a small bug fix unexpectedly touch configuration or dependencies?
- Are generated files, lockfiles, or migrations intentional?
- Did the agent modify tests, fixtures, or documentation unrelated to the request?
Separate your preexisting edits from the agent's changes. If ownership is unclear, stop and establish the review boundary rather than attributing everything in the working tree to the agent.
3. Read the behavior change before the cleanup
Open the implementation diff first, then read the surrounding function and its callers. A locally sensible edit can still violate a contract elsewhere. Trace one successful request and one failing request through the changed path.
Check return values, exception handling, state transitions, and side effects. Watch for early returns that skip cleanup, retries that repeat non-idempotent operations, and defaults that turn missing data into apparently valid output. Review formatting-only changes separately so they do not hide meaningful edits.
4. Inspect trust boundaries and dangerous side effects
Give extra attention to authentication, authorization, database writes, filesystem access, shell execution, and outbound requests. Ask where each input originates and what validates it before use.
Look for removed permission checks, credentials added to logs, broader file access, and queries built through string concatenation. Inspect package scripts and dependency changes before installing packages or running unfamiliar commands. A test command is still executable code; use an isolated environment when the patch warrants it.
5. Check whether the tests can catch the original bug
Read changed tests as critically as production code. A test that repeats the implementation's assumptions may pass while proving little. Prefer assertions about externally visible behavior, not merely whether an internal helper was called.
Where practical, verify that the regression test fails against the original implementation and passes with the patch. Add boundary cases the agent missed: empty input, duplicate requests, missing permissions, partial failures, or unexpected ordering. Confirm that mocks do not bypass the exact behavior under review.
6. Run verification yourself and record the evidence
Run the narrow regression test, the relevant test suite, and the project's applicable type-checking, linting, or build commands. Use the repository's documented commands rather than inventing replacements.
Distinguish passed, failed, and not run. Missing credentials or unavailable services are verification gaps, not passing results. Record the commands and outcomes so another reviewer can reproduce your checks. For user-facing changes, exercise the actual workflow when feasible.
7. Request a skeptical second review with focused context
Give a second reviewer the task, acceptance criteria, relevant diff, and verification results. Ask for concrete failure scenarios with file references, not a general quality score. Independently investigate each finding.
If you use different models for implementation and review, SwiftRelay offers a pay-as-you-go relay compatible with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for SwiftRelay if that setup fits your workflow. A second model's approval supplements your evidence; it does not replace it.
8. Accept only the diff you actually verified
After revisions, inspect the diff again and rerun affected checks. Confirm that temporary debugging, accidental files, and unrelated edits are absent. Review the final staged patch before committing.
Accept when the behavior matches the request, the scope is justified, and the evidence supports the change. If a material risk remains untested, keep the patch pending and name the missing check explicitly.