--- title: "The Art of Not Reading — Finale: I Have Nearly Stopped Reading What the AI Outputs" author: garplab publisher: TypingTube license: All rights reserved license_scope: 記事の全体（序論・最終回は CC BY 4.0 の対象外）。引用は法の範囲で自由 canonical: https://typing-tube.net/articles/en/c133110afb526c series: "バイブコーディングにおける読まない技術" language: en --- I have nearly stopped reading what the AI outputs. Not the test results it produces, not the notes it appends to its own memory, not the work logs of the subagents. And it is not only me: the AI itself is now in a shape where it does not have to read its own output either. The starting point was the introduction's "what you add dilutes what is already there," and the 12 articles up to here were all remedies for that one point. What you add dilutes because the AI follows whatever is strongest right now. The series "The Art of Not Reading" is the record of building that state one mechanism at a time, and this article is the finale. The mechanism from each article can be reached from the list in the [introduction](https://typing-tube.net/articles/en/34b02627c718fa), so if this is your first one, start there. Apart from when I am working out a policy, what I type to the AI is almost nothing but the following two sentences. > Go ahead with the next task > Are there any gaps so far? Check, and if there are no gaps, hand the work off to the next session Between those two sentences, commands go in through a fixed entrance, only failures and a count arrive from the tests, and a subagent runs only if it has passed the catalog of missions. The rules are held by automated tests and hooks, a policy is inserted at the moment a failure is about to be repeated, and saving to memory is narrowed at the entrance. Near the end, the command's numbers line up next to the report, and the question in the second sentence closes it. ```mermaid flowchart TB S(["Sentence 1: 'Go ahead with the next task'"]) --> W subgraph W["While the AI works — the human is not made to read and does not cut in (article 11)"] direction LR a1["Type a command"] --> g1["The hook at the entrance stops it and points the way
Article 4"] a2["Run the tests"] --> g2["The wrapper returns only failures and a count
Automated tests = where rules fail
Articles 1, 3 and 6"] a3["Start a subagent"] --> g3["Only what passes the catalog of missions runs
Article 5"] a4["Be about to repeat the same failure"] --> g4["The policy is inserted at that moment
Article 8"] a5["Save to memory"] --> g5["Narrowed at the entrance, the diff put in front after the save
Articles 2 and 7"] end W --> Z subgraph Z["Near the end"] direction TB F["The command's numbers line up next to the report
Article 9"] --> V["The hook prints the command's numbers if they are not copied
Article 10"] --> Q(["Sentence 2: 'Are there any gaps so far?'
Article 12"]) end Z --> N(["On to the next session
All the human reads is 'nothing missing' or 'handoff done'"]) classDef human fill:#FFF3E0,stroke:#E38B2C,stroke-width:1.5px,color:#3A2A14 classDef ai fill:#F7F7F7,stroke:#9E9E9E,color:#333 classDef part fill:#E6F0FB,stroke:#3B7DC4,stroke-width:1.5px,color:#14304F class S,Q,N human class a1,a2,a3,a4,a5 ai class g1,g2,g3,g4,g5,F,V part style W fill:#FCFCFC,stroke:#C8C8C8,color:#555 style Z fill:#FCFCFC,stroke:#C8C8C8,color:#555 ``` Each one on its own is a small device that you only have to put down. Put them together and the whole of the work, with several sessions and subagents running in it, turns on two fixed sentences. Through all of it, I read almost nothing. And I say almost nothing. Turn it around: without those two sentences, quality drops however many mechanisms you stack up. The first sentence is a promise that the human will not cut into the work (article 11). The second is the net that catches at the end whatever fell out of every mechanism (article 12). What a piece of work is missing comes out only when the question is put from outside. A mechanism can only stop a problem in a shape it can detect, so a replacement for these two sentences cannot be built out of mechanisms. What runs on the far side of those two sentences is a web service called [typingtube](https://typingtube.net). It is a service for practicing typing along with music videos on YouTube, which I run on my own, and it is live in production. Every number in this series came out of it: the 26,147 lines of test output, the 13 agents and about 1.73 million tokens, all of it. Now for the confession. ## Where it mattered, I read all of it In this series I told the same lie over and over. "I have never read one." "I do not read them." It is a lie. Let me be exact. I was not reading every corner of it every time. Where it mattered, I read all of it. The raw test logs, the subagent work logs, the AI's output along the way: when I needed to, as much as I needed, as much as I wanted. The evidence sits inside the mechanism from each article. Which lines the summary greps for. The criterion for choosing the lines where a mutation ought to be caught. The center's tools (the center being the AI that directs the subagents) lined up under `requires` in the catalog. The lower bound on what the scan must cover, set beside the automated test. The position of the policy, inserted after the save. None of that can be written without reading. The shape of the summary could be settled because I had read the raw logs, the place to inject the mutation was clear because I had read the tests that copy, and on the day the 13 agents went to waste, the guardrails found their place because I read one agent's log. To settle the shape of the summary, I read all 26,147 lines of the raw log to the end. The work of turning the art of not reading into mechanisms was mostly the work of reading. The mechanism in each article is the result of the reading I did in the time I was not reading. ## So what was actually true "I am not made to read" was true; "I do not read" was a lie. But that is not what this series was trying to say. Who read and who did not was beside the point. What you do with the reading is everything. Looking back, what I did in each article was the same. Find one problem that is not working. Understand why it is not working. Put down one simple mechanism that fits that understanding. Break it, and confirm that it works. I repeated that, and only that, 12 times. Stack up understanding that way and what problems that looked separate have in common comes into view. That is why the same words kept coming up across the articles. - "A rule works only when it is read. It dilutes as you add." Test output, memory, the description text of a skill, the prohibitions in the instruction file: every one of them was this single problem - "The AI searches when it is stopped. Put it in a shape where it cannot move unless it has read." The wrapper's pointer for the tests (article 1), the pre-commit hook's pointer (article 4), the catalog for subagents (article 5), the policy at the moment of a retry (article 8) are one mechanism in different places - "Whether it was read cannot be measured. Look only at the existence of something that cannot be made without reading." Article 5 did nothing but apply article 4's hook as it was - "How a policy works is decided by the moment it is inserted." Article 8 is the generalization of article 7's "after the save" - "A self-report leans toward 'done.' A report only tells you that it stopped." Subagent reports and handoff notes could both be handled the same way Once you find what they have in common, the mechanisms get smaller. Instead of building a new mechanism for a new problem, you add one more place for a mechanism you already have. There was nothing new to put down in article 11 because the mechanisms placed in the earlier articles had taken over the scenes where a human wants to cut in. What they have in common goes back to the one structure written in the introduction. On every response the AI loads the instruction file, the memory, the tool output and the task in front of it into a single working memory (the context), reads all of it, and decides its next move by following whatever is strongest in there at that moment. Strength is not decided by correctness, nor by how prominent the place is where something is written. Standard behavior it has seen hundreds of millions of times in training, the error that just arrived, the goal of the task in progress, a direct instruction from a human: these are strong, and the one line you added to the instruction file a few weeks ago joins that competition every time and usually loses. The five above were all this one thing. Rules dilute because the lines you add shave strength off one another. It searches when it is stopped because the error that just arrived is the strongest input at that moment. Whether it was read cannot be measured because reading is not a question of "there or not there" but of "how strongly it took hold." The moment of insertion decides the effect because the same sentence is stronger the closer it sits to the moment of deciding. A report leans toward done because the context at the moment the report is written is the continuation of work aimed at getting done. ## Why the difference in strength appears What separates the strong side from the weak one is not a single thing. There are four separate properties, and they work at the same time inside one context. The first is position and volume. As article 1 showed, every line that arrives goes into the context and becomes material for the next response. What goes in does not take hold evenly, though. This is where the introduction's attention budget comes in. Anthropic calls it [a finite resource that diminishes](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents). That anything placed in the middle of a long input gets harder to pull back out is what articles 3 and 11 showed. The line you added to the instruction file sits at the head of the conversation and shares the same budget with everything that piles up after it. The second is behavior ingrained by training. As article 8 showed, an AI does no learning while it is being used, so the words I hand it in conversation do not rewrite that behavior. The line you added to the instruction file does not overwrite it; it lines up beside it and competes. The one line telling it to use the wrapper lost to the standard command `rails test` in article 1, and that is the same competition. The third is the goal of the task in progress. The official prompting guidance says that [Claude can focus too much on making tests pass at the expense of a more general solution](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices). A goal decides directly what happens at that moment. The tests the AI wrote in article 3 became a copy of the implementation because the expected values were taken from the goal of passing rather than from the specification. The policy read before the save in article 7 did not work because a save runs at the highest priority. The fourth is where it arrives. As article 6 showed, the instruction file and the memory arrive not as the system prompt but as a later user message. The same documentation also says that the AI reads it and tries to comply, but that [there is no guarantee of strict compliance](https://code.claude.com/docs/en/memory). That whatever lands at the end of the conversation is strong, and that it stays in the conversation afterward, is what articles 8 and 11 showed. The line you added to the instruction file sits on the weak side of all four. In position it is at the head, in volume it shares the budget with everything that piles up after it, against behavior ingrained by training it lines up beside and competes, it was written before the goal, and it is not at the end. The four are separate, but the next move is one. Whatever is strongest at that moment decides it. Knowing that the structure is one thing, though, does not tell you where or what will lose next. The structure explains what happened; it does not announce it. Which scene you lose in becomes visible only once the problem actually happens. So the reason the AI cannot act until it is told is not a missing ability. Being told works because it becomes the strongest input in the context at that moment. Write the same content in advance as a rule and it has gone weak by the moment of deciding, so it does not work. The only remedy the AI can pick for itself is to add something to the context (save a lesson, add one line to the instruction file), and that is a solution on the diluting side. What works is changing what arrives at the moment of deciding — the wrapper's pointer, the hook's error, a file you cannot get past unless it exists, the diff right after the save — and those are paths outside the AI, so only the human outside can put them there (the AI may do the writing. Deciding what goes where is the human's job). The art of "not reading" stands on top of that structure. Rather than reading the AI's output and being tossed about by what it says (told something is missing, you add a rule; told it failed, you read it again), you change what arrives at the moment of deciding. Find the problem that is not working, understand why, put down one mechanism, break it and confirm. Repeat that, and widen the range you do not have to read, one step at a time. The time I used to be made to read became the time to go looking for the next problem. None of these mechanisms went down all at once. I put each one down right after I had stepped on the failure it answers. You do not need to put all of it down today either. The criticisms, "you have to understand the code you had the AI write" and "without reading, you never grow an eye for design," are right, I think. Honestly, the amount I read has gone down. What went down, though, was the shallow reading I was made to do, and what is left is the reading that goes looking for problems. The only thing I stopped reading is the output I was made to read. ## The conclusion The art of not reading is the art of going on replacing problems that do not work with mechanisms. Once you have broken a mechanism you placed and confirmed that it works, you never have to read it again. I do not think of this as an advanced technique for a few people. I think it should be the basics of developing with an AI. Pick up the art of not reading, and with it the room to go looking for the next problem. --- For how to place the mechanism from each article, start from the list in the [introduction](https://typing-tube.net/articles/en/34b02627c718fa). What was built with these mechanisms is running at [typingtube](https://typingtube.net). The screens I built in the time I no longer read are lined up there. --- The next series is "[The Art of Not Listening to the AI's Opinions](https://typing-tube.net/articles/en/kikanai-intro)." **I do not weigh up the AI's proposals.** And my development has never gone sloppy. --- **Series: The Art of Not Reading** - ← Previous: [12. The art of not reading work results](https://typing-tube.net/articles/en/1769779c2f1b4b) - All articles: [Introduction: I Barely Read What the AI Outputs Anymore](https://typing-tube.net/articles/en/34b02627c718fa)