---
title: "The Art of Not Reading #8: The Art of Not Reading Fix History"
author: garplab
publisher: TypingTube
license: CC BY 4.0
license_url: https://creativecommons.org/licenses/by/4.0/
license_scope: 「CC BY 4.0」の印から始まる節（仕組み・検証手順・コード）。印の無い本文は著作権を留保
canonical: https://typing-tube.net/articles/en/f7c9c30f567aee
series: "バイブコーディングにおける読まない技術"
language: en
---


> This is article 8 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](https://typing-tube.net/articles/en/34b02627c718fa).

This time it is the record of the times I put the AI back on course. Even when I write the remedy for a failure into the instruction file, the AI makes the same mistake the next time round. A policy read before the problem occurs has no context. What decides whether it works is not its content but the moment it is inserted. What is missing is what this article deals with.

You will recognize this. The AI fails, and it tries the same way again. Again. Again.

"Do not keep retrying; when something fails, change your approach." I have put the AI back on course on that point many times, and the lesson is written into the instruction file. Even so, at the moment of the failure, the AI handles the error in front of it as "one more go and it will be fixed." Trying again right after an error is a standard behavior ingrained by training, and it sits above that one line of a lesson in priority.

When the same thing keeps happening, you end up going back to look for how you fixed it the last time. Past exchanges, the remedy you wrote down then, the lines you added to the instruction file. I would read back through this fix history and add one more line to the policy. In the next session the same failure comes up again.

Two reasons overlap here. One is the dilution from the [introduction](https://typing-tube.net/articles/en/34b02627c718fa): the policy is mixed in with everything else, far above in the context. The other is the essential one: a policy read before the problem occurs has no context. "Change your approach when something fails," read at a point where nothing has failed, is a generality about someone else, and the AI has no reason of its own to hold on to it. The same sentence means something only at the moment the failure is in front of it.

Article 7 showed that a policy works only after the save. A save runs at the highest priority, so a policy put down before it was losing.

What I understood fits in one sentence.

> **A policy read before the problem occurs has no context. Whether it works is decided not by its content but by the moment it is inserted.**

## Why a policy read before the problem does not work

There is no route where you have it read something first and it remembers. That is because an AI does no learning while it is being used. What Brown et al. showed in 2020 was a shape in which behavior is settled [purely through text interaction, with no gradient updates or fine-tuning](https://arxiv.org/abs/2005.14165). Having it read the instruction file writes nothing inside the AI. The policy you had it read becomes one of the lines sitting in the context.

That line stays where it was loaded, at the head of the conversation, and it does not move. The failure happens much later. What sits close to that moment is the error that has just arrived and the work in progress. The error that has just arrived is the strongest input at that moment.

Putting it close to the moment is a placement Anthropic uses itself. The published system prompt for claude.ai holds a mechanism that is [sent as an append to the user's message, helping Claude hold on to its instructions over a long conversation](https://platform.claude.com/docs/en/release-notes/system-prompts/claude-fable-5-1).

The move that surfaces right after a failure has a source as well. Typing the same command once more is a sequence the AI saw over and over during training. It is on the same side as the standard command from article 1, and it surfaces without anyone asking for it.

If it only surfaced, the second attempt could still put things right. It does not, because nothing new comes in from outside between the first attempt and the second. Huang et al. report that [LLMs cannot correct their own responses without external feedback, and sometimes come out worse after trying](https://arxiv.org/abs/2310.01798). With the same material to work from, the wording changes but the same kind of move comes out. So I decided to stop that second attempt itself.

## The mechanism: one policy file, and a hook that inserts it at the moment

You write the course-correction policy, the things a human wants learned from past failures, in a few lines in one file.

```markdown
# Course-correction policy (inserted when a problem is detected)
- After 1 failure, do not repeat the same method; change the approach at its root first (split it up, use another means)
- Always check with the human before a retry
- After 2 failures in a row, break off that means and propose an alternative
```

Then you give the hook a **detectable form** of the problem, and the moment it is detected the hook inserts this file. On my machine the real example is a subagent retry. On [typingtube](https://typingtube.net) (a web service for practicing typing along with music videos on YouTube), which I run on my own, jobs that come in large numbers, such as translation, get thrown at subagents, so that is where both the failures and the restarts happen. A relaunch under the same name, or a re-send to an agent that has already been started, can be detected mechanically, so the hook stops there and puts the policy out.

```bash
# If the launch record already holds the same name, it is a retry. Stop and insert the policy (a shortened version of the code on my machine)
# Keep the record by appending echo "$agent_name" >> tmp/launched_agents.txt every time a launch is let through
if grep -qxF -- "$agent_name" tmp/launched_agents.txt 2>/dev/null; then
  echo "'${agent_name}' has already been launched. This counts as a retry." >&2
  cat docs/course_correction.md >&2
  echo "Recount what is left, report to the human, then ask for direction." >&2
  exit 2
fi
```

The code ends in `exit 2` because that is the ending that reaches the AI. [The Claude Code documentation](https://code.claude.com/docs/en/hooks) says that a hook exiting with code 2 blocks the operation and hands its standard error to Claude as the reason for the block. A hook that exits with 1 blocks nothing, and the text it inserted never reaches the AI.

The policy is `cat`-ed instead of being written straight into the hook's message so that updating the policy never means touching the hook. However much the record of failures grows, what you swap out is only the few lines you have narrowed it down to.

One case where this worked. Before the mechanism was there, the AI restarted 2 failed subagents without checking, and ran straight into the session's usage limit. The instruction file said "check before a retry" even back then. It was not that the line went unread: it was not there at the moment of the failure. Now the same operation always stops once, and the policy comes out in front of the AI. A stopped AI reads the sentence in front of it. Here too, it is a structure that cannot proceed unless something has been read. By the time a human notices and cuts in, the retrying has already gone round many times. The insertion arrives at the entrance to the first round, and turns the work in another direction while it is still in flow.

## What I stopped reading

Fix history. Going back over past exchanges and records of failures to work out "how did I fix this last time," having the AI go back over them, and repeating "I told you this before" as a human are all gone. The history is narrowed down to the few lines of the policy, and it arrives only at the moment it is needed.

## Caveat: you can only insert into a problem you can detect

This mechanism is good only for problems with a form you can detect mechanically, as a retry has. A new kind of failure, one you cannot write a detection for, has no moment to insert into. Those surface only when they are asked about from outside, so the nets of next time (the command's numbers) and article 12 (the closing question) pick them up. And one more caveat, the same as last time. Keep the policy file to a few lines. Every failure makes you want to add 1 line, but merge the lines that are about the same thing, and delete the lines that were inserted and did not work. The file not growing is the evidence that this mechanism is working.

## How to verify: make it repeat on purpose, and confirm that it stops

**Prerequisites**

- The policy file is down in a few lines, and the hook that `cat`s it and inserts it is registered
- The condition for detection is settled (in this article's example, "a subagent relaunched under the same name")

**Time required**: 10 minutes

**Steps**

1. You have the AI repeat, on purpose, an operation that meets the condition for detection. In this article's example, you have it start a subagent again under the same name as one it has already started once. The first time goes through as normal. What you are checking is the second time

**Pass conditions** (all of them have to hold)

- It stops before the operation is carried out
- At the place where it stopped, the full text of the policy file is shown (not a summary, and not an instruction to "read the policy," but the contents themselves)
- The AI's next reply changes: instead of trying the same operation again, it offers an alternative, or checks with you

**If it does not pass**

- It did not stop — the condition for detection does not match the shape of the actual operation. Fix the string the hook is looking at so that it matches what the AI typed
- It stopped, but the AI repeated the same operation — the sentences in the policy file are not saying "what to do at this moment." Write in the next move

**Cleanup**

- Stop the subagents you started in step 1, and delete any half-written output they left behind

---

Next time, the art of not reading handoffs. **I do not read the completion reports the AI writes.** Even so, if the report and what actually happened disagree, I notice it on the spot.

---

**Series: The Art of Not Reading**

- ← Previous: [7. The art of not tidying shared memory](https://typing-tube.net/articles/en/83c46d1e6b2591)
- → Next: [9. The art of not reading handoffs](https://typing-tube.net/articles/en/a43b57a94d2216)
- All articles: [Introduction: I Barely Read What the AI Outputs Anymore](https://typing-tube.net/articles/en/34b02627c718fa)