You approved every turn of an agent session, so why is the finished change one you would not approve?
answer
- Each turn is judged from the previous turn
- The reference point moves with the change
- Locally right, cumulatively somewhere else
- Watch for turns that repair the last turn
- Read the whole session, not the last turn
basics
~20 sEach turn is judged against the state the turn before it left, so the baseline moves with the change. A turn that repairs the previous turn's side effect is locally right and carries the session further from what you asked.
solid answer
~50 sApproving a turn asks whether this edit makes sense given where the session now is — and where it is was produced by the edit you approved a moment ago. The reference point moves with the change, so a chain of locally sound turns can land somewhere you would have refused outright at the start. The shape is easy to recognise once it has a name: a turn whose purpose is to repair the previous turn's side effect rather than to advance the goal. One of those is ordinary. Three in a row is a run that has stopped advancing and started coping. The check is cumulative rather than incremental — every so often, read everything the session has changed since it began against the goal you set, because that is the comparison no individual turn makes.
code
pseudocode · 17 lines# turn 1 - requested: rename the field `status` to `state`
function Order.currentState():
return this.state
# turn 2 - a stored-record test failed, so the old key stays readable
function Order.currentState():
if this.state is null:
return this.status # older records still carry `status`
return this.state
# turn 3 - two paths now disagree, so both keys are written
function Order.save():
this.status = this.state # keep the two in step
store.write(this)
# each turn answers the problem the turn before it created;
# the request asked for a rename, and there are now two fieldsgo deeper
Recall that approving each step is not the same as approving where the steps lead. Be able to name the shape: a turn that exists to fix what the last turn broke.
Explain why local approval does not compose — each turn is graded against the state the previous turn left, so the reference point moves and the distance travelled is invisible from any single step.
Show the working practice: a cumulative read against the original goal on a cadence, and a fix aimed at the first decision in the chain rather than the most recent turn.
Own the incentive problem: having approved the step that made the next step reasonable, a reviewer is being asked to reopen their own decision, which is a weaker position than judging something new.
## The baseline moves with the change When you approve a turn, the question you are answering is *given where this change now stands, is this edit reasonable?* It is a fair question and the answer is usually yes. The problem is the first half of it. Where the change now stands is not where it stood when you wrote the request — it is wherever the turn you approved a moment ago left it. Each approval moves the reference point, and each subsequent judgment is made from the new one. That is why a sequence of reasonable turns can arrive at an unreasonable change. **No single turn looks like the defect**, because what has gone wrong is the distance travelled, and distance is not visible from any one step. ## A rename that became a compatibility layer The request was to rename one field. What came back, over three turns, was this: 1. The field is renamed in the model and its callers updated. Correct, and exactly what was asked. 2. A test that loads older stored records fails, because those records carry the old key. The run adds a fallback so the old key is still readable. Sensible: the test passes and no data is lost. 3. Two code paths now disagree about which key is authoritative, so the run writes both on save, keeping them in step. Also sensible, given step 2. What you asked for was a rename. What you have is a field with two names, a fallback path, and a write that maintains both — a small compatibility layer that nobody decided to build. | turn | the question it answered | the question nobody was asked | |---|---|---| | 1 | rename the field | — | | 2 | why did the stored-record test fail? | should old records stay readable under the old key? | | 3 | why do two paths disagree? | should we be writing both names? | The right-hand column is where the change was actually decided, and none of it was decided by you. Each of those decisions arrived as an edit rather than as a question, which is what makes them easy to approve. ## Why turn-by-turn approval does not compose Approving increments feels stricter than reviewing the whole change at the end, because it is more frequent. It is stricter in one direction and blind in another. Frequent local review catches an edit that is wrong in itself. It does not catch a series of edits that are each right in themselves, because each one is graded against a baseline the previous one set. There is a second effect worth naming. Having approved turn two, you are now a co-author of the state that makes turn three reasonable. Rejecting turn three means reopening a decision you already made, which is a harder position to judge from than being handed something new. ## The shape to watch for - **A repair turn.** Its purpose is to fix a consequence of the previous turn rather than to move toward the goal. One is ordinary — work has consequences. - **Repair turns in a row.** Two is worth a look, three is the run coping rather than advancing. - **A reason that points backwards.** *Because of the change we just made…* is the run explaining itself from inside the session rather than from your request. - **Growth in kind rather than in size.** A fallback, then a normaliser, then a default for the fallback: each is a new mechanism, not more of the same edit. ## What to read, and when 1. **Set a cadence, not a rule per turn** — every so often, or whenever the run reports something finished. 2. **Read everything the session has changed since it started**, in one view, rather than the most recent turn in more detail. 3. **Read it against the goal as you stated it**, not against the last turn's summary of the goal. Summaries inside a session drift toward what the session has been doing. 4. **When you find a chain, look at its first repair**, not its last. The later turns exist to keep an earlier decision consistent, so removing them alone leaves the same problem to be solved again. This is not expensive. A cumulative view every few turns costs one read; it is the per-turn reading that is expensive, and it is the per-turn reading that misses this. ## What this is not Not every follow-on edit is compounding. A rename has to update its callers, and a new branch may genuinely need a helper to hold it; those are consequences of what you asked for, and filing them as drift buries the real finding in noise. The distinguishing question is whether the turn advances the goal or repairs the last turn. And this is about noticing the chain while it forms. What to do with a finished change once you have read it — repair it by hand, or correct the request and run again — is a review-time decision and a separate subject.
- Is reviewing each turn as it happens worse than waiting for the finished change?Not worse — differently blind. Per-turn review catches an edit that is wrong in itself, which a single end-of-run read can miss in a large diff. It cannot catch distance travelled. The two answer different questions, and a cumulative read every few turns is what covers the gap between them.
- You find the chain at turn nine. Do you undo turn nine?Undoing the last turn usually leaves the reason it existed, so the problem comes back on the next turn. Look for the first turn that answered a question you would have answered differently — commonly the first repair — and decide that question yourself. The turns after it are consequences of it.
- Could you just tell the agent not to make decisions like that?Partly. Naming what it must stop and ask about, rather than decide, genuinely reduces the chain — but only for the cases you thought of in advance, and compounding is made of the ones you did not. Treat an instruction as narrowing the problem and the cumulative read as the thing that catches the rest.
saying these in an interview costs you the question
- If every individual turn is correct, the finished change is correct
- Approving turn by turn is strictly safer than reviewing the change at the end
- The agent would stop once the sequence stopped making sense
- Compounding means the agent made mistakes, so each turn was wrong
- Undoing the last turn puts the change back on track
- A chain of repairs is the cost of a big change and cannot be avoided