Review an AI-written diff in 10 minutes: a checklist

Your coding agent says the change is done, and the app runs. Merge without checking the diff, and you may ship changes you never asked for or miss a broken edge case. This checklist gives you a practical first pass before the code reaches a client or bounty submission.

Read the agent’s summary, check the scope, inspect the riskiest files, and run the relevant checks. Ten minutes is a triage target, not proof that a complex patch is safe; if you run out of time with questions open, keep reviewing before you merge.

Start with the summary, then check the scope

Ask the agent for a short account of what it changed, why, and what it tested. Look for the commands it ran, the results, and anything it could not verify. Treat that summary as a map for your review, not as evidence that the work is correct.

Next, from the repository, run:

git diff --stat

The output summarizes changed files and the size of their edits. Compare the list with your request: a change to a contact form might reasonably touch its handler and tests, but an unexplained deployment change deserves a question.

Know what you’re comparing. As the Git diff documentation explains, plain git diff shows unstaged changes against the staging area. Use git diff --cached for staged changes. If the agent committed its work, compare the branch with the appropriate base instead, for example git diff BASE...HEAD, replacing BASE with your intended base branch.

Run git status --short too. Git’s status documentation says it also reports untracked files, which won’t appear in an ordinary diff. Inspect any new files that belong to the task before deciding you’ve seen the whole change.

Read the risky files first

Open the full diff and begin with the parts where a mistake would matter most. Depending on the app, that might mean authentication, permission checks, payment handling, database queries, deployment settings, or code that writes user data.

For each change, compare the old and new behavior. Ask: what can the caller provide, what happens with invalid input, and what does the code do when the operation fails? If a new condition was added, check whether a nearby guard was removed or bypassed.

Follow the path beyond the changed line when necessary. A function that looks reasonable in isolation may be called with values it doesn’t expect. Likewise, an error message can look helpful while the underlying operation returns success after failing.

Check the surrounding permissions as well as the visible interface. If a button disappears for a user, find the server-side check that prevents that user from making the request directly. Use test accounts and data where you can.

If the scope is too broad to understand, ask the agent to separate unrelated edits or explain why they are needed. A smaller patch is easier to review against a specific request.

Look for changes that need an explanation

Scan the remaining diff for these red flags. None automatically proves the patch is wrong, but each deserves an answer before merge:

• Deleted or weakened tests. Look for removed cases, skipped tests, looser assertions, and changed expected results. Ask what behavior each altered test still verifies.
• Swallowed errors. Inspect broad catch blocks and fallbacks. If a failed operation returns an empty result or success response, check whether the caller can tell something went wrong.
• New dependencies. Check the manifest and lockfile. Confirm the package name, source, purpose, and whether the feature actually needs it.
• Hard-coded secrets or URLs. Look for credentials and newly fixed service addresses. If a real secret was exposed, revoke or rotate it; removing the line alone is not enough.
• Unrelated reformatting. Large formatting edits can obscure functional changes. Ask for them to be separated when they make the patch difficult to inspect.
• New TODOs or changed config. A TODO may identify unfinished required work. Check changed defaults, feature flags, environment settings, and deployment targets against the task.

Review test changes alongside implementation changes. If the agent changed an expected result, ask whether the product requirement changed too. If it did not, keep digging rather than accepting the new expectation because the test is green.

Run the flow you’re about to ship

Run the project’s documented tests relevant to the patch. Read the output for failures and skipped checks; “tests passed” is only useful when you know which tests ran. If a command cannot run in your environment, record that gap.

Then perform the user flow the change touches. For a form, submit valid data and inspect the result. For a settings change, save the setting and verify the behavior after navigating away and returning. Use a safe test environment rather than real customer data.

Add an edge case chosen for the feature. Try a blank field, an invalid value, a denied account, or a repeated action. State what you expect before running it, then compare the actual result. If the expected behavior is unclear, resolve that with the person who requested the work.

When a test fails, give the agent the exact failure and reproduction steps. Ask for a focused fix, then review the new diff and rerun the relevant checks. A fix can introduce another change, so it needs review too.

A harness with a built-in diff view and test runner makes this loop faster; you can try the ZCode agent harness free with our invite link. Whatever you use, keep the evidence from the checks available for your handoff.

Save this 10-minute first-pass checklist

Use these timings as a suggested review budget, not a claim that every patch can be reviewed this quickly:

• Minutes 0 - 2: Read the summary, claimed checks, and known gaps
• Minutes 2 - 3: Check diff scope, staged changes, and untracked files
• Minutes 3 - 6: Inspect permission, data, payment, and config changes first
• Minutes 6 - 8: Scan tests, errors, dependencies, secrets, TODOs, and unrelated edits
• Minutes 8 - 10: Run relevant checks, the changed flow, and an edge case
• Before merge: Resolve unclear lines, failures, and unverified changes

If tests take longer than the remaining time, let them finish and review the result. If the patch is large or touches sensitive behavior, extend the review or ask for another reviewer. An incomplete check should stay marked incomplete.

If agent coding is a daily habit, you can get a referral discount on GLM coding plans with our referral link; Z.ai's campaign terms give invited users a referral discount on their first GLM Coding subscription. Both Z.ai links in this post are our invite links, and we may receive referral credits.

Ask before you approve

When you find a line you don’t understand, give the agent its file and surrounding code, then ask:

Explain what this change does, what behavior it replaces, and what happens if the operation fails. Point to the relevant test or show how I can verify it. Do not change the code yet.

Read the answer against the diff and run the proposed check where appropriate. If the explanation depends on a configuration value or a caller outside the patch, inspect that too. Ask a person familiar with the code when the answer still doesn’t establish what will happen.

Finish with a handoff that distinguishes what you checked from what remains open. List the commands run, the user flow and edge case exercised, and any checks you could not complete. Don’t describe the patch as verified if a required test or risky change is still unresolved.

Find more practical teardowns on our blog. For a broader review routine, read when to trust AI agent output and how to verify it.

If this helped you review a patch, a small tip on this post helps keep these guides coming.