I barely read what the AI outputs anymore. Not the test results, not the notes the AI appends to its own memory, not the work logs from its subagents — the separate AI instances it starts up without carrying the main conversation over. Did quality drop because of it? It did not. This series is about building that state one mechanism at a time.

A word first on how to read this. This series works by reading alone. Each article starts with what happened on the ground, then what I put down, and then what I stopped having to read as a result. Near the end of each one there is a section called "How to verify," but you are free to skip it. It will still be there when you feel like trying it in your own environment.

Start with one thing you can answer from memory. The instruction file you hand to your AI coding agent (CLAUDE.md, AGENTS.md, or whatever yours is called — the place your rules live): how many lines is it now? Can you remember which of those lines you added last week? Was that line honored in today's session — one continuous stretch of work with the AI?

If you are not building alongside an AI yet, of course you cannot remember. From here on we follow what becomes of that instruction file over three weeks. It reads fine without a number of your own.

If you have a terminal at hand, counting the lines makes the numbers in the next section yours.

wc -l CLAUDE.md   # substitute the file name you actually use, such as AGENTS.md

It stops working in three weeks

Here is the usual course of events. Week 1: the instruction file is 10 lines. It works well. Week 2: you add one "never do X" line after every failure, and it reaches 30 lines. It still works, but days start to appear where a rule you added earlier is broken. Week 3: 60 lines. What you could do in week 1, you can no longer do. So you reorganize the rules, give them priorities, and move the important ones to the top in bold. 80 lines. They are honored even less. The effort to improve is itself what pushes the state further down. That is the pit.

The cause is not the AI's ability but the structure. Your instructions are competing for attention with everything else inside the working memory (the context) that the AI loads on every response. Rules dilute as you add them. Adding one is making every other one a little weaker. So "add a rule to make it obey" is a structurally losing move.

Anthropic calls this a finite resource that diminishes — an LLM has an attention budget, and the more tokens it holds, the less accurately it recalls from them. The Claude Code docs are blunter: aim for under 200 lines per instruction file, because longer files consume more context and reduce adherence.

flowchart TB
  subgraph K["Loaded every session, on every response"]
    direction TB
    k1["The instruction file"]
    k2["The memory index"]
    k3["The conversation for the task at hand"]
    k4["Tool output (test results, diffs, ...)"]
  end
  K --> B["The attention budget does not grow"]
  B --> R["Adding one line is making<br/>every other one a little weaker"]

The production project on my own machine went through this pit as well. It is typingtube, a web service for practicing typing along with music videos on YouTube, which I run on my own. The instruction file reached 101 lines and the accumulated memory 89 files, about 1.1MB. Merely injecting the list of rules put about 26KB into the context every single time. This series is the record of walking back from there.

The art of not reading

What lay on the other side of walking back was the opposite of "make it read more." Test results arrive as failures only. Memory does not grow on its own. Subagents stop where they should stop without being watched. One by one, the things you were being made to read disappear, and that much of the load goes with them.

There is one thing to do per article. You put down one file or one script, and one procedure to confirm it. A mechanism works simply by being placed. Understanding is soon enough once you have started using it. There is no need to read it through before you begin.

Many of the articles use a hook mechanism that interrupts the agent (hooks, if you are on Claude Code), but if the tool you use does not have one, build it. What you need is a structure that cannot proceed unless something has been read; a hook is only one way of implementing that.

One important caveat. You do not need to put all of this in place today. Putting a mechanism in place ahead of the failure it prevents tends not to work out. Depending on your scale and structure, there are failures that never occur at all (small projects are strangers to memory bloat).

Most of the articles open with a single operation for checking the symptom in your own environment. If the symptom is there, that is the moment to place that article's mechanism. A mechanism you place after failing settles in well, because you have just witnessed why it is needed.

How the series is laid out

The basics are for people who use a mechanism that has been handed to them. Placing what you are given is enough to make it work.

The advanced articles are for people who build mechanisms and hand them over. They put things into a shape that does not fall apart as the scale grows.

The final article puts together how the parts up to that point connect into something that runs on its own.

After the main series concludes, four test-focused articles follow as an addendum (the art of not re-running tests / the art of not reading false failures / the art of not running everything / the art of not taking screenshots). Tests are what the AI runs most often, so those articles take the first article further in a section of their own. Beyond that, I plan to keep adding as practice gives me more to write.

Next time, the nearest thing to hand. The 26,147 lines that pour in every time the AI runs the tests — I do not read them. I have yet to miss anything because of it.

Series: The Art of Not Reading