You have been running git diff all module. Now let us do it properly, because this is the
skill that decides whether AI-written code is safe to keep.

Read in this order

Not top to bottom. In this order:

1. Which files changed?

git status

Before reading a single line, ask: should these files have changed? A change to a file you
did not mention is the most common quiet problem, and you can spot it in two seconds without
reading any code.

2. What was added to the project?

git diff package.json

New libraries first. A new dependency is a decision that outlives this change and is
annoying to remove later.

3. What was deleted?

git diff

Look at the removed lines before the added ones. Added code is visible when you run the app.
Deleted code is invisible, and deleting something that mattered is how features quietly
disappear.

4. Now read the added lines.

Last, not first. By now you know the shape of the change and you are reading with a
question in mind instead of just reading.

What to actually look for

When you reach the added lines, you are looking for a small number of things:

  • Does it do what you asked, or something near it?
  • Does it do more than you asked?
  • Are the rules from your plan implemented as written, or as remembered?
  • Are the edge cases from your plan handled?
  • Is anything hard-coded that should not be? A date, a number, a limit.
  • Does it handle the case where something is missing or empty?

Module 5 turns this into a proper checklist. For now, those six questions will catch most of
it.

When the change is too big to read

Sometimes you will end up with a large change anyway.

You have two honest options. Neither is “skim it”.

Option one: throw it away and ask again in smaller pieces. Usually right. You lose
minutes.

Option two: read it in pieces, one file at a time, running the app after each one.

git diff src/schedule.ts

What you must not do is scroll to the bottom, see that it looks reasonable, and commit. That
is not review. That is hope.

The honest standard

You are not trying to understand every line the way you would if you had written it.

You are trying to answer one question:

Would I be comfortable if this broke and someone asked me what it does?

If yes, commit. If no, either read more or ask for something smaller.

Before Module 5

  1. Run git log --oneline. You should have a commit for each step. If several steps share
    one commit, the steps were too big.
  2. Pick your largest commit and review it in the four-step order above. Find one thing you
    missed the first time.
  3. Recall now works. Use it for real. Add five cards about something you are actually trying
    to learn, and review them. You will find a problem this way that no amount of reading
    finds.
PreviousNext