Building Software

Engineering Fundamentals for the Agent Era

Contents Section 9, Directing Agents

Reading and Reviewing Code You Did Not Write

Mistakes to catch in review

  1. A change that passes the tests but alters behavior outside the requested task.

  2. A second date-formatting helper added next to the existing one, with slightly different time-zone handling.

  3. A pull request description that says 'all tests pass' with no command or output attached, when the suite was never run after the final edit.

  4. An agent reviewer approving another agent's change because both share the same wrong assumption.

Reading diffs and unfamiliar code critically: what to check first, where agent changes typically go wrong, and how to review more code than you could ever write.

Topics

Reading Unfamiliar Code
Tracing entry points, data flow and side effects in code you did not write.
Reading Diffs
Reading a change in the context of the code around it, including what it deletes, what it renames and what it quietly leaves untouched.
A Review Checklist for Agent Changes
Scope, error paths, security, data changes, new dependencies and duplicated logic, checked in a fixed order.
Reviewing Tests First
Checking that the tests encode the right behavior before trusting the code that passes them.
Risk-Based Review
Spending attention where mistakes are costly, such as security, money, data and migrations, and less where they are cheap.
Automated Reviewers and Shared Blind Spots
Using model reviewers for coverage while remembering that two models can be wrong in the same way.

You understand it when you can

  • Review an agent-written pull request and find its defects without asking an agent to review it.
  • For a given change, identify which parts are load-bearing and deserve line-by-line reading.
  • Read the tests in a change before the code, and say whether they would catch the obvious ways the change could be wrong.

Drill

An agent opened a 600-line pull request titled 'Add CSV export' that also edits the shared date-formatting helper, adds a second helper with different time-zone handling, and updates two snapshot tests to match. Find the behavior change outside the task and mark the lines that deserve line-by-line reading.

Start here

Reference

Google Engineering Practices: How to do a code review

Google's published reviewer guide sets the order to look at a change (design, functionality, complexity, tests, then naming), says to read every line, and asks reviewers to put the most attention on the parts that carry the most risk.

Watch

Read

The Programmer's Brain: What every programmer needs to know about cognition

Felienne Hermans, 2021.

Uses research on working memory and chunking to teach concrete methods for reading unfamiliar code and diffs quickly without losing the thread.

Looks Good to Me: Constructive Code Reviews

Adrienne Braganza, 2025.

A full review process: what to check and in what order, how to tell load-bearing lines from routine ones, and when to reject a change instead of approving it.

Working Effectively with Legacy Code

Michael C. Feathers, 2004.

The classic on understanding code you did not write by finding its seams and pinning its behavior with characterization tests, which is how you check whether an agent's change altered behavior outside the task.