Reviewing your own code is checking your work. Reviewing a colleague's is checking a shared understanding. Reviewing an agent's is neither, and the habits from the first two mislead you.
What is different
No shared context to lean on. With a colleague you can infer intent from what you know they were working on. An agent's diff has to explain itself, or be read line by line.
Fluency is not competence. Human code carries signals: hesitation, an odd name, an inconsistent style where someone was unsure. Agent code is uniformly confident, so the parts it guessed at look exactly like the parts it knew. You lose the tell.
The dangerous mistakes are plausible. An agent rarely writes nonsense. It writes something that reads perfectly and is wrong about one thing: a mocked test that asserts the mock, an error path that swallows, a config value invented because it seemed like the sort of thing that would exist.
Volume. You can generate 1,500 lines in four minutes and you cannot review 1,500 lines in four minutes. This asymmetry is the actual bottleneck in agent-assisted development, and no amount of model improvement removes it.
A reading order that works
1. Read the file list before any code. Does the shape match what you asked for? A request to fix a date bug that touched fourteen files is a finding, and you have it in ten seconds.
2. Read the tests first, and read them suspiciously. Tests are where agent-written code fails most often and most quietly. Specifically:
- Does the test assert the behaviour, or assert the mock it just configured?
- Would it fail if you broke the implementation? If you cannot answer, break it and see.
- Is it testing the thing that was hard, or the thing that was easy to write a test for?
3. Then the interfaces. Types, signatures, schemas, the API surface. An agent gets local logic right far more reliably than it gets boundaries right, and boundaries are what other code depends on.
4. Then the implementation, but only the parts the first three made you suspicious of. Reading every line linearly is how you run out of attention at 40 per cent, which is worse than not reading some of it deliberately.
5. Then run it. Not the tests it wrote. The thing itself.
The specific things to distrust
- Error handling. A caught exception that logs and continues, in a path where continuing is wrong. This is the single most common serious defect.
- Anything it did not have to invent. A constant, a header name, an environment variable, a field on a third-party response. If the agent could not have read it from your code, it may have been generated from a plausible-sounding memory.
- Deleted code. An agent removing something to make a test pass is a real behaviour. Read deletions as carefully as additions, and more carefully if they are large.
- Comments explaining what the next line does. Usually harmless, occasionally a sign the agent was narrating rather than reasoning.
- The bit it described as "simplified" or "for now". Search the diff for those words.
- Anything touching auth, money, or deletion. Ordinary care, but agents get here faster than people do.
Giving feedback that costs one round
The economics are inverted compared to human review. An agent will not be offended, will not push back on tone, and will do exactly what you said. The only cost is a wasted round, and vague feedback wastes rounds.
- Anchor to the line. "This is wrong" costs a round of the agent asking which part. Quoting the code costs nothing.
- Say what is wrong, not what to write, unless you actually want a specific implementation. "The retry has no backoff, so a flapping endpoint gets hammered" produces better code than "add backoff", because the agent solves the stated problem and often finds the second instance you had not spotted.
- Batch everything. Three notes in one message is one round. Three notes in three messages is three rounds, each rebuilding context and each costing money.
- Say when something is fine. An agent asked to address one note in a file will sometimes helpfully revise the rest of it too.
When to throw it away
Sometimes the right review outcome is to discard the branch and re-ask with a better brief. This feels wasteful and is usually cheaper than three rounds of correction, because a diff built on a misunderstanding does not converge, it accumulates patches.
The signal is when your notes are about the approach rather than about the code. Take that as a prompt to rewrite the prompt.
Where Fleet fits
Fleet shows a session's whole diff against its base, committed and uncommitted together, since either alone is still something to read. You select lines and leave notes, and the notes collect into a draft that sends as one prompt with each note's code quoted, which is the batching advice above made structural.
Notes re-anchor as the code moves, and a note whose code is gone entirely is marked orphaned rather than silently pointing at whatever now occupies those lines. See review and merge.