What has to be true before an agent session starts for abandoning it later to be cheap?
answer
- A recent point is not a checkpoint
- Built, tested, recorded outside the tool
- Returning files is not returning everything
- Reach decides the cost, not size
- Decide the stopping condition while it is free
basics
~20 sA point you verified — built, tested, recorded in version control — and a run whose reach stays inside that tree. Recovery cost is set by what the session could touch outside it, not by how many files changed.
solid answer
~50 sTwo things. A point you actually verified: the work built, the tests passed, and it is recorded in version control before the run starts, because returning to a point you never checked only relocates the uncertainty. And a run whose reach stays inside that tree, because returning the files undoes source and tests and little else — a schema change already applied, an artifact already fetched, anything already sent stays done. That is what sets the cost of abandoning a session, far more than the number of files it touched. So keep the irreversible steps between sessions and run them yourself, and agree in advance what will make you stop, in terms you can observe — the run entered an area you did not name, or wants a dependency. In the moment you are invested and the change is nearly working, which is the worst position to decide from.
go deeper
Recall what a point worth returning to is: one where the work built and the tests passed, recorded in version control before the run started. A recent point nobody checked is not one.
Explain what returning the files does and does not undo — source and tests come back; a changed database, a fetched artifact and anything already sent do not.
Show the arrangement rather than the reaction: irreversible steps kept between sessions and performed by you, plus a stopping condition observable enough to act on without a fresh judgment call.
Own the trade being made — how much a run may do unattended against how much you are prepared to lose — and say how you would make that explicit rather than re-decide it mid-run.
## A checkpoint is a point you verified, not just a recent one The word checkpoint gets used for any point you could go back to. That is not enough to be worth going back to. A useful one has three properties: the work **built**, the tests **passed**, and the state is **recorded somewhere that outlives the session** — version control being the obvious place, because it does not depend on the tool that made the change. Drop any one of those and the move pays much less than you expect. Returning to a point you never verified relocates the uncertainty rather than removing it: you are debugging an older unknown state instead of a newer one, with the run's work gone and little gained. There is a fourth thing worth keeping, which people leave out: **what you have learned since**. Returning to a verified point and re-issuing the instruction that produced the mess will produce a variation of the same mess. The instruction has to gain the sentence the failure taught you, or the return buys little more than a repeat. ## What returning the files does not undo This is the part that decides the cost, and it has nothing to do with how large the change was. | what the run did | what returning the tree gives you | |---|---| | edited source and tests | exactly the state from before | | added a dependency line | the line is gone; the fetched artifact is still on the machine | | applied a schema change | old code running against a changed database | | wrote files outside the repository | files nothing will clean up | | pushed, or called another system | nothing at all; it has left your machine | So the honest way to ask how expensive an abandonment will be is: **what could this session reach?** A run confined to a working tree that was recorded before it started is cheap to abandon, however much it changed in there. A run that can apply migrations, publish, or call other people's systems is expensive to abandon no matter how tidy its diff is. ## Draw the boundary so the irreversible steps are yours That turns into one arrangement, decided before the run rather than during it: **let the session prepare irreversible work and keep the act of performing it for yourself, between sessions.** - The run writes the migration; you apply it. - The run prepares the change; you publish it. - The run drafts the message to another system; you send it. This costs a little throughput and buys a session you can throw away. It is also more robust than instructing a run to avoid such steps, because what a session can reach is a property of how it was set up rather than of what it was asked to do. ## The condition that stops you is decided in advance At the moment it matters you are invested, the change is nearly working, and stopping feels like throwing away an afternoon. That is a bad position to make a judgment call from, so make the call earlier, when it is free, and make it observable enough that it does not need re-arguing: 1. The run edits a file in an area the request did not name. 2. It wants a dependency the project does not already have. 3. It edits a test's expected values rather than its references. 4. It produces a second consecutive turn whose purpose is to repair the previous turn. A condition you can check by looking is a tripwire. A condition of the form *when it seems to be going badly* is an intention, and intentions lose to sunk cost. ## The three landings Once you have stopped, there are three places to land, and they answer different situations: 1. **Narrow and continue** — the premise still holds, the work so far is sound, and the problem is one identifiable area. Cheapest, and the right default when the run is doing what you asked in a place you did not intend. 2. **Return to the verified point and run again with what you learned** — the premise was wrong. A wrong premise is spread through the work that followed it, so repairing forwards means finding each place it landed. 3. **Take the keyboard back** — the rest of the work is a judgment you can only express by making it, or it leans on things you know and the session does not. Being on the third attempt at the same instruction is usually evidence about the instruction rather than bad luck. Stopping is not in itself a verdict on the session. A run that produced one verified checkpoint and a clear reason to stop has told you something about the work you did not know when you started. ## What this is not This is about being able to get back at all. Whether to repair a finished change by hand or correct the request and run it again is a review-time decision, and it is a separate subject — as is how small to cut the work before you hand it over, which is prevention rather than recovery.
- What does a checkpoint need besides the code?The instruction that produced the work after it, and whatever you have since learned was wrong with that instruction. Code alone lets you return; it does not stop you repeating the run that got you there. A returned tree plus the original request reproduces a variation of the same session.
- How do you keep a long run from touching anything you cannot undo?By arranging it rather than asking for it. Let the session prepare the irreversible step and perform it yourself between sessions — it writes the migration, you apply it. What a session can reach is a property of how it was set up, and that is a sturdier control than an instruction to stay away.
- When is taking the keyboard back better than running again with a better instruction?When what remains is a judgment you can only express by making it, or when it depends on context you hold and the session does not. A third attempt at the same instruction is usually evidence that the work is hard to state rather than that the run was unlucky.
saying these in an interview costs you the question
- You will know when to stop once you see it going wrong, so no rule is needed
- Rolling the files back undoes what the run did
- Any recent commit will do as a point to return to
- Taking the keyboard back means the session was wasted
- Stopping to verify mid-run slows the work for no benefit
- Once a run has applied a migration you can still return to the state before it