4.3 Reading the Agent's Work

You don't have to write code to review code — you have to read change. Diffs, summaries, and pointed questions are the reviewer's toolkit, and they work whether you're a career engineer or someone who first opened a terminal two chapters ago. This lesson builds the reviewing eye.

What you will learn

• Read a diff: what changed, where, how much.
• Use the agent itself as your explainer without letting it grade its own homework.
• Apply lane-appropriate review depth — and know what you're looking for at each.

Builder principle

Never accept work you haven't looked at. "Looked at" scales with your skill — but it never rounds down to zero.

The diff: change made visible

After any agent session, before committing:

$ git diff

Diffs read the same in every language and every tool:

--- a/index.html
+++ b/index.html
@@ -42,6 +42,12 @@
     <p>Portfolio under construction.</p>
+    <section class="contact">
+      <h2>Get in touch</h2>
+      <a href="mailto:jordan@example.com">Email me</a>
+    </section>

• Lines with + were added. Lines with - were removed. Everything else is unchanged context showing you where.
• The header tells you which file; @@ marks roughly where in the file.

Two questions answer themselves the moment you look:

1. Scope check: how many files, how many lines? A "small tweak" showing 400 changed lines across 9 files is a conversation, not a commit.
2. Location check: are the changes where you'd expect? Contact section task → changes near the bottom of index.html, maybe some CSS. Changes to package.json? Ask why.

You can do both checks on day one, with zero code literacy. That's already real review.

Using the agent as your explainer

The agent wrote it; make the agent walk you through it — with prompts that force clarity instead of cheerleading:

Walk me through this diff section by section, in plain language.
For each part: what does it do, and what happens if it breaks?

What's the weakest part of what you just wrote? What would a
skeptical senior reviewer flag?

That second prompt is disproportionately powerful. Models are much better at criticism when you ask for criticism than when you ask "is this good?" (which invites agreement). Make the skeptical-reviewer question a standard part of your post-flight on anything that matters.

One caution: the agent explaining its work is the start of review, not the end — it's still the same author describing its own intentions. The diff, the tests, and your hands-on check are the ground truth.

Review depth by lane

🌱 No-code lane⚙️ Engineer lane

Your review stack, in order:

1. Scope + location checks on the diff (above) — always.
2. Plain-language walkthrough from the agent — always.
3. The skeptical-reviewer question — on anything you'll share or sell.
4. Behavioral testing — use the thing, thoroughly (next lesson).

And quietly, something compounding happens: you'll read the walkthroughs next to the diffs, week after week, and code will start making sense — not because you studied, but because you kept looking. Six months from now you'll catch a bug by eye and surprise yourself.

Review agent code exactly like a teammate's PR — same standards, same skepticism, plus agent-specific tells:

• Over-engineering — abstractions and options nobody asked for. Push back; demand the simple version.
• Convention drift — subtly different patterns from your codebase. (Fix systematically with CLAUDE.md in Chapter 5.)
• Test theater — tests that mirror the implementation or mock away the behavior under test. Read assertions, not test counts.
• Silent scope creep — drive-by "improvements" in files adjacent to the task. Each one is a review-attention tax; tell the agent to keep diffs minimal.

git diff --stat first for shape, then file-by-file. Structure your sessions so diffs stay reviewable: one logical change per commit (Lesson 3.3's rhythm) — if a diff is too big to review, the session was too big; that's feedback for your next brief.

Try it now

Pull up the diff from your Lesson 4.2 quick-win build (git log --oneline, then git diff HEAD~1 if you already committed):

1. Run the scope and location checks — one journal line each.
2. Ask for the section-by-section walkthrough. Note one thing you now understand that you didn't before.
3. Ask the skeptical-reviewer question. Did it surface anything real? (It usually does.)
4. Have it fix the most legitimate flag it raised. Review that diff too — smaller, right?

Check your understanding

• In a diff, what do +, -, and the @@ lines each tell you?
• What are the scope and location checks, and why do they require zero code literacy?
• Why does "what would a skeptical reviewer flag?" outperform "is this good?"
• Engineer lane: name three agent-specific code smells and the countermeasure for each.