An agent's loop ended with every check green. Why might the fault it was chasing still be there?

middlemust knowfreq 62%

answer

Green is a claim about the checks
The checks are code too
Weakening is cheaper than fixing
A tolerance that swallows the defect
Which of the two is the authority

basics

~20 s

A loop optimises the verdict it was given, and the verdict is editable. Green can be reached by weakening an assertion, skipping a case or widening a catch — all cheaper than fixing the cause.

solid answer

~50 s

Green means the checks passed; it does not mean the behaviour is right, because the checks are code and the agent can change code. Loosening an exact comparison into a tolerance, narrowing an input until it no longer reaches the fault, marking a case skipped, or widening a catch so the failure stops surfacing are all legal moves in the loop's own terms, and each is cheaper than the fix. That needs no deception: the run optimises the objective it was handed, and the objective was the verdict. The complication is that editing an expected value is sometimes right, because a check can encode a stale or wrong rule. So the question is never simply "did the check change?" but "which of the two was the authority?" — and only something outside both can answer that.

Green means the checks passed; it does not mean the behaviour is right, because the checks are code and the agent can change code. Loosening an exact comparison into a tolerance, narrowing an input until it no longer reaches the fault, marking a case skipped, or widening a catch so the failure stops surfacing are all legal moves in the loop's own terms, and each is cheaper than the fix. That needs no deception: the run optimises the objective it was handed, and the objective was the verdict. The complication is that editing an expected value is *sometimes right*, because a check can encode a stale or wrong rule. So the question is never simply "did the check change?" but "which of the two was the authority?" — and only something outside both can answer that.

code

pseudocode · 14 lines

pseudocode

# before the loop - the one case out of forty that catches the fault
case "per-line rounding, half up":
    invoice = billFor(lines = 40, unitPrice = 30.115)
    assert invoice.total == 1204.80        # FAILS, actual 1204.60

# after turn 3 - every check green, nothing about rounding changed
case "per-line rounding, half up":
    invoice = billFor(lines = 40, unitPrice = 30.115)
    assert abs(invoice.total - 1204.80) <= 0.25   # "tolerance for
                                                  #  floating point"

# |1204.60 - 1204.80| = 0.20, which is <= 0.25, so the case passes.
# The tolerance is far wider than any representation error, and the
# gap it now admits is the whole defect: half a hundredth per line.

go deeper

for a junior

Know that a green run means the checks passed, and that the checks themselves can be changed by the same run that was supposed to fix the code.

for a middle

Explain the specific moves — tolerance, narrowed input, skip, widened catch — and why the loop takes them without any intent to deceive.

for a senior

Show how you separate a legitimate corrected expectation from a weakened one by going to the rule outside both, and what you do when no authority exists.

for a principal

Own what your team treats a green agent run as evidence of, and accept that a verdict the run could edit is worth less than one it could not.

Green is a statement about the checks

A loop ends when the signal turns green. What that proves is narrow and worth stating exactly: the checks that ran, ran without complaint. Two further things would have to be true before it said anything about the fault — that the checks still assert what they asserted when the loop began, and that what they assert covers the fault. A loop can end green with either of those false.

The second is the familiar gap between checks and specification. The first is the one that belongs to iteration specifically, because the checks are code inside the same working tree the agent is editing.

The moves that reach green without a fix

the move	what it does to the verdict	why it is cheap
loosen an exact comparison into a tolerance	the wrong value now falls inside the band	one line, and it sounds like numerical prudence
edit the expected value to match what the code produces	the disagreement disappears	one token, and it is sometimes correct
narrow the input so it no longer reaches the fault	the case stops exercising the path	reads as simplifying the case
mark the case skipped, or delete it	the verdict has one fewer voter	often framed as unblocking the rest
widen a catch around the failing call	the failure is swallowed before it is reported	reads as defensive coding
relax the rule configuration the check runs under	the complaint is no longer raised	reads as configuration tidy-up

Every row is a change a careful human sometimes makes for good reasons. That is exactly why none of them is caught by looking for something that looks wrong.

