skip to content

Four turns in, each fix breaks a neighbouring case — how do you tell a stalled loop from a converging one?

level: seniorimportance: should knowfreq 48%

answer

  1. Track the failing set across turns
  2. Sideways, not smaller
  3. Same value pushed between two sites
  4. New fact or same fact, new shape
  5. Set the stopping rule before turn one

basics

~20 s

Watch the failing set, not the last message. A converging loop shrinks it and keeps it shrunk; a stalled one moves it sideways — same size, different members. Fix the stopping condition before turn one, while the sunk cost is small.

solid answer

~50 s

Judge the loop by what the signal does across turns rather than by how the latest turn reads. Converging looks like a failing set that gets smaller and stays smaller, with each failure telling you something the previous turn did not. Stalling looks like the same count with different members, an assertion failing on a new value each turn, or a change that grows while the failing set does not shrink. The discriminator is whether a new failure is a **new fact** — a second real defect the fix exposed, which is progress — or the same fact wearing a different shape. Set the stopping rule before the first turn: a turn budget, or a condition such as *the failing set must be strictly smaller after two consecutive turns*. Pre-commit because each individual turn is the cheapest next action available, so continuing rarely feels wrong at the time.

code

text · 12 lines
text
turn 2   FAIL  perLineRounding_halfUp    expected 1204.80   actual 1204.60
               39 other cases green

turn 3   FAIL  creditNote_negativeLine   expected  -18.06   actual  -18.05
               perLineRounding_halfUp now green

turn 4   FAIL  perLineRounding_halfUp    expected 1204.80   actual 1204.40
               creditNote_negativeLine now green

One case red every turn, never the same case twice running, and turn 4
case from turn 2 missing by a different amount. The count never moved
and neither did the defect - only where the rounding happens.

go deeper

for a junior

Know that a loop can run for turns without getting closer, and that the thing to watch is which checks are red across turns rather than the latest explanation.

for a middle

Explain the sideways pattern — same count, different members, the same value pushed between two sites — and why a rising count is not by itself a stall.

for a senior

Show the pre-committed rule you set before the first turn and why it has to be set then, and demonstrate the new-fact test on a failure that appeared after a fix.

for a principal

Own the stopping policy as something a team agrees in advance rather than each developer deciding under sunk cost, and decide what a stalled loop must leave behind for whoever picks the work up.

## Judge the sequence, not the turn Any single turn of an agent loop reads reasonably. The agent explains what it found, makes a plausible change, and the run comes back with a result. Stalling is not visible in one turn; it is a property of the **sequence**, and you only see it if you are tracking something across turns. The thing to track is the **failing set**: which named checks are red, not how many. Counts hide the failure mode entirely, because the characteristic stalled loop holds the count perfectly steady. ## What converging actually looks like - The failing set gets **smaller and stays smaller**. Cases that went green last turn are still green. - Each new failure carries **information you did not have** — a different assertion, a different module, a genuinely different cause. - The change is **not growing faster than the progress**: the diff after turn three is not three times the diff after turn one for the same one remaining failure. - The agent's explanation is getting **narrower**, converging on a mechanism rather than producing a new theory each turn. ## What stalling looks like - The failing set **moves sideways**: same size, different members. Case A is fixed, case B breaks; B is fixed, A breaks again. - The same case fails with a **different actual value** each turn, which means the value is being pushed around rather than derived. - The **diff grows every turn while the failing set does not shrink** — new helpers, new branches, new configuration, all in service of a verdict that has not moved. - The change starts **reaching outside the unit** you asked about, because the nearby code is now the obstacle. - Each turn offers a **new confident explanation** and none of them is ever checked; the previous one is neither confirmed nor retracted. ## The discriminator: a new fact, or the same fact in a new shape Sideways movement is not automatically a stall, and this is the judgement the question is really asking for. A fix that exposes a second genuine defect looks identical to thrash for exactly one turn. The way to tell them apart: 1. **Read the new failure as a claim about the system.** Is it something you did not know before — a different rule, a different boundary, a case nobody had considered? 2. **Ask whether the earlier fix was right on its own terms.** If it was, and something else broke, you have discovered a coupling. That is knowledge, and knowledge is progress even when the count went up. 3. **Ask whether the same value keeps moving.** A total that was too low, then too high, then too low again is one defect being traded between two sites, not two defects. In a billing calculator where one case out of forty catches a rounding fault, the stalled version is unmistakable once you lay the turns side by side: per-line rounding fails, gets fixed, a credit-note case breaks, that gets fixed, and per-line rounding fails again on a different number. Nothing was learned; the rounding was moved. | observation across turns | reading | |---|---| | failing set shrinks and stays shrunk | converging | | a new failure in a different module, first time seen | probably a real second defect | | same case, new actual value, third time | one defect being pushed between sites | | set stays the same size, members alternate | stalled | | diff grows, failing set flat | stalled, and now expensive to undo | ## Why the rule has to be set before turn one Every individual next turn is the cheapest action available. You have context loaded, the agent has a theory, and the marginal cost of one more attempt is small — while everything already spent argues for continuing. So the decision to keep going rarely feels wrong at the time, and a rule invented at the moment of doubt will be argued with. Set it in advance, in whatever form you will actually honour: - **A turn budget** for this unit of work, fixed before the first prompt. - **A monotonicity rule**: if the failing set is not strictly smaller after two consecutive turns, stop. - **A scope rule**: if the change reaches a file outside the unit you asked about, stop. - **A wall-clock rule**, which is cruder but survives your own reasoning better than the others. None of these is a claim that the loop would not have succeeded on the next turn. They are a bet that the expected cost of finding out has stopped being worth it — and a bet made in advance is the only one made on the evidence rather than on the sunk cost. ## Stopping is a decision, not the end of the work What you do once you stop — which earlier state you return to, and who takes the keyboard — is a separate subject with its own answers. The part that belongs to the loop is narrower: **notice that the signal has stopped improving, and stop on a rule you set when you could still think clearly.**

  • A fix exposes a failure in a module nobody had touched. Stall or progress?
    Probably progress, on one condition: the earlier fix has to be right on its own terms. Then you have found a coupling you did not know about, which is knowledge even though the count rose. Treat it as a stall only when the same value keeps moving between the same two sites.
  • Is a turn budget enough on its own as a stopping rule?
    It is the weakest of the useful rules, because it fires on cost rather than on evidence. A condition on the failing set fires when the loop stops making progress, which is the thing you actually care about. Keep the budget as a backstop behind it.
  • Can you tell a loop is stalled from the agent's own account of its progress?
    Not reliably. The account is generated from the same session that produced the changes, and it will usually read as steady progress. The failing set is the observation that comes from outside it, which is why you track that instead.

saying these in an interview costs you the question

  • If the last turn explained the cause well, the loop is converging
  • One more turn is always worth it once this much is invested
  • A rising failure count is by itself proof the loop is going nowhere
  • Decide when to stop once it starts feeling unproductive
  • Ask the agent whether it is making progress and go by the answer