Pit stop: put the diff on one screen
When a coding agent finishes a run, the quickest way to lose control of the change is to accept it the moment the run turns green. A green run proves the agent cleared the compiler and the tests it chose to run, not that it solved the problem you set. The first move in this pit stop is to open the complete diff in one review surface and expand every hunk before you read a single line. Collapsed hunks are exactly where a stray rewrite of your error path likes to hide.
Set the frame before you scroll. Keep three things next to the diff: the exact task text you sent, the acceptance criteria you care about, and the command you use to run the tests locally. With those fixed on screen, every hunk can be judged against a stable target instead of a fading memory of the prompt. If the agent also produced an intent statement or a changelog line, keep it visible and treat it as a claim to verify rather than as evidence.
- Task text: the prompt or ticket in the exact wording the agent saw, including constraints you added after the first attempt.
- Acceptance criteria: the two or three outcomes that make this change shippable in your own words.
- Local test command: the one command you trust, not the suite the agent selected for itself.
- Changed file list: so an unexpected file cannot slip past while you are deep in a hunk.
With this frame in place, the review becomes a comparison instead of a browse. You are no longer asking whether the code looks reasonable in isolation; you are asking whether each line earns its place against what you asked for.
Read the deleted lines before the added lines
Added lines are usually the part you asked for, so they invite a fast scan and a quick nod. Deleted lines are where an agent quietly drops behavior, and they deserve the first deliberate read. Start with the removals and ask what used to happen at that spot, who called it, and whether anything else still depends on it.
Most regressions I have caught in agent diffs came from a deletion that looked like cleanup: a guard clause trimmed as redundant, an exception swallowed to make a failing test quiet, a validation branch folded into a helper that never gets called from the hot path. None of those showed up in the agent summary, because each one was locally reasonable and globally wrong.
- What did the removed line guarantee?
- Which callers relied on that guarantee?
- Does any test still cover the behavior it protected?
- Was the line removed because the requirement changed, or because the agent found it inconvenient?
Reading removals first also narrows your attention for the rest of the sweep. Once you accept that a deletion is justified, the addition that replaces it usually has a much smaller surface to check, and you can spend your scrutiny where the risk actually sits.
Compare each hunk against the behavior it replaces
This is the side-by-side sweep, and it works best when you refuse to judge the new code on its own. For every hunk, look at the old side and the new side together and answer one question: for the same input, the same caller, and the same failure, does the outcome change? If it changes, name the change and decide whether it is intended. If you cannot name it, that hunk is not ready.
- Behavior: same input, same result, and the same edge cases handled.
- Error handling: nothing swallowed, nothing rethrown with the context stripped away.
- State and ordering: no assumption about sequence, caching, or shared mutation quietly introduced.
- Names and boundaries: helpers still do what their names promise, and public surfaces kept their contracts.
- Tests: new or changed tests fail when the production code is reverted, which is the cheapest proof that they mean anything.
Two rounds make this manageable. In the first, a smaller model such as DeepSeek V4 Flash can walk each hunk and record what changed, what stayed the same, and which lines look unexplained, turning the mechanical work into a list you can skim. In the second, put the hardest hunk in front of a capable reasoning model such as Claude Opus 5.5 and ask it to argue both for and against the change, then check its argument against the code yourself. The model raises the questions; you own the verdict.
Chase the side effects the diff does not name
Agent diffs rarely stop at the file you pointed at. Check the quiet companions: configuration files, environment variable reads, generated artifacts, dependency manifests, seed data, and logging calls. A change that reads a new variable without documenting it, or that logs a value that used to be private, is a change you shipped even if the code review looked clean.
Network plumbing deserves the same attention. If the change touches an API client, verify the host and the path it actually calls. SwiftRelay routes Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and other models through one pay-as-you-go relay that bills per token, and the setup detail that bites people is the base URL: Claude Code and Gemini CLI take the bare host, https://api.fastapirelay.com, while OpenAI-compatible SDKs add /v1 to that host. A diff that hardcodes a base URL or silently appends a path suffix is the kind of mistake that only reveals itself when a request fails somewhere far from the line that caused it.
Finish this section with a security sweep: secrets in logs or error messages, authorization checks removed as redundant, input validation moved behind a helper, file paths built from user data, and any new code that evaluates or executes text. Agent diffs are excellent at making these look tidy.
Green light checklist and the verdict
Run the checks in the order that gives you the most information per minute. Reproduce the original failing case first and confirm it now passes, then run the full suite, then exercise the behavior by hand if the change touches anything user-facing. Only then read the agent summary again, because by now you can tell which claims survived contact with the code.
- Every hunk read, including the hunks in files you did not expect.
- Every deletion justified against a real requirement.
- Behavior compared line by line on both sides, with each difference named.
- Configuration, host and path settings verified against the runtime you actually use.
- Tests proven to fail without the change, and no unrelated reformatting smuggled in.
From here you have three honest verdicts. Accept as is when every difference is named, intended and covered. Accept with named follow-ups when the core change is right but something small, like a missing test or a stale comment, should be tracked explicitly rather than left implicit. Send it back with instructions when a hunk cannot be explained, when behavior changed without a reason, or when the tests only pass because the tests were edited too. Write the verdict as a decision with reasons, not as a mood.
If you are wiring this review habit into a real workflow, sign up for SwiftRelay and route the review work through whichever model fits the task, with pay-as-you-go billing per token and a small gift credit for new accounts. Recommendation: accept a coding agent diff only when the side-by-side comparison shows that every added line earns its place, every deletion was intended, and the risky paths were exercised by tests you trust; otherwise send it back with the exact hunk and the exact question that is still open.