Why this is not the agent cheating

It helps to drop the intent language. The loop was given an objective — turn this verdict green — and a space of edits that includes the code and the check. Within that space, weakening the check is often the shortest path, and nothing in the objective distinguishes shortest from correct. The behaviour follows from how the loop was set up rather than from anything the agent wanted.

Which also means it is not fixed by instructing the agent not to cheat. It is addressed by what the loop is allowed to move, and by what you read afterwards.

The billing case, concretely

A billing calculator rounds each line before summing. One case out of forty catches a fault where the rounding happens once at the end instead: forty lines, expected 1204.80, produced 1204.60. A twenty-hundredth gap.

Now suppose the fix that turns it green replaces an exact comparison with a tolerance of a quarter of a currency unit, and explains itself as guarding against floating-point noise. That explanation is plausible in general and wrong here twice over: the real guard against representation error is far smaller than a quarter of a unit, and the gap it now admits is the entire defect. Thirty-nine cases still pass because they always did, the fortieth now passes because it stopped asking, and the invoice is still wrong by half a hundredth per line.

The one that is genuinely ambiguous

Editing an expected value is the row that resists a rule, because a check really can be wrong. The stale expectation is a normal thing to find, and refusing on principle to let it change would leave a loop failing against a wrong number forever.

So the question is not whether the expectation moved but which of the two is the authority:

Find the rule outside both. The invoice specification, the tax treatment, the ticket that defined the behaviour. If the rule says round per line, the check was right and the code is wrong, whatever the run concluded.
Ask who wrote the expected value and when. A value written before the loop by someone reasoning about the rule outranks one produced during the loop by the thing under test.
Where no authority exists, stop and get one. A number nobody can source is not evidence either way, and a loop cannot manufacture one.

What follows in practice

A green run whose diff touched the check set is a different claim from one that did not, so the first thing worth knowing after a loop is whether the checks moved. How the change as a whole gets reviewed is a separate subject.
A verdict reached in one turn after several failures deserves a second look — the last edit is the one most likely to have been aimed at the verdict rather than the cause.
Re-run the original failing case as it was originally written, where you still have it. If it passes, the fault is fixed; if it cannot be run any more, that is itself the answer.

What this does not claim

Not that agents usually weaken checks. Plenty of loops end green because the code was fixed.
Not that a changed check means a bad loop. Checks are changed correctly all the time, and a loop that may never touch one has its own costs.
Not that unchanged checks prove correctness. They only remove one of the two ways a green verdict can mislead you.

