A coding agent can finish a request and leave behind a diff that is much wider than the request itself. The hard part is deciding which changes belong: the requested code, related cleanup, generated files, and edits to configuration can all appear in one run.

Reviewing that diff file by file is possible, but order matters. Start by establishing what the agent was asked to do, then look for changes that could affect the project beyond that request.

1. Restate the request before reading the diff

Write the task in one or two sentences. Include the expected behavior and the files or systems you anticipated changing. This gives you a reference point when a file appears that seems unrelated.

For example, a password-reset request might reasonably touch authentication code, an email template, and tests. A change to the CI matrix deserves a separate explanation. It might be justified, but it should not blend into the requested work.

2. Inventory every changed file

Run git status --short and git diff --stat before opening individual hunks. Check new, deleted, and renamed files as well as modified ones. Group them by purpose:

  • Files directly needed for the request.
  • Supporting changes, such as tests or types.
  • Generated or formatting changes.
  • Changes whose connection to the request is unclear.

Do not assume an unfamiliar file is wrong. Ask what behavior required the change and whether the change can be reviewed independently.

3. Inspect high-impact changes early

A one-line change can matter more than a large component edit. Prioritize authentication and authorization, dependencies, migrations, deployment files, CI, data deletion, and changes that remove tests or checks.

Read enough surrounding code to understand the old and new behavior. For a deleted test, ask what scenario it covered. For a dependency change, inspect the lockfile and reason for the new package. If a hunk is hard to explain, keep it pending until you can verify it.

4. Review and verify in small decisions

Check each meaningful hunk against the original request. Keep the change when its purpose is clear and supported by the behavior you want. Revert it when it is unrelated or incorrect. When two changes depend on each other, review them together before deciding.

Then run the tests and checks relevant to the affected code. A passing test suite does not explain why a configuration change belongs, and a visual inspection does not prove the requested behavior works. Use both forms of evidence where they apply.

5. Finish with a clean account of the run

Before committing, inspect git diff again. You should be able to say what changed, why each change belongs, and what you verified. If part of the work is uncertain, record that uncertainty instead of silently treating it as reviewed.

Diffward is built around this review order. It groups an agent session, marks hunks by likely origin, and brings files that may be outside the request to the top. Attribution and that classification are still being evaluated, so use them as prompts for inspection and verify decisions against the code itself.