skip to content

When is re-running an agent with a corrected request cheaper than repairing the change it produced?

level: seniorimportance: nice to knowfreq 34%

answer

  1. Two routes out of a bad change
  2. Where does the defect live
  3. Repeated mistakes point at the premise
  4. A re-run discards the review
  5. The request gains a sentence either way

basics

~20 s

Re-run when the premise is wrong — a misread request or an unstated constraint — because that mistake is spread through every file. Repair when the premise holds and the defects are few. A re-run discards the review already done.

solid answer

~40 s

The question is where the defect lives, not how big the change is. If the same misunderstanding repeats across files, or the run was missing a fact it needed, the premise is wrong: repairing by hand means applying one edit several times and leaving it in everything you did not repair, so correcting the request and running again costs less. If the premise holds and the defects are few and unrelated, repair — and count what a re-run would cost, because it produces a different change rather than the same change minus the bug, so every part you had already accepted comes back unread. Decide before you start repairing; half-repairing and then re-running pays both costs. Either way, the request gains the sentence the review discovered.

go deeper

for a junior

Know there are two responses to a bad generated change — fix it, or ask again with a better request — and that the choice is made deliberately rather than by whichever feels faster at the time.

for a middle

Explain the difference between a defect in the premise and a defect in a few places, and why the same mistake repeated across files points at something the run believed rather than at carelessness.

for a senior

Show that you count review as a cost. A re-run discards the reading already done, because the second change will differ in places you had already accepted and must be read again.

for a principal

Own the loop that closes this: whichever route is taken, the request absorbs the sentence the review discovered, or the same misunderstanding returns on the next run of the same feature.

## The decision is about where the defect lives Faced with a change that is wrong, there are two routes: repair it by hand, or correct the request and run again. The instinct is to decide by size — small diff, repair it; nine files, start over. **Size is the wrong axis.** What matters is whether the defect sits in the premise the change was built on, or in a few specific places within a premise that is sound. A **premise defect** is a belief the run held throughout: a misread of what the feature is for, an invariant nobody told it about, a downstream consumer it did not know existed. It is not in one file. It is in every file it touched, including the ones you have already read and approved, and repairing it by hand means applying the same edit again and again while hoping you have found all of them. A **local defect** is a slip: a wrong branch, a missed edge case, an off-by-one. Two or three unrelated ones inside otherwise sound work are exactly what review is for, and repairing them preserves everything you have already read. | what you are looking at | what it points to | |---|---| | the same misunderstanding repeated across several files | re-run | | a fact the run never had — an invariant, a house rule, a consumer | re-run | | the shape is wrong; the feature was built around the wrong idea | re-run | | two or three unrelated slips in work that is otherwise sound | repair | | defects surrounded by code you have already read and accepted | repair | | the run already did something irreversible outside the repository | repair — a re-run is not a clean slate | ## The cost people forget "Just re-run it" sounds free because the running is cheap. **It is not free, because a re-run throws away the review.** A second run produces a *different* change, not the same change minus the bug. Files you had already read come back altered; the parts you accepted must be accepted again; and any improvement you made while reviewing the first change is gone unless it went into the request. So the real trade is your repair time against your reading time, and reading is usually the expensive one. That is what makes this a judgement call rather than a rule: on a change you have already read most of, repair often wins even when the defect is mildly systemic, because the remaining repair is bounded and the re-read is not. ## Decide before you start repairing The common bad outcome is paying both costs. Repair starts because the first defect looks local; the premise defect is discovered on the fourth one; the change is then re-run anyway and the repairs are discarded along with it. A cheap guard: **when you meet the second defect of the same kind, stop and make the decision explicitly.** One slip is a slip. Two of a kind is evidence about what the run believed, and belief is a premise defect until shown otherwise. Stopping at that point costs you nothing you would not have spent anyway. ## Either way, the request gains a sentence Whichever route you take, the review discovered something the request failed to say — the constraint the run had to guess at, the behaviour it invented, the consumer it did not know about. **Put that into the request even when you repair by hand**, because the request is what the next run on this feature will read. Repairing the code and leaving the request unchanged fixes this change and guarantees the next one repeats it. What a good request contains is a subject of its own; the point here is only that the review's finding belongs in it. ## What this is not - **There is no file-count threshold.** A large change with a sound premise and three local defects is worth repairing; a small one built on a misread request is not. - **It is not a verdict on the tool.** A premise defect usually means the run was missing something it had no way to obtain — most often from the request itself. - **It is not the question of when to give up on a loop.** How many attempts a non-converging session is worth is a separate subject; this is the one-shot decision about the change now in front of you. - **And re-running is not a way to avoid reviewing.** The second change gets the same read as the first, by the same person, against the same list of outcomes.

  • Does the size of the change decide between repairing and re-running?
    No. A large change with a sound premise and three local defects is worth repairing, while a small one built on a misread request is not. Size affects how expensive each route is, not which kind of defect you are facing.
  • You have repaired four files when you realise the premise is wrong. Now what?
    Stop and re-run, and treat the repairs as notes rather than as work wasted — each one told you something the request failed to say. Continuing costs the repair of every remaining file plus a full review of a change you already know is built on the wrong idea.
  • The run applied a migration before you reviewed anything. Does that change the decision?
    Yes. A re-run is only a clean slate for things inside the repository. Anything already applied outside it has to be reasoned about on its own terms, and that work is owed whichever route you take with the code.

saying these in an interview costs you the question

  • Re-running is free, so throw away anything that needs work
  • The number of files decides whether to repair or re-run
  • A re-run returns the same change with the defect removed
  • Repair the code and leave the request exactly as it was
  • A large generated change can never be repaired reliably by hand