Dev Tool Experiences
All articles

· 7 min read

Why Your AI Agent Restores a Checkpoint Exactly Three Times Before It Works

By H. Mansour

  • tools
  • satire

This is satire, but it is also the approved operating procedure at the Institute for Reversible Progress: let the coding agent make a confident change, restore the checkpoint, let it make the same change with different indentation, restore again, then observe it solve the problem on the third attempt as though it has finally been granted access to the repository’s hidden emotional truth. The number is always three. Two restores are caution. Four is an incident review.

Checkpoint one: the agent discovers the obvious solution is technically legal

The first attempt is usually fast, complete, and wrong in a way that tests cannot immediately articulate. You ask for a retry wrapper around one HTTP client. The agent adds a retry wrapper around every HTTP client, moves configuration into a new abstraction named ResilienceOrchestrator, and updates 43 files because a fixture once imported the old helper by relative path. It then reports that the change is complete and asks whether you would like it to run the test suite, a question it poses after it has already edited the test harness.

At this point, restoring the checkpoint is not a reversal. It is a ceremonial acknowledgement that the agent followed the literal request with the enthusiasm of a municipal zoning office discovering an unregulated shed. You click restore and watch 43 files disappear. The working tree becomes calm. Somewhere, a dependency graph exhales.

Tools do provide mechanisms for this, although they do not call it the Rite of the First Regret. Cline documents Git-based snapshots for file changes in a task. GitHub Copilot CLI offers rewind points per prompt, including an option to restore files as well as conversation history; its docs specifically recommend checking the resulting state with git status and git diff. That last detail is less a workflow tip than a reminder that the checkpoint has restored files, not judgment.

Checkpoint two: the agent discovers the intended solution is socially illegal

Your second prompt is better. It contains constraints: “Do not change public APIs. Touch only src/client.ts and its direct test. Preserve existing backoff behavior. Run the focused test first.” The agent now edits only six files, which is progress in the same sense that a kitchen fire contained to one room is progress. It preserves the public API by introducing a private API whose only consumer is the public API. It runs the focused test, sees green, and congratulates itself before the typecheck points out that its new generic accepts undefined in a codebase that has spent nine years trying to prevent exactly that.

This is checkpoint two: the phase in which the agent understands the code but has not yet encountered the organization. It knows how to make a patch compile. It does not know that ClientOptions is copied into four SDKs, that the retry semantics are part of a contract test maintained by a team in another timezone, or that the word “simple” in the ticket was added after a previous incident involving a 900-line helper class.

Restore again. Do not negotiate with the patch. Do not ask it to “just fix the type errors,” because that request produces a third state: the same architecture plus casts. Instead, inspect the diff yourself for 45 seconds—the one interval nobody has yet managed to turn into an autonomous loop—and state the missing constraint. “No new abstraction. Keep the option internal. Match the existing retry test’s clock control.” This is not micromanagement. It is supplying the information that was only ever stored in the heads of people who have been paged at 02:13.

Checkpoint three: the agent receives a task instead of an archaeological site

On the third run, something mystical happens: the agent makes a small patch. It adds a branch beside the existing branch. It changes the focused test. It runs pnpm test src/client.test.ts and then pnpm typecheck. It stops. The patch is almost boring enough to merge. The Institute for Reversible Progress records this as an agent success, while carefully deleting the two earlier attempts from the quarterly dashboard so that the bar chart can continue pointing northeast.

This is why the third restore appears intelligent. The model did not necessarily acquire a new faculty between attempts. The task became narrower, the bad direction became visible, and the prompt accumulated repository-specific constraints. Each restore removed not just files but an attractive wrong plan. By attempt three, the agent is operating inside a trench you dug with the first two failures.

How to preserve the ritual without turning it into a lifestyle

  1. Before the first run, create a clean boundary: commit, stash, or at minimum run git status --short. A checkpoint is useful only if you can tell what was already yours.
  2. Ask for an implementation plan and the target files before granting broad write access. If the plan names a framework, a migration, or “centralized infrastructure” for a one-line bug, restore early and with feeling.
  3. After a restore, change one constraint, not twelve. “Do not alter the exported type” is actionable. “Please be more careful” is a request for the agent to simulate a concerned facial expression.
  4. Run the smallest relevant command before the full suite. A focused test that finishes in 8 seconds tells you whether the agent understood the behavior; a 19-minute monorepo command tells you that CI remains an important civic institution.
  5. Review the diff after the third attempt anyway. Rewind systems may restore only agent-modified files and can skip files you changed afterward; a clean-looking conversation is not the same thing as a clean working tree.

The limitation of the checkpoint economy

Checkpoints are bad at the part developers most want them to solve: deciding whether a change was conceptually right before it became syntactically extensive. They can restore a file state. They cannot restore the 11 minutes spent reading a generated lockfile diff, nor can they warn that the agent has interpreted “add observability” as “introduce a distributed tracing vendor to the local unit test.” A rollback button makes experimentation safer; it does not make broad, underspecified work cheap.

There is also a practical ceiling. Copilot CLI documents that file changes may not be captured for restoration when a single turn changes more than 500 files, and that restoration can skip files whose contents no longer match what the tool last wrote. This is exactly when the agent will confidently announce that it has “cleaned up related call sites.” Treat that phrase as a smoke alarm, not a completion signal.

The true observation beneath the joke is less glamorous: agents improve when the work has a tight scope, a fast verification command, and explicit constraints drawn from the codebase. The third checkpoint is not where intelligence arrives. It is where the task finally becomes small enough for anybody—or anything—to do well.

Sources & citations

  1. [1]Cline documentation — Tasks and checkpoints
  2. [2]GitHub Docs — Rolling back changes made during a GitHub Copilot CLI session
  3. [3]GitHub Docs — Canceling a GitHub Copilot CLI operation and rolling back changes