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

Reading the new code from top to bottom is hopeless by the second week, and clicking through the app only covers the paths you thought to try. Reading the change itself stays possible at any size, and it is the part of checking that you should keep for yourself.

The idea

A shows only what moved. Everything the assistant did to your project is in there, including the parts its summary did not mention, and it is a fraction of the size of the project itself.

text
  $ git diff
  diff --git a/src/app/api/waitlist/route.ts b/src/app/api/waitlist/route.ts
  @@ -12,3 +12,4 @@                          <- which lines, in old and new
     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

  $ git diff --stat                          <- a different command: the shape only
   .env.example                  |   2 +
   package-lock.json             | 240 ++++++++++++++++++++++++++++++++++++++
   src/app/api/waitlist/route.ts |  12 ++-
   ... 11 more files
   14 files changed, 287 insertions(+), 25 deletions(-)

How it works

  • Lines beginning with - were removed, lines beginning with + were added, and unmarked lines are context printed so you can see where the change sits. A modified line appears as one removal plus one addition.
  • The @@ line is a hunk header giving the line numbers on each side. Git prints two or three more header lines above it. You can skip all of them.
  • git diff shows changes you have not staged yet and git diff --staged shows staged ones, which is why git diff sometimes prints nothing at all after you have run git add. git diff HEAD shows both at once (HEAD means the commit you are currently sitting on) and is the safest one to reach for.
  • No form of git diff shows a file the assistant has just created, because git has never seen it before. Run git status first and read the Untracked files list, or run git add -A and then git diff --staged, which does include them. New files are worth the extra step: they are where a stray config or a second copy of something hides.
  • git diff --stat prints the file list with the size of each change. The + bar is scaled against the biggest file in the set, so it shows proportion. The number to its left is the real count.
  • 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. No terminal involved, and it is the most comfortable way to do this.
  • On GitHub, the Files changed tab 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 those 14 files are the 14 you expected. In the example above, one file was never mentioned in the request: .env.example gained two lines. That is the line to ask about before reading anything else, because a file nobody asked to touch is where the surprises are.
  2. Read the removals first. Additions are usually the work. Removals are where behaviour quietly disappears, and a deleted validation check earns more attention than a screen of new lines.
  3. Check four things every time, whatever the change was about: anything under .env, anything in package.json, anything touching login or payment code, and any string that looks like a key.
  4. Reject rather than read when the diff is mostly noise. If a hundred lines were reformatted that nobody asked to touch, put the project back to your last commit 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 cannot show what it means. Two lines can be correct on their own 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. The lockfile, the file where your package manager records the exact version of everything installed, genuinely changes by hundreds of lines when you add one package. Reading those lines teaches you nothing. Skim for the package name you expected and move on.