How to review AI-generated code before you merge

"Done, tests pass" is a sentence, not evidence. Start from the diff and the commands that ran, and read the summary last.

The closing message comes from the same model that wrote the code, so it repeats the same assumptions. It is a useful index of what to look at, not proof that the work is finished. The evidence lives in two places: the diff, which shows the exact lines that changed, and the record of what ran after the last edit.

A Turn is one prompt and everything the agent did in response. Reviewing per Turn keeps each diff small enough to read; in Oxide, Checkpoints make each Turn's diff exact (Diff by Turn).

A diff of the whole Thread hides the order of events: a change that looked reasonable in one prompt can quietly become a wrong direction by the third. Per Turn, you can see which instruction produced which lines, and stop a bad direction before the next prompt builds on it. If a Turn went the wrong way, Restore puts the files back to the Checkpoint from before it and leaves the rest alone. What ran, and whether that run still covers the change, is the Verification Dossier's job.

Look for which tests, type checks and builds ran after the last edit, which went stale, and which languages or paths no check covers. That is what the Verification Dossier computes, without an LLM.

A green check from before the final edit says nothing about the code you are about to merge. Ask three questions of every change: did a check run, did it cover the file that changed, and did it run after the last line changed? Files with no covering check are the ones to read yourself.

Comments on lines, not paragraphs of chat. Send them back to the agent as one prompt, or to the pull request as a review (Line comments).

Feedback written in the conversation loses the line it refers to, and the agent has to guess. A comment pinned to the line survives the round trip: the agent sees the exact code and the exact request, and the next Turn is smaller. Group the comments into one prompt before you send them, so the agent answers them together instead of one at a time.

Take out one hunk or one file, or put everything back to before a Turn, and keep the rest (Revert and Restore).

Not every unwanted change deserves another prompt. Cut the part you don't want, keep what you do, and ask the agent again with less to work with. Both actions can be undone, so it is safe to try the smaller cut first.

A short checklist: every Turn read, every Risk signal looked at, checks fresh on the final commit. Optionally publish the Dossier in the pull request body so reviewers see the same evidence.

In practice:

• Every Turn read. Review the newest first, so you know what the branch adds.
• Every Risk signal looked at. Explain it, fix it, or remove the change that caused it.
• Checks fresh on the final commit. A pass from an earlier Turn does not cover the last edit.
• The Verification Dossier published, if your team wants the same evidence in the pull request.

A reviewer that didn't write the change catches a different class of problem, and you can add one without leaving the workflow. Claude Code and Codex together shows how to set up a second agent as the reviewer, what it sees, and when the extra usage is worth it.