Trusting autonomous work

The core rule: define the check before you start the work

Any autonomous task should have a pre-defined answer to “how will I know this worked?” That answer must exist before the loop kicks off, not after Claude reports it is done.

Concretely:

• A test suite that captures the desired outcome.
• A checklist the loop is supposed to walk through, that you can re-walk yourself.
• A known-good artifact the loop is supposed to produce, whose shape you can inspect.

If you cannot answer “how will I know this worked?” in advance, do not run it autonomously. Run it interactively.

The four checks worth automating

For any long-running loop, the following instrumentation pays for itself:

1. Checkpoint on every iteration. Commit, push to a scratch branch, or write a snapshot. So a wrong turn is one iteration old, not the whole night.
2. Kill switch on divergence. If the current cost or file-touch count exceeds a threshold, stop. Better to bail than to run through the night burning credits.
3. Structured summaries. Each iteration should emit a small, machine-readable status (“iter 12: 2 tests failing, cost $0.14, next step: fix users.test.ts”). You skim these, not the raw output.
4. Automatic tests. Whatever the correctness check is, run it every iteration. A loop that changes code without running the tests is a loop optimising for looking productive.

When you come back

The check-in ritual worth building:

1. Look at the branch, not the summary. git log, git diff, git status. What actually changed.
2. Run the test suite yourself. Do not rely on the loop’s claim that they passed.
3. Sample a couple of iterations from the middle. Pick two random ones from the log. Read what Claude decided in each. Did the decisions look sane?
4. Cost it out. If the loop cost more than you budgeted, take the lesson before doing it again.

The trust-earning cycle

Trust for autonomy grows in exactly the same way it grows for anything: by starting small, keeping the check tight, and expanding scope only after each level has succeeded a few times.

Reasonable progression:

1. Interactive. You approve everything. You verify everything.
2. Loose interactive. Read-only auto-approved; you review edits.
3. Bounded background. Whole task runs in the background, in a sandbox, with a checkpoint each iteration.
4. Scheduled autonomous. Fires on cron; you check in on a cadence.
5. Ambient. Hooks and long-running loops just… happen, and you trust the checks you built.

Skipping straight from 1 to 5 is how bad stories start.

The single most important sentence in this course

Never confuse the summary with the work. It has come up in every chapter for a reason. When Claude is doing hours of autonomous work you did not watch, the temptation to skim the final report and move on is enormous. The report is not the work. The diff is. Read the diff.

Check your understanding

Quick check

—

You come back to a Claude Code loop that ran overnight and finished with the message 'All 42 iterations completed successfully. All tests pass. Ready for review.' What is the right first move?

1. AMerge to main. Ship it.
2. BRead the actual git diff of the branch, run the test suite yourself, spot-check a couple of iterations' decisions from the log, then decide whether to trust the result.
3. CSend the summary to your team as a status update and go for lunch.
4. DDelete the branch to save space.

Check answer→