The session ends with a confident summary: the bug is fixed, the tests pass, 312 lines changed across 14 files.

You believe roughly the first half of that sentence. Checking the rest by reading the new code from top to bottom does not scale. Reading the change does.

The idea

A shows only what moved. Everything the agent did to your project is in there, including the parts it did not mention in its summary, and it is a fraction of the size of the project itself. This is the one verification skill that holds up as the changes get bigger.

text
  diff --git a/src/app/api/waitlist/route.ts   <- which file
  @@ -12,7 +12,9 @@                            <- which lines
     const body = await req.json();            <- context (unchanged)
  -  if (!body.email) return err(400);          <- removed
  +  const parsed = schema.safeParse(body);     <- added
  +  if (!parsed.success) return err(400);      <- added
     await db.insert(body);                    <- context

     14 files changed, 287 insertions(+), 25 deletions(-)
       src/app/api/waitlist/route.ts   | 12 ++---
       package-lock.json               | 240 +++++++++     <- read the shape first
       .env.example                    |  2 +

How it works

  • Lines beginning with - were removed. Lines beginning with + were added. Unmarked lines are context, printed so you can see where the change sits. A modified line shows up as one removal plus one addition.
  • The @@ line is a hunk header giving the line numbers, and you can ignore it.
  • In the terminal, git diff shows unstaged changes and git diff --staged shows staged ones. git diff --stat prints just the file list and the size of each change.
  • In VS Code or Cursor, the Source Control panel lists every changed file and opens each one side by side, old on the left and new on the right. This is the most comfortable way to do it.
  • On GitHub, the Files changed tab of a pull request shows the same thing in a browser, with a comment box on any line.

What to do

  1. Look at the shape before the content. git diff --stat takes two seconds and tells you whether 14 files is the 14 you expected. A file you did not ask about is the highest-value signal on the page.
  2. Read the removals first. Additions are usually the work; removals are where behaviour quietly disappears. A deleted validation check or error branch is worth more attention than fifty new lines.
  3. Check four categories every time, whatever the change was about: anything under .env, anything in package.json, anything touching auth or payment code, and any string that looks like a key.
  4. Reject rather than read when the diff is mostly noise. If 200 lines were reformatted that nobody asked to touch, git restore . and ask again with "change only the two files you named, do not reformat anything else". A smaller second attempt is cheaper than a careful review of a bad first one.

Where it breaks

A diff shows what changed, and it cannot show what that means. Two lines can be correct in isolation and wrong together, or correct here and broken for the one page that imports this file. Nothing about a clean review says the feature works. You still have to run it.

Some large diffs are legitimate. A lockfile like package-lock.json or pnpm-lock.yaml genuinely changes by hundreds of lines when you install one package, and reading those lines teaches you nothing. Skim them for the package name you expected and move on.