Long-running coding agents need checkpoints, not just larger tasks

Duration is not the control

A coding agent that can keep working for longer does not automatically make a long task safer to delegate. For work that crosses files, layers, or decisions, I care less about how much code arrives in one run than whether I can inspect what happened along the way and choose what happens next.

That distinction matters as agents take on broader work. Anthropic’s Claude Opus 4.8 announcement describes dynamic workflows in Claude Code for larger tasks: the agent plans work, runs parallel subagents, and verifies outputs before reporting back. The announcement names codebase-scale migrations and refactors as examples. That is a useful opening, but the engineering question is not just whether a system can attempt more work. It is how a person stays in control when the work takes many steps.

I would not treat an agent’s internal plan, conversation history, or final summary as the authoritative record of a change. Those are useful inputs, but the repository is what I need to review. A good workflow leaves visible evidence in the files and history, sets clear points where a person can stop, and makes it possible to continue from the evidence rather than trusting a long session to remember everything correctly.

Make progress inspectable

A large task should be divided around meaningful changes, not arbitrary time intervals. A migration might have separate stages for identifying affected code, changing one bounded area, updating callers, and validating the result. A refactor might isolate a structural change from behavior changes. The exact boundaries depend on the task; the principle is to make each stage reviewable on its own.

I would ask the agent to state, before it starts, what it intends to change and what evidence would show that a stage is complete. Then I would have it stop after a bounded stage, summarize the files it changed, and report checks it actually ran. A summary is a navigation aid, not proof. I would inspect the diff and run or review the relevant checks myself before accepting the checkpoint.

For example, a checkpoint can be recorded as a normal commit after reviewing the staged changes:

git status --short
git diff -- path/to/change
git add path/to/change
git diff --cached
git commit -m "Complete bounded migration step"

This is a workflow sketch, not a command sequence to paste blindly: the path should name the intended files, and the staged diff should be checked before committing. I prefer checkpoints that describe a coherent state over one commit per tool call. A commit should make it easier to understand or recover the work, not merely prove that the agent was busy.

The checkpoint also needs a useful handoff. I would ask for the goal of the stage, decisions made, unresolved questions, changed files, checks run, and the next proposed step. That record should be short enough to read and specific enough to challenge. “Tests passed” is weak without saying which checks ran; “finished the refactor” is weak if the diff still contains unrelated changes. If the agent cannot clearly explain the state it is handing over, I would not ask it to continue yet.

Stop before uncertainty compounds

A stopping point is valuable when it gives a person a decision to make. It might be a choice between two data shapes, a change to an external contract, or a point where an automated check cannot establish the intended behavior. The agent should not silently turn an unresolved design choice into implementation simply because it can keep going.

That adds friction. I have to review intermediate work instead of waiting for a polished final result, and too many tiny checkpoints can turn a useful workflow into ceremony. I would set checkpoints where the cost of a wrong assumption rises: before a broad mechanical change, after the first representative slice, and before the change crosses an important boundary. Routine edits that are easy to review can stay together. Decisions with wide consequences should not be buried in a long, uninterrupted run.

Passing checks is one kind of evidence, not a substitute for judgment. A test suite can show that existing tests still pass; it cannot, by itself, prove that the agent chose the right migration boundary or preserved an unstated requirement. I would ask the agent to report the checks it ran and the gaps it could not resolve. If a required behavior has no test or other clear verification, that is a reason to pause and make the gap explicit, not to infer success from a green command.

This is also why I would keep the task’s acceptance criteria outside the agent’s private working state. Put them in an issue, a review note, or a file in the repository where another person can compare them with the diff. The agent can help refine the criteria, but its own account of completion should not be the only record of what completion means.

Resume from the repository

Long-running work will be interrupted: a person may stop it, a tool may fail, or a checkpoint may reveal a problem that needs correction. Resumption should start from a known repository state. I would ask the agent to inspect the current branch, working tree, recent commits, and relevant task notes before continuing. It should explain what it believes is complete and what remains, then wait for correction if that understanding is wrong.

I would not rely on a saved transcript alone. Conversation history can help recover intent, but it can also contain outdated assumptions or intermediate plans that no longer match the code. The committed diff, current tests, and an explicit handoff are better anchors. If those disagree with the old summary, I would trust the present repository and investigate the mismatch.

A practical instruction for the agent could be as direct as this:

Work on one bounded stage at a time.
Before each stage, state the intended change and how you will verify it.
After the stage, stop. Report changed files, decisions, checks run, and unresolved questions.
Do not continue past an unresolved design choice or failing check.
Resume only after inspecting the current repository state and confirming what remains.

The value is not in those exact words. It is in making the control points part of the workflow rather than hoping the agent will remember to offer them. I want the agent to do useful work independently, but I want the repository to preserve enough evidence that I can disagree, roll back, or redirect without treating the agent’s memory as the source of truth.

Longer tasks are worth delegating when the work stays legible while it is in progress. Larger task limits may let an agent attempt more; checkpoints let me decide whether the attempt is still going in the right direction.