Your agent writes most of the code now, and it writes it faster than you can read. The temptation is to skim its summary, see the app still runs, and move on. But that summary is a claim, not the code, and review is the first time a human truly looks at what shipped. This chapter makes that look happen every time, before the change lands.
4.7.1Read what the agent wrote
The agent hands you a confident paragraph describing what it did. Open the diff, the exact lines added and removed, and read them against what you actually asked for. That is code review: you deciding whether this change earns a place in your codebase, from the real evidence and not the sales pitch.
Read the whole change, not just the parts you follow at a glance. The lines you skip are exactly where the bug you cannot explain later is hiding.
4.7.2Review even when solo
On a team, a second engineer reads the change before anything merges. Alone with an agent, that second engineer is you, and skipping the step does not make the code safe, it just means nobody looked.
Fresh eyes catch what the author cannot see, so give yourself them: read the diff as if a stranger wrote it. Better, hand it to a second agent whose only job is to review, the same builder-and-reviewer split you use elsewhere, so a different mind grades the work.
Watch out: the change that also quietly renamed, restructured, or "cleaned up" something you never asked about is the one that breaks a working feature. Extra scope is not a bonus, it is unreviewed risk.
4.7.3Four checks on every diff
You are not re-deriving the code from scratch, you are running it past a fixed set of questions. The same four, every diff:
Take the package question seriously. Agents pull in libraries you do not need, and they sometimes name one that does not exist at all. Attackers now exploit that: they register the invented name and fill it with their own code. Before you accept a new dependency, have the agent show you its official page and the date of its last release.
4.7.4The common answer is not always the right one
The four checks catch code that is wrong. They miss code that is merely average. An agent predicts the most common solution, and most common is not the same as most appropriate.
Its answer is the average of everything it read. Sometimes that is a solid default. Sometimes it is an outdated choice, a heavier dependency than you need, or a generic approach blind to what makes your case different.
None of that trips the checklist, because the code runs. It is just not the best code for you.
So add one question to the read: is this the choice everyone reaches for by reflex, or the right one here? When you are not sure, ask the agent for two or three alternatives and why it picked this one.
Rule of thumb: "everyone uses this" is how the agent defaults, not why it fits you. Judge the reasoning it gives, not the popularity of the answer.
4.7.5Comments should explain why, not what
While you read the diff, watch how it comments. The agent loves to narrate the obvious (// increment the counter above count++), and that noise buries the lines that matter. What earns its place is a comment where a choice is surprising: why this retry limit, why this workaround, the reason the code itself cannot show. A comment is documentation that lives next to the code, and the agent re-reads it next session, so keep the why and cut the what.
4.7.6Never ship what you don't understand
A change you cannot explain is one you cannot maintain, debug, or trust. If a line does what you asked but you have no idea how, that is not done, it is a liability with a green checkmark.
So make the agent teach you: have it walk you through anything unclear until you could defend it yourself. Then run the review as one command:
Do this now: take the last change your agent made, open its diff, and run it through the four checks and the prompt before you accept it. A reviewed, running app is what you carry into hardening it for real users.
