Review, undo, and commit your first change

The agent says the tests pass, and they probably do. But “probably” is doing a lot of work in that sentence, and the change is about to carry your name into the project history. This lesson is the habit that makes everything else safe: you treat the agent’s output as a proposal you review, not a result you accept — and you give yourself a floor to fall back to when the review goes badly.

Read the diff before you believe the summary

The agent’s closing summary — “added the endpoint and a passing test” — is a claim about what it did. The diff is the evidence. Always read the evidence, because the gap between the two is exactly where bugs live: a test that passes because it asserts the wrong thing, a handler that returns 200 but with the wrong body, an edit that also touched a line you didn’t expect.

> /diff          # show everything changed this session, in one view

You can also just ask — “show me everything you changed” — or, if you’re in your editor, see the edits rendered as a normal diff in the gutter, which is the subject of the last lesson in this chapter. However you look at it, you’re reading for two things: does the change do what I asked, and did it do anything I didn’t ask. For a two-file health-check, that’s a ten-second read. The point isn’t the time; it’s that you never skip it. A reviewed small change builds the habit you’ll lean on hard when the changes are large.

When it’s wrong, roll back — don’t patch forward

Suppose the review turns up something off — the test asserts status: 'up' instead of 'ok', say. Your instinct will be to type a correction and let the agent patch it. Resist that on anything but the most trivial fix. The cleaner move is to step the change back and re-ask, so the agent isn’t reasoning about a fix layered on top of its own mistake. Claude Code keeps checkpoints of your session for exactly this — pressing Esc twice opens them — and undoing a bad run is a skill with enough depth that it gets its own lesson in the next chapter. For now just know the escape hatch exists: a wrong change is one keystroke from gone, not something you have to dig yourself out of by hand.

Commit the moment it’s right

When the review does pass, commit immediately — and you can have the agent do it:

> commit this with a sensible message

  ⏵ Run  git commit -am "Add GET /healthz health-check endpoint and test"   → y

This is the single most valuable habit in the chapter, and it’s worth being blunt about why. The agent’s own undo — those checkpoints — is real but session-scoped; it vanishes when you /clear or quit. Git is the floor that doesn’t vanish. Every time the agent reaches a genuinely working state and you’ve reviewed it, a commit locks it in permanently. Then the next experiment, however badly it goes, can never cost you more than the work since your last commit. Commit at every green, reviewed checkpoint and you can let the agent take bigger swings, because the downside is always capped at “go back to the last commit.”

Your first change is written, reviewed, and committed — the whole loop, closed once by hand. Now make it something you reach for without thinking, by putting it where you already spend your day: next to your editor.