Reading code an agent wrote is not the same job as reading code a colleague wrote. A colleague's pull request carries intent you can ask about. An agent's change carries a transcript: every file it opened, every command it ran, and a plausible explanation of all of it. The explanation is not evidence. The diff is.
That distinction stops being academic the moment more than one agent is running. Five agents finishing inside ten minutes produce five change sets. Reading is serial, so the queue is you.
Review the change, not the commits
An agent working for twenty minutes may leave one commit or nine, and the count says nothing about the work. It reflects how often the agent decided to save. Reviewing commit by commit means re-reading files the agent touched three times on its way to a final state you have not seen yet.
Read the whole change against the branch it started from, as one unit. That is the thing you are deciding about: the difference between the repository now and the repository if this lands. In Cohalen this unit has a name, the Changeset, because naming it is what stops the review from silently becoming a commit crawl.
Put the correction where the problem is
The default correction loop is prose: you read a diff, switch to the chat, and describe the file and line you want changed. The agent then re-derives what you meant, sometimes correctly.
A note attached to the diff line carries the file and the line with it. The next Turn starts with the location already pinned, and the class of failure where the agent fixes the analogous line in the wrong file goes away. Same instruction, less to reconstruct.
Let the checks carry the verdict
Some of what a reviewer does is mechanical: does it compile, do the tests pass, does the linter agree, is the branch behind. Doing that work by eye is how the interesting parts of a review get skipped.
Push it down to whatever already runs it, then reduce every signal to a single answer to a single question: can this land? Cohalen calls that answer the Verdict and states what stands in the way as Blockers. A reviewer who already knows the mechanical answer spends their attention on the part no linter covers: whether the change actually does what was asked, and what it broke that nothing tests.
What five agents change about the loop
Nothing about a single review. Everything about the queue.
- Scope the prompt to one task. A Changeset you can hold in your head comes from a prompt that asked for one thing. This is the cheapest lever on review time and it is entirely upstream.
- State the acceptance criteria in the prompt. What to build, and what to test. Then the checks answer the mechanical question before you open the diff.
- Read the changes, not the transcripts. Thinking traces are useful when a change confuses you. They are not a substitute for the diff.
The agents got fast. Review did not, and it is not going to. The only durable move is to make each change small enough to actually read.