A Clean Starting Point

Before you ask the agent for anything, the repository should be in a state you can return to: no uncommitted changes, the tests green or their failures known, and a fresh branch from the current main branch. Then every change in the working tree is the agent's, every new failure is its doing, and throwing all of it away takes seconds.

Five minutes of setup buys a diff with nothing else in it. Skipping it buys a diff that mixes your work, the agent's work and the state main was in last Tuesday, and no tool can separate those afterwards.

A Clean Working Tree

Before the session starts, git status should report nothing to commit. If it shows a file you were halfway through editing, deal with that first: commit it, or set it aside on a branch of its own. The reason is mechanical. Your half-finished edit and the agent's changes to the same file are, to git, one change. No diff tool can split them, and discarding the agent's work discards yours with it.

Setting your own work aside is quick. Commit it on a branch of its own, with a message saying it is unfinished, and switch back to main. A commit has a name and sits in the branch list where you will see it; work hidden elsewhere is easy to forget for a week, and the agent's session will not remind you.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

# the same command, with your half-finished edit still in the tree
$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   docs/refund-policy.md

no changes added to commit (use "git add" and/or "git commit -a")

The second status above is the one to stop at. The modified file is yours, an edit to the refund policy notes you started before lunch. Ask the agent to change the refund window now and, if it also touches that file, the review in Chapter 6 starts with you trying to remember which of those lines you wrote.

Green Before You Start

Run the full suite on the starting commit, before the agent changes anything. If something already fails, write it down. At Cragmoor this week, two tests in schedule fail on main. Ines knows, and a fix is on someone else's branch.

$ python -m pytest
... 900 tests collected, progress dots trimmed ...
=========================== short test summary info ============================
FAILED tests/test_schedule.py::test_evening_class_start_in_local_time - asser...
FAILED tests/test_schedule.py::test_week_view_has_seven_days - assert 8 == 7
================== 2 failed, 898 passed in 171.38s (0:02:51) ===================

$ npx vitest run

 ❯ tests/schedule.test.ts (250 tests | 2 failed)
   ❯ schedule (250)
     × evening class start in local time
     × week view has seven days
 ... failure details trimmed ...

 Test Files  1 failed | 3 passed (4)
      Tests  2 failed | 898 passed (900)

$ ./gradlew test

> Task :test FAILED

ScheduleTest > eveningClassStartInLocalTime() FAILED
    org.opentest4j.AssertionFailedError at ScheduleTest.java:27

ScheduleTest > weekViewHasSevenDays() FAILED
    org.opentest4j.AssertionFailedError at ScheduleTest.java:33

900 tests completed, 2 failed

Without that note, here is what happens. The agent makes the refund change, runs the full suite, sees red, and does what it was built to do with red: it fixes it. The refund diff now contains changes to schedule that nobody asked for, made by a session that did not know those failures predated it and had no reason to think they were someone else's work. Afterwards, you cannot tell from the results which failures the agent caused and which it inherited.

The fix is one line in the task: "the two schedule tests fail on main; leave them alone." With it, two red tests are expected, a third is the agent's, and the summary line from the starting commit is the baseline every later run is compared against.

If main is red and nobody knows why, stop there. Find out whether the failures are known before the agent starts, because a session that begins on unexplained red is a session whose every result is ambiguous. Ten minutes asking Ines, or reading the last few commits on main, is cheaper than an afternoon of separating the agent's failures from main's.

A Fresh Branch From Current Main

Fetch first, then branch from the up-to-date main, with a name that says what the task is. One branch per task, which Chapter 9 makes a habit.

$ git fetch origin
From git.cragmoor.example:booking-service
   321b0c3..3473e53  main       -> origin/main
$ git switch -c refund-window-12h --no-track origin/main
Switched to a new branch 'refund-window-12h'
$ git status
On branch refund-window-12h
nothing to commit, working tree clean

Notice what the first git status on this page said before the fetch: "up to date with origin/main". It compares against the last fetch, not against the server. Main had moved on; a colleague had pushed a change to the refund policy notes. A branch made without fetching starts from a stale main, which shows the agent code that no longer exists and produces a diff that conflicts when it comes to merge, usually in the file you most wanted to be simple.

Name the branch for the task, not for the tool or the date. "refund-window-12h" tells a reviewer, a teammate and the next session what the branch is for; "agent-work-3" tells nobody anything. The name ends up in the pull request, in the history and in every conversation about the change, and it is the cheapest piece of context you will ever write.

Branching from origin/main rather than from your local main sidesteps the question of whether your local copy is current. Starting the branch without tracking keeps a later push from trying to land on main by accident.

Commit Before You Ask

The starting commit is the first known-good point. Everything the agent does from here is a difference from it, visible in one diff, and the way back to it takes seconds. From this point on, every pass of the loop ends in a commit or a discard, and each commit becomes the known-good point for the next pass.

Some tools, as of 2026, can also rewind their own file edits within a session. That is useful and it is not a substitute. Such checkpoints generally cover edits made through the agent's edit tool, not files changed by the commands it ran, and they live inside one session on one machine. A commit covers the whole tree, whatever changed it, and it is permanent and shared. Chapter 9 builds the habit of a commit before every request.

What It Buys

After the session, the diff against the starting commit is exactly the agent's change. Failing tests beyond the known two are its failures. Discarding means returning the branch to the starting commit, which takes seconds and loses nothing of yours, because nothing of yours is on it. The review in Chapter 6 starts from a clean slate instead of from archaeology.

It also changes how you feel about a bad answer. When throwing a pass away costs seconds, you throw it away. When it means untangling your own half-finished work from the agent's, you are tempted to keep a mediocre change and patch it, and that temptation is where Kai's second week came from.

It makes the agent's report checkable, too. When the session ends with "all tests pass except the two known schedule failures", you can verify that sentence against the baseline in seconds. When the session started from an unknown state, the same sentence could mean anything, and you would have to rebuild the starting point to find out.