Checkpoint Thinking

A flight plan gets approved at nine in the morning: five steps, each with a one-line description, nothing controversial in any of them individually. By eleven, three steps have executed and merged cleanly. Step four rewrites how a shared cache invalidates; step five builds directly on top of it, trusting the rewrite is correct because nothing said otherwise. The plan finishes on schedule. Two days later a different session, working in an unrelated part of the same repository, starts failing in a way nobody can immediately explain, and the fix means walking backward through five steps to find the one where things actually went wrong — because nothing between step three and step five marked where good ended and risk began.

This is not the failure a code review catches, and it is not the failure per-action hooks catch either — a hook fires on a single tool call, deterministic and narrow, checking one file path or one shell command against one rule. What went wrong here happened across steps, in the interaction between a plan that looked fine at every individual point and a session that never paused to ask whether the plan, three steps in, still deserved the trust it was given at step one.

What batch size predicts

Software delivery research has a settled-enough answer for why this matters at the workflow grain and not just the action grain. DORA’s own guidance on delivery performance states plainly that smaller changes are easier to recover from if something goes wrong, and that reducing batch size is one of the more direct levers a team has over both how fast changes move and how often they break something on the way. The finding predates AI-assisted coding by years and has nothing to do with models; it is about how much surface area a person can hold in their head between one decision point and the next. A twenty-year-old result from Microsoft Research makes a narrower, complementary point: absolute code churn — how many files, how many lines, in one change — is a weak predictor of defects on its own, but churn measured relative to a component’s size and history predicted fault-prone binaries with close to ninety percent accuracy in a study of Windows Server 2003. File count and change size are not incidental details about a plan step. They are two of the oldest known signals for where defects concentrate, and any confidence score worth building should already know that.

The frequency nobody decides

Most teams that adopt an AI harness end up with checkpoint frequency set by default rather than by decision, and the defaults cluster at two extremes. Wire hooks to every tool call and a session is, in effect, stopped constantly — at a grain fine enough to block a write to a protected path but too fine to ask whether an entire approach is still sound. Or approve a flight plan once, at the start, and check nothing again until the session declares itself finished, which puts the only review at the two points where reviewing is least informative: before any evidence exists, and after all of it has already accumulated into one large diff. Both patterns feel like oversight. Neither one pauses at the place most of the actual risk in a multi-step plan concentrates — the boundary between one step and the next, where a session either builds correctly on what it just did or quietly compounds a mistake into everything after it.

Checkpoint thinking

Call the discipline checkpoint thinking: treating how often a session pauses between plan steps as a deliberate design choice rather than a harness default, and building each pause around three things — a snapshot cheap enough that taking it costs nothing, a diff small enough to actually read, and a signal that tells a reviewer whether this particular pause deserves five minutes of attention or five seconds of it. The unit being gated is a step of an already-approved plan — not the individual tool call a hook fires on, and not the decision to commit to an approach at all, which this Library covers elsewhere as plan-mode review. What checkpoint thinking adds is the middle grain: the plan — what this volume’s second chapter names Flight Plans — looked right when it was approved at the start. Does it still look right three steps in.

What a confidence score should measure

The obvious shortcut is to ask the model how confident it is in what it just did, and the obvious shortcut does not work. A 2026 study of AI agents’ ability to predict their own task success found some agents that actually succeed only 22% of the time predicting a 77% success rate for themselves — a gap wide enough that the self-report carries close to no information. The same researchers found pre-execution guesses, made with less information than the agent had by the end, often discriminated better than the agent’s own after-the-fact review of its work. None of this should be surprising in hindsight: a model narrating its own confidence is still generating text, subject to the same fluency-over-accuracy pressure as everything else it writes.

A workable score has to be computed from things a reviewer can independently check, not asserted by the thing being scored. Google’s own internal study of a bug-prediction tool it rolled out to real engineers found the algorithm’s raw accuracy was almost beside the point: what determined whether developers actually changed their behavior was whether the tool’s output was actionable and its reasoning obvious, and a risk flag nobody could explain got ignored no matter how well it scored in the lab. A confidence figure a team cannot decompose into named reasons earns the same fate — skimmed, not read, the same fate the ceremony pattern this Library has already named elsewhere produces by a different route.

Rollback as a mechanic, not an apology

A checkpoint that only observes is half a mechanism. The other half is what happens when the answer to whether a step still looks right is no, and here the discipline is older than AI coding and genuinely cheap: tag the working tree at the checkpoint, and revert to the tag if a later step turns out to have been the wrong one. Anthropic’s own guidance for long-running agents leans on exactly this pattern — pointing a session at git to recover a known-good state rather than trying to hand-edit its way out of a bad turn. Some tools already implement a version of it: Kilo Code snapshots the workspace automatically at the start and end of every model turn, with a real limitation worth stating rather than glossing over — its rollback granularity is the whole user turn, so a good edit and a bad edit that landed inside the same turn revert together, with no way to keep one and discard the other.

Gating at the plan-step boundary rather than the model-turn boundary matters because a step is usually the more meaningful unit — a session can take several turns to complete one step of a plan, and tagging at the step means the good and bad turns inside it are already reconciled by the time the tag exists, rather than needing to be untangled after the fact. The alternative to a tag is the archaeology this Library has already named in a sibling chapter: reconstructing, from a diff that has grown across steps nobody marked, which parts were the mistake and which parts happened to be fine. A tag turns that reconstruction into a single command. What makes it worth doing every time is not that a git tag is technically impressive — it is the least impressive part of the mechanism — it is that the cost of taking one is close enough to zero that there is no honest argument for skipping it.

What a checkpoint log would show

The number worth watching, if a team builds this out, is not the approval rate. It is whether the confidence score and the eventual outcome actually agree with each other — whether the checkpoints the score flagged as risky are the ones that later got rolled back, and whether the ones it scored high stayed approved without a second look. A score that does not track outcomes is decoration wearing the shape of rigor, no more trustworthy than the self-reported number it was built to replace.

Checkpoint frequency, like the plan it gates, is a workflow decision rather than a harness default — one more piece of the discipline this volume is assembling around the session as the unit of work. Setting it well means resisting both temptations at once: the temptation to gate every action, which turns review into ceremony nobody reads closely, and the temptation to gate nothing between the plan’s approval and its completion, which turns a wrong step three into an archaeology project by step five.