Agentic Coding Workflows

Lesson 5 of 6

Reviewing Multi-File Agent Diffs and Using Git as a Safety Net

A single agentic task can touch far more files than a human would change for the same request. Reviewing that well, and having an easy way back out, matters more as the diff grows.

Reviewing a large diff

  • Look at the file list first. Before reading a single line of code, check which files changed. Does that match the plan you approved? A change to a file you didn't expect is worth questioning before you even read it.
  • Read for intent, not just correctness. Does each changed file serve the stated goal, or did something unrelated sneak in alongside it?
  • Prioritize risk. Spend your closest attention on auth, data handling, and anything touching money or user data. A typo in a comment and a broken permission check are not equally important to catch.
  • Don't approve diffs you didn't actually read. A 400-line diff you skimmed in ten seconds isn't reviewed, it's just accepted.

Commit checkpoints as an undo button

Before letting an agent start a large, multi-step change, commit your current state. If the agent's approach goes sideways three files in, you want "revert to the last commit" available, not "manually untangle which of these forty changed lines were actually part of the original request."

1. git commit your clean starting point
2. Let the agent work
3. If the result is wrong: git diff to see everything that changed,
   or git checkout/restore to throw it away and try a different prompt
4. If the result is right: review, then commit it as its own change

Checkpointing between meaningful steps (not just at the very start) means a bad turn later in a long session doesn't force you to lose everything that came before it.

Small increments review better than big ones

The same request can be given as one giant task, or broken into a few smaller ones. Smaller increments produce smaller diffs, and a small diff is one you can actually read carefully in the time you have. If an agent's first attempt at a large feature produces an enormous diff, it's often worth asking for it in stages instead, rather than trying to review it all at once.

WARNING

Never let uncommitted work pile up underneath multiple rounds of agent changes. If something goes wrong, you want a clean, recent commit to fall back to, not a tangle of your changes and the agent's changes with no clear boundary between them.

📝 Reviewing Diffs Quiz

Passing score: 70%
  1. 1.What should you check first when reviewing a large agent-generated diff?

  2. 2.Why commit your working state before a large agentic change?

  3. 3.A 400-line diff you skimmed in ten seconds isn't reviewed, it's just ____.

  4. 4.Breaking a large task into smaller increments generally produces diffs that are easier to review carefully.

  5. 5.Every changed file in a diff deserves exactly the same amount of review attention, regardless of what it touches.