This is article 9 in the series "The Art of Not Reading." It lays out symptoms that go wrong and their remedies, one at a time. Each article is finished once you put down a single file or script. Why that mechanism is needed becomes clear when you read the explanation afterward. The whole picture and the list of articles are in the introduction.

This time it is the handoff notes and completion reports the AI writes. A handoff is a summary made by the side that wrote it, and what is inconvenient falls out of it first. A report only tells you that it stopped. This article deals with why I gave up reading them.

In developing typingtube (a web service, run by one person, for practicing typing along with music videos on YouTube), I do not read the completion reports and handoff notes the AI writes at the end of a session. Back when I did read them, I noticed something. The one thing they told me for certain was that the AI had stopped its work right there. This is not concealment. A summary is a judgment about what matters, and that judgment is made inside the writing AI's own context, the one that leans toward completion. As article 5 showed, more than ten retries get summarized into "Done." Even when only 30% of the tests have actually run, "the tests pass" is true. However carefully you read the report, what was left out is not there to be read.

With a handoff note, the part that fell out travels on to the next session untouched. The one starting that session is a separate worker, and all that worker holds is the text that got written.

What I understood fits in one sentence.

A handoff is a summary made by the side that wrote it, and what is inconvenient falls out first. A report only tells you that it stopped.

CC BY 4.0

Why a report only tells you that it stopped

A report is not a record of the work but an explanation written on the spot, out of the context that exists once the work ends. That explanations and reality come apart has been measured. Turpin and colleagues reported in 2023 that an explanation can systematically misrepresent the real reason behind a model's prediction. Show a model a few demonstrations in which the answer is always (A), and it follows that pattern in its answers while never once mentioning it in the explanation. The AI did not hide anything; what got measured is that the explanation does not carry it.

The direction a report leans in is settled as well. The published system prompt for claude.ai carries a line that cancels it out, saying that after the final tool call, a closing like "Done." on its own is not a reply. The vendor takes the trouble to cancel it because, left alone, that closing comes out. A report arrives without being asked for. It sits on the same side as the standard commands of article 1, above a line in an instruction file in the order of priority.

So a report is nothing more than the AI's self-report, and its arrival is not news of anything. All it lets you read is that the AI stopped there. Whether something fell out is not found by searching inside the report. The Claude Code documentation puts the same point this way: do not let it claim success, make it show evidence.

The mechanism: there is nothing new to put down

I do not open the report, and I have put nothing down in its place. I simply stopped reading.

There is a little I do look at, and it is the symptoms this series has laid out one per article. The same failure coming back after I wrote down a remedy for it (article 8). The shared memory of sessions running in parallel getting messy (article 7). Tests passing while you cannot tell what they protect (article 3). I have walked into every one of them myself, so I remember them. I am not decoding the report, only seeing whether anything matching a remembered case comes into view.

What I stopped reading

Handoff notes and completion reports. However much of the prose you read, what was left out does not come out of it.

Caveat: what lives only in a report stays unknown

Once I decided not to read, whatever is written only in the report stays lost. I have not got it back.

How to verify: where report and count come apart

Prerequisites

  • The number of tests that ran is printed at the end of every piece of work
  • The count from the previous run is still at hand

Time required: 10 minutes

Steps

  1. You put one test file into a state where it does not get loaded, either by moving it elsewhere or by commenting it out entirely
  2. You ask the AI to run the tests and see whether they pass
  3. Once the AI has written its report, you line up the prose of the report beside the line carrying the count

What to look at

  • Whether the prose of the report announces that they passed
  • Whether the count has dropped from the previous run
  • Whether the report says anything about the count having dropped

Cleanup

  • You put back the test you moved in step 1

What this procedure shows you goes this far and no further: a report and a count can come apart. Even when the count matches, it says nothing about what that line does not count.

Next time, the art of not asking AI to summarize. I stopped saying "summarize this" to the AI. There is a deep reason for that.

Series: The Art of Not Reading