Between the words the code is written and the task is done lies a whole phase that is easy to skip. The agent's final message describes intent: what it wanted to change and why. The diff shows the actual implementation - what will really land in the repository. Those two diverge more often than one would like, and not out of ill will: the message is written from the plan, while the code emerges along the way. The only way to learn about the divergence in time is to look at the diff rather than at the retelling.
A naive check looks like this: read the final paragraph, see the word done and accept the changes. It misses whole classes of edits. The diff still holds untracked files, generated artifacts, updated dependency lock files and configuration edits the message said nothing about - not because the agent hid them, but because to it they are a by-product of the work rather than the subject of the story.
That is why review is arranged as a separate phase with its own interface: changes can be viewed, accepted, rejected or commented on. The value is that the decision is made per change rather than for the task as a whole. That is exactly the granularity you miss when the diff is large: accepting the useful and rejecting the excess costs less than rolling everything back and explaining again.
The second half of review is evidence, and it has levels. Syntax is proved by the formatter or the compiler. Types by a typecheck with an exit code. Behavior by a focused test or a reproducible scenario. Regressions by a wider run in a reasonable area. The interface by interaction in the browser with a screenshot. Integration by a build or a contract test. And the change itself by a manual diff review plus a clean, expected git status.
It helps to lay those levels out in a table once and keep it in sight. You come back to it when you need to answer whether enough has been checked: the level of evidence is chosen by the cost of a mistake, not by the wish to close the task sooner. A small text edit does not require a full test run, while a change to money calculations is not closed by the project building.
| Level | Evidence |
|---|---|
| Syntax |
| Formatter, parser, compiler |
| Types | The project typecheck with an exit code |
|---|
| Behavior | A focused test or a reproducible scenario |
|---|
| Regressions | A wider run in a reasonable area |
|---|
| Interface | Interaction in the browser, a screenshot or a recording |
|---|
| Integration | A build or contract test and explicit external limits |
|---|
| The change | A manual diff review and a clean, expected git status |
|---|
An independent review technique is useful too: ask the agent to check its own work as a reviewer - first list the risks by severity with file paths, then run the existing focused checks, and do not fix what was found until the findings have been shown. Separating findings from fixes is essential here: otherwise the review turns into a new batch of changes that again nobody reviewed.
Evidence has a property people remember late: a check proves something only if it is sensitive to the change. A green run after an edit means only that the test suite did not notice a difference - which is exactly what happens when the changed branch is not covered by tests. Checking that sensitivity costs less than it seems: name the test that would fail if the edit were reverted. If there is no such test, the behavior is not proved, however many checkmarks stand next to it.
Reviewing every change has a price, and it grows faster than the size of the diff. Twenty edits across three files are worked through in a few minutes; two hundred edits across thirty files can no longer be read attentively, and the decision is made in bulk. The size of a task is therefore chosen by the readability of its result rather than by ambition: a task should produce a diff you can work through in one pass. The sign that the boundary has been crossed is simple - you accept changes without opening some of the files.
Hence the completion formula worth remembering. The code is written is an intermediate state. Completion is the expected diff plus observed behavior plus the checks that were run plus an explicit list of what could not be verified. That last item is not a sign of weakness but of honesty: it shows where your attention is needed most.
The typical review failures are predictable. Judging by the final message instead of the diff. Missing untracked and generated files that are not visible in the usual view. Taking a green run for proof of behavior that run does not cover. And agreeing to fix findings before they have been shown and weighed.
Review the finished work as an independent reviewer.
First list the risks by severity and name the files.
Then run the existing focused checks.
Do not fix what you find until you have shown the findings.