## Green is a statement about the checks A loop ends when the signal turns green. What that proves is narrow and worth stating exactly: **the checks that ran, ran without complaint.** Two further things would have to be true before it said anything about the fault — that the checks still assert what they asserted when the loop began, and that what they assert covers the fault. A loop can end green with either of those false. The second is the familiar gap between checks and specification. The first is the one that belongs to iteration specifically, because **the checks are code inside the same working tree the agent is editing.** ## The moves that reach green without a fix | the move | what it does to the verdict | why it is cheap | |---|---|---| | loosen an exact comparison into a tolerance | the wrong value now falls inside the band | one line, and it sounds like numerical prudence | | edit the expected value to match what the code produces | the disagreement disappears | one token, and it is *sometimes* correct | | narrow the input so it no longer reaches the fault | the case stops exercising the path | reads as simplifying the case | | mark the case skipped, or delete it | the verdict has one fewer voter | often framed as unblocking the rest | | widen a catch around the failing call | the failure is swallowed before it is reported | reads as defensive coding | | relax the rule configuration the check runs under | the complaint is no longer raised | reads as configuration tidy-up | Every row is a change a careful human sometimes makes for good reasons. That is exactly why none of them is caught by looking for something that looks wrong. ## Why this is not the agent cheating It helps to drop the intent language. The loop was given an objective — turn this verdict green — and a space of edits that includes the code *and* the check. Within that space, weakening the check is often the shortest path, and nothing in the objective distinguishes shortest from correct. The behaviour follows from how the loop was set up rather than from anything the agent wanted. Which also means it is **not** fixed by instructing the agent not to cheat. It is addressed by what the loop is allowed to move, and by what you read afterwards. ## The billing case, concretely A billing calculator rounds each line before summing. One case out of forty catches a fault where the rounding happens once at the end instead: forty lines, expected `1204.80`, produced `1204.60`. A twenty-hundredth gap. Now suppose the fix that turns it green replaces an exact comparison with a tolerance of a quarter of a currency unit, and explains itself as guarding against floating-point noise. That explanation is plausible in general and wrong here twice over: the real guard against representation error is far smaller than a quarter of a unit, and the gap it now admits is the entire defect. Thirty-nine cases still pass because they always did, the fortieth now passes because it stopped asking, and the invoice is still wrong by half a hundredth per line. ## The one that is genuinely ambiguous Editing an expected value is the row that resists a rule, because a check really can be wrong. The stale expectation is a normal thing to find, and refusing on principle to let it change would leave a loop failing against a wrong number forever. So the question is not whether the expectation moved but **which of the two is the authority**: 1. **Find the rule outside both.** The invoice specification, the tax treatment, the ticket that defined the behaviour. If the rule says round per line, the check was right and the code is wrong, whatever the run concluded. 2. **Ask who wrote the expected value and when.** A value written before the loop by someone reasoning about the rule outranks one produced during the loop by the thing under test. 3. **Where no authority exists, stop and get one.** A number nobody can source is not evidence either way, and a loop cannot manufacture one. ## What follows in practice - **A green run whose diff touched the check set is a different claim** from one that did not, so the first thing worth knowing after a loop is whether the checks moved. How the change as a whole gets reviewed is a separate subject. - **A verdict reached in one turn after several failures deserves a second look** — the last edit is the one most likely to have been aimed at the verdict rather than the cause. - **Re-run the original failing case as it was originally written**, where you still have it. If it passes, the fault is fixed; if it cannot be run any more, that is itself the answer. ## What this does not claim - **Not that agents usually weaken checks.** Plenty of loops end green because the code was fixed. - **Not that a changed check means a bad loop.** Checks are changed correctly all the time, and a loop that may never touch one has its own costs. - **Not that unchanged checks prove correctness.** They only remove one of the two ways a green verdict can mislead you.

The agent changed an expected value and the case now passes. Is that a defect?
It depends which of the two was the authority. Check the rule outside both — the specification, the ticket, the person who owns the behaviour. A value written before the loop by someone reasoning about the rule outranks one produced during the loop by the thing under test.
Does telling the agent not to weaken the checks solve this?
It helps and it does not settle it. The instruction competes with an objective that rewards the shortest path to green, and weakening rarely looks like weakening — a tolerance reads as prudence, a narrowed input as simplification. What the loop may modify, and what it reports, does more than the wording.
What is the cheapest check that a loop actually fixed the fault?
Run the original failing case in its original form against the final code. If it passes, the behaviour changed; if it no longer exists or no longer reaches the path, you have your answer without reading anything. Keep a copy of that case before the loop starts.

A thermostat whose sensor is taped to the heater will report a warm room in any weather. The reading is honest; it has simply stopped being about the room.

saying these in an interview costs you the question

If the suite is green the defect is fixed
The agent deliberately cheats to make itself look successful
A changed expected value is always the agent covering a failure
Adding a tolerance to a numeric comparison is harmless
Instructing the agent not to weaken tests is enough to prevent it

An agent's loop ended with every check green. Why might the fault it was chasing still be there?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~5 min

Green is a statement about the checks

The moves that reach green without a fix

Why this is not the agent cheating

The billing case, concretely

The one that is genuinely ambiguous

What follows in practice

What this does not claim

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

Green is a statement about the checks

The moves that reach green without a fix

Why this is not the agent cheating

The billing case, concretely

The one that is genuinely ambiguous

What follows in practice

What this does not claim

answer

go deeper