Review the system not the syntax

Reading a big change line by line is the slowest way to find what's wrong with it. By the time you've read every line you've spent your attention on formatting and naming, which are the parts that matter least, and you still don't know how the thing fits together.

The better lens: review the system. Look at which modules the change touches, how they now depend on each other, how data moves between them, and the shape of the function interfaces. Drop down to raw code only for a targeted spot-check or when the structure tells you something is off. This is how Kent C. Dodds and Robert Martin describe reviewing work you didn't write, and it's the only lens that scales to a large agent-written diff.

What "the system" means in practice

A few concrete things to look at before any line of code:

• Module structure and new dependencies. What imports what now that didn't before. A new edge from a low-level module up to a high-level one is worth more attention than fifty tidy lines.
• Call graph. What calls what, and how far the blast radius reaches when a changed function changes again.
• Data flow. Where data enters, what transforms it, what it becomes. Follow it end to end and the awkward hand-offs show themselves.
• Interface shape. Argument counts, function size, how hard a function is to hold in your head. See Cognitive complexity tracks readability better than cyclomatic.

Why it matters more for agent-written changes

An agent diff can be clean and still be hard to enter, because you didn't watch the thinking happen. The syntax passes review easily. The system-level questions are the ones the agent can get wrong without leaving a trace: a new cycle, a leaked layer, a function that quietly does three jobs. That's also why a review map helps so much here.

This is the philosophy behind the Review System Changes Skill, which builds the module map, call graph, and data-flow entry points so the review can start at the structure instead of the first line.

The boundary

System-level review doesn't replace checking the scoped work or matching depth to risk. It changes where you start. Start at the shape of the change; go to the syntax only when the shape points you there.