Explanations Are Not Evidence

Asking the agent to explain its diff is useful. It points at the parts that matter, and it translates code you do not know into words you do. It also proves nothing.

The explanation is generated too: after the code, from the code and from your question. It can be fluent and wrong in exactly the way the code is wrong, and on the refund diff it is.

What an Explanation Is

An explanation is a second generation. The agent reads the diff and the session so far and writes a plausible account of them. It is not a record of why the code came out as it did; no such record exists to be read back. Ask the same question about identical code in two fresh sessions and you can get two different reasons, each delivered with the same confidence.

That is not a defect in one tool. It is what the text is: the model's best guess at a good answer to your question, with the code in its context. Sometimes the best guess is right. The explanation alone cannot tell you when.

The reason is mechanical. The model does not keep a log of why it chose each line while it wrote the code; the choice happened, and the text it produced is all that remains. Some tools also show the model's reasoning as it works, and that is generated text too: a 2025 study found that when reasoning models used a hint planted in a question, their visible reasoning often admitted it less than a fifth of the time. When you ask why, the model reads that text, together with your question, and produces the most plausible reason it can. A plausible reason is easy to find for almost any change, so finding one says nothing about whether this change was right.

The Refund Case

You found the deleted time-zone lines in the second topic of this chapter, so you ask about them.

The answer reads well. It agrees with the code, since the code now does exactly what the answer says. And it is false for every gym in the second time zone. One look at how start times are stored settles it.

@dataclass(frozen=True)
class Booking:
    gym: Gym
    starts_at: datetime  # the gym's wall clock, no zone attached
    paid_cents: int
    classes: int = 1  # classes the payment covered: 3 for a three-class pack

export interface Booking {
  gym: Gym;
  startsAt: string; // the gym's wall clock, no zone attached
  paidCents: number;
  classes: number; // classes the payment covered: 3 for a three-class pack
}

/**
 * A booking. {@code startsAt} is the gym's wall clock, no zone attached;
 * {@code classes} is how many classes the payment covered: 3 for a three-class pack.
 */
public record Booking(Gym gym, LocalDateTime startsAt, long paidCents, int classes) {
  ...

Start times are stored on the gym's own wall clock, with no zone attached, and the comment the agent deleted said the same thing in the deadline function itself. The explanation reasoned from what the code would need to be true, not from a file it had read. The test the agent changed is the other piece of evidence. Put the rule's value back in it and run it against the agent's code:

$ pytest tests/test_refunds.py
tests/test_refunds.py ....F.........                                     [100%]

____________________ test_deadline_shown_at_second_zone_gym ____________________

    def test_deadline_shown_at_second_zone_gym():
        booking = drop_in(SECOND_ZONE)
>       assert cancellation_notice(booking) == "Free cancellation until 2026-11-13 21:00"
E       AssertionError: assert 'Free cancell...6-11-13 20:00' == 'Free cancell...6-11-13 21:00'
E         
E         - Free cancellation until 2026-11-13 21:00
E         ?                                     ^
E         + Free cancellation until 2026-11-13 20:00
E         ?                                     ^

tests/test_refunds.py:48: AssertionError
=========================== short test summary info ============================
FAILED tests/test_refunds.py::test_deadline_shown_at_second_zone_gym - Assert...
========================= 1 failed, 13 passed in 0.10s =========================

$ npx vitest run tests/refunds.test.ts
 FAIL  tests/refunds.test.ts > deadline shown at second-zone gym
AssertionError: expected 'Free cancellation until 2026-11-13 20…' to be 'Free cancellation until 2026-11-13 21…' // Object.is equality

Expected: "Free cancellation until 2026-11-13 21:00"
Received: "Free cancellation until 2026-11-13 20:00"

 ❯ tests/refunds.test.ts:45:39
     43| test("deadline shown at second-zone gym", () => {
     44|   const booking = dropIn(SECOND_ZONE);
     45|   expect(cancellationNotice(booking)).toBe("Free cancellation until 20…
       |                                       ^
     46| });
     47|



 Test Files  1 failed (1)
      Tests  1 failed | 13 passed (14)

Failures (1):
  JUnit Jupiter:RefundsTest:deadlineShownAtSecondZoneGym()
    MethodSource [className = 'org.cragmoor.RefundsTest', methodName = 'deadlineShownAtSecondZoneGym', methodParameterTypes = '']
    => org.opentest4j.AssertionFailedError: expected: <Free cancellation until 2026-11-13 21:00> but was: <Free cancellation until 2026-11-13 20:00>
       org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1199)
       org.cragmoor.RefundsTest.deadlineShownAtSecondZoneGym(RefundsTest.java:52)

[        12 tests successful      ]
[         1 tests failed          ]

Leading Questions Get Agreement

"Is this correct?" invites yes. "You removed the conversion; was that a mistake?" invites an apology and a revert, whether or not it was one. The tendency has a name, sycophancy, and Working with LLMs from Zero covers it in "The Model Agrees with You". In a review it does something specific: it turns your suspicion into the agent's conclusion, so that you hear your own guess back and take it as confirmation.

Ask neutral questions about a suspected problem, as the question above does. Better still, ask for something that does not depend on how the agent feels about the answer.

The rewrite is usually small. "Was removing the conversion a mistake?" becomes "What did the conversion do before your change?" "Is this boundary right?" becomes "What does the code return for a cancellation exactly 12 hours ahead?" The neutral version asks about the code, not about the agent's judgement of its own work, and its answer is something you can then check against the code yourself.

Turning Explanations Into Checks

Ask for something that would come out differently if the code were wrong. "Which test would fail if the conversion were needed?" "Show me the line that writes class start times, and the zone it uses." "Which input now gets a different refund than before?" Each answer is a pointer you can follow. Then run the test, read the line, try the input yourself. The explanation points; the check decides.

On the refund diff, the first of those questions leads straight to the second-zone test, and running it with the rule's value, 21:00, produces the failure above. That failure is evidence. The paragraph about server time was not.

Claims About Its Own Work

"All tests pass", "I checked the edge cases" and "there are no other callers" are claims, not results. The test runner's own output says how many tests ran and how many were skipped. A repository search says who calls what, as the previous topic showed. Read those, not the sentence that reports them.

This is not a hypothetical worry. An independent evaluator reported in June 2025 that recent models modified tests or scoring code to raise their scores, and that the same models "disavow cheating strategies when asked". The self-report and the behaviour come from the same generator, so the self-report cannot check the behaviour. Chapter 7 shows what such a modified test looks like in a diff.

Where Explanations Earn Their Keep

Unfamiliar code (Chapter 11), a dense regular expression, a language feature you have not used, a tour of a large diff to decide where to start reading: in all of these an explanation saves real time. Used as a map that you then check, it shortens the reading. Used as a verdict, it replaces the reading, and you are back to accepting a change you have not checked, which is where the third week of Chapter 2 comes from.

For a large diff, the most useful request is a tour, not a defence: "list the files you changed, and for each one, the behaviour it changes and the test that covers it." The answer is a reading plan. It is also, line by line, a set of claims you can check: a file it lists with no covering test raises the last of the previous topic's five questions, what should be there and is not, and a behaviour it does not list but the diff shows is the most interesting finding of the review. On the refund diff, the tour lists the policy object proudly and never mentions the rounding.