Small Diffs, Frequent Commits

Here is the prompt almost everyone writes in their first week:

Build me a task app with user accounts, projects, due dates,tags, a calendar view, email reminders, and dark mode.

You will get something. It will run. And then you are stuck, for three reasons.

1. 1
   You cannot review it

   Two thousand lines across fifteen files. Nobody reviews that properly, so you accept it unread — and now you are maintaining code you have never seen.

2. 2
   You cannot debug it

   Something is broken. Which of the eight features caused it? Every one is a suspect, because they all arrived together.

3. 3
   You cannot steer it

   The AI made a hundred decisions you never saw. By the time you disagree with one, the rest are built on top of it.

There is a fourth failure that is easy to miss, because it does not look like a failure. The eight features rarely agree with each other. The calendar view and the due-date field were each implemented independently, twenty minutes apart in the same reply, so they store the date in two different formats — and nothing catches it, because nothing in a two-thousand-line diff gets read closely enough to notice.

Same app. Ten prompts instead of one:

1. Set up the project with a page that lists hardcoded tasks.2. Add a form to create a task. Keep it in React state.3. Add a checkbox to mark a task done.4. Persist the list to localStorage.5. Add due dates with a date picker....

Each one is reviewable in a minute, runnable immediately, and committable. If step 5 breaks something, steps 1 to 4 are still good and you know exactly where the problem is.

This is not only about your comprehension. Small requests get better output, for a reason that follows directly from the previous part of this course.

Small diffs only pay off if you actually snapshot them. The loop is short enough to become muscle memory:

$ git add .$ git commit -m "Add due dates to tasks"

Do that after every prompt that works. It costs three seconds and it is what makes git restore . a real option instead of a threat — you can always throw away the current mess without losing the last good state.

Sometimes you already have the huge diff — the AI took one instruction and ran further than intended, or you accepted a big feature request before reading this chapter. Splitting after the fact is slower than doing it in small pieces from the start, but it is not hopeless.

Start by finding the shape of the damage, not by reading every line. git diff --stat tells you how many files changed and by how much before you commit to reading any of it. A diff touching two files you expected and one you did not is a different problem to one touching nineteen.

1. 1

   Separate mechanical changes from real ones

   Reformatting, import sorting, and renamed variables should never share a commit with logic changes. Ask the AI which lines in the diff are purely cosmetic.

2. 2

   Commit in slices with git add -p

   Stage and commit the parts you understand and trust, even if it is only the scaffolding, so you are reviewing a shrinking remainder rather than the whole thing at once.

3. 3

   Ask for a file-by-file summary

   "Describe what changed in each file and why" forces a structure onto a diff that arrived with none.

4. 4

   If it is too tangled to trust, discard it

   git restore . and re-request the same feature in three or four prompts. Slower now, faster than debugging code nobody, including the AI, can now explain.

$ git diff --stat$ git add -p$ git commit -m "Add search filtering (1/3): state and input"

The rule is not absolute. A large change is reasonable when it is mechanical and verifiable — renaming a symbol across forty files, say, where the type checker confirms the result and any error is loud rather than subtle.

The distinction is not size. It is whether you can tell that the change is correct. Forty files of a rename you can verify beats one file of logic you cannot.