The Art of Not Listening to What the AI Says

CC BY 4.0

Cutting in broke my work; saying nothing burned 1.73 million tokens

The failure when I explained. Cut in partway through the work with "that part is wrong" and that one remark becomes the highest-priority task. And the more correct the remark is, the more the response to it takes the lead, and the plan that was running breaks along with it.

The failure when I did not explain cost more. On the production project on my own machine (typingtube, a web service for practicing typing along with music videos on YouTube), there was a day when I handed the translations for more than ten languages to subagents. A subagent is an 🤖AI that starts up separately and works without carrying the main conversation over. I started 13 of them in parallel, about 1.73 million tokens. Each agent rewrote its own tools, and the same job went ahead in a different way in each one.

I noticed when I hit the usage limit.

Then I explained, and the 🤖AI opened the body of the behavior rules — the decisions about how the 🤖AI should act that I had built up in a note. Counting the record afterward, the first word that appears only in that body is on line 1042, and the 13 launches had finished between line 631 and line 990.

"Leave it alone and the 🤖AI notices by itself" did not hold.

What I understood fits in one sentence.

A drift moves ahead if you say nothing, and breaks the order of the work if you say it in the conversation. So correcting is made a job for a mechanism, not for a person.

Why a remark in conversation breaks work priorities and saying nothing leaves nobody noticing

A remark I type into the conversation does not stop the tool that is running. The Claude Code documentation writes that when you send a correction partway through the work, the 🤖AI reads it as soon as the current action completes and adjusts before deciding its next step. A policy written in the instruction file (CLAUDE.md or AGENTS.md) is, as the documentation writes, context loaded at the start of the conversation and not enforced configuration, so it is only lined up as material. At the very back of that line comes the remark I have just typed.

And that remark stays. The Claude Code documentation writes that as the conversation approaches its limit, what is cleared first is the older tool outputs, while your requests and key code snippets are preserved. The plan that was running sits on the tool-output side.

When I said nothing, no material reached the 🤖AI's side. The same page writes that without tools the 🤖AI can only respond with text, and that each tool use returns information that feeds back into the loop, informing the next decision. No tool returns the fact that 13 agents were taking the same job in a different way each. The same page also writes that a subagent has its own conversation and starts fresh. The 13 do not see each other's hands either.

There was no material on my side either. The same page writes that a subagent's tool calls stay out of the conversation that started it, and a summary comes back when it finishes. What the 13 were writing, and how, does not appear on my screen or in the center's conversation while they run. What appears is the report that they are finished, and the usage numbers. So the point where I can notice is when those numbers reach the limit.

The 1 line a mechanism returns is neither a remark I type nor nothing arriving at all. What puts that line out is a hook, a script that runs by cutting in before or after a command, and its documentation says "rather than relying on the LLM choosing to run it, the action always happens." It also says that when a hook blocks something, the explanation of why it blocked comes back to the 🤖AI, and the 🤖AI can adjust its approach. Where it arrives is not the conversation but the result of the move the 🤖AI has just made. So that line does not cut into the line of material, and it does not stay in the conversation either.

The mechanism: there is nothing new to put down

The mechanisms put down in the previous series stand in for the correction as they are.

5 patterns ran through all of them. In this series too, I reuse every one of them.

One, a rule works only when it is read, and it thins out the more you add. Adding 1 line to the instruction file makes all the rest a little weaker. So there is no answer down the road of writing in more "do not do this." That is why this series was never about writing more rejections down, but about gathering them in one place and giving them a structure (article 1).

Two, stop the 🤖AI and it goes looking. When a hook stops a command that did not come through the entrance you set and puts up guidance, the 🤖AI reads it that way on the spot and starts off again. Unlike a human breaking into the conversation, the guidance arrives inside the flow of the work, so it does not break the order of priorities. In this series, the catalog that stops a subagent from starting takes this shape (article 4).

Three, you cannot measure whether something was read. You look only at whether it was written, whether it is there. Whether the 🤖AI read a document is something a program cannot decide. Whether a "file that could not have been made without reading it" exists, a program can decide. In this series, the tools the center (the 🤖AI that directs the subagents) has to prepare before a launch (article 4) and the "Machine check" heading, which you judge by whether it is written, (article 5) are the same pattern.

Four, a policy has its effect decided by the moment it is slipped in. The same text, read by the 🤖AI before the trouble happens, turns into general advice about somebody else; arriving the moment it happens, it gets read. The condition for lifting it is attached to the prohibitions in this series (the list of rules you decided not to allow while developing) so that the material for the judgment arrives at the very moment the proposal comes (article 3).

Five, a self-report leans toward "done." A report only tells you that it stopped. A report is a summary written by the 🤖AI, so what is inconvenient falls out of it first. A mismatch shows only when a line the 🤖AI did not write sits next to it. In this series, the pass or fail of a check is decided not by the 🤖AI's report but by the 2 numbers a smoke test, one that runs the operations through to the end in a browser, returns after looking at the data left behind (article 6).

When the 🤖AI says something off, I do not explain. I let it carry on, and where it ought to stop, a mechanism stops the 🤖AI. The 🤖AI that has been stopped reads the guidance in front of it and turns itself around.

A stand-in stops the 🤖AI when the 🤖AI rewrites a file and when it runs a command. For a drift that ends with the 🤖AI rewriting nothing and running nothing — a premise left taken wrong, a proposal merely put forward — no mechanism steps in to stop it.

What I stopped pointing out

The drift I notice partway through the work. "That premise is wrong," "we settled that before": I no longer say these while the 🤖AI is running. It is not that what I wanted to say has disappeared. The job of saying it has simply moved to the mechanisms. What I notice, I pile up in a note of my own that the 🤖AI never sees, and once that piece of work is over I sort it out, into an automated test, into the list of prohibitions, into the catalog. I decide where it goes; the 🤖AI writes it.

Whether I can get by without explaining, I measured in article 1 of this series. It was an experiment that threw an already rejected proposal at 2 separate workers which do not carry the conversation over. I did not explain a word. Even so, the 2 of them both found the list of prohibitions on their own and turned it down. One read entries it had not been asked about and closed off the road itself, partway through an alternative.

Caveat: going quiet where nothing stands in is just leaving things alone

In the previous series there is one article, out of all 12, that said "please read this." It is article 5. It says to read your subagents' logs, once. The reason is that if the person who started them has put down no guardrail and does not look at the logs either, that is not a technique but simply leaving things alone.

The 1.73 million tokens went to waste in exactly that state. That day there was not one mechanism that stopped a subagent from starting. I put the catalog of missions down on the day of the accident itself. Because I went quiet where there was no stand-in, the 13 ran all the way through with nobody stopping them. The only place you may stop explaining is where you have put a stand-in down. Do not reverse the order: put it down first, and then go quiet.

How to verify: when you want to explain, look for the stand-in

Prerequisites

• There is nothing to put down. 1 occasion where the 🤖AI says something off is enough (it will come the same day)

Time required: 5 minutes (once, on the spot. The sorting comes later)

Steps

1. You catch 1 occasion where the 🤖AI said something off and you wanted to explain. A premise taken wrong, a feature added that nobody wants, something already settled brought back up
2. Before you cut in, you stop your hand and look. You see whether a mechanism that stops it is already there, short of that drift doing real harm: an automated test, pre-commit, a hook that stops a launch, the list of prohibitions. What you look for is not "a mechanism that points the drift out" but "something that fails once the result of carrying on with the drift takes shape"

What to look at (not pass or fail: it splits on what your search turned up)

• You found one — you say nothing and let it carry on. Take the chance to watch whether that mechanism really stops the 🤖AI. If it did not stop, it is not a stand-in
• You found none — that is the mechanism you put down next. On the spot you do not hand it to the 🤖AI: you write 1 line in the note

Cleanup

• Once the current piece of work is over, you sort the note out. What a program can decide the truth of goes into an automated test, judgments go into the list of prohibitions, and what you hand to a subagent goes into the catalog. All you decide is where it goes; the 🤖AI writes it
• Put the sorting off and only the note grows. Do the sorting at every break in a session

Next time, the art of not tidying rules. I have never once tidied the rules I hand to the 🤖AI. And even so, the rules are not growing without end.

Series: The Art of Not Listening to the 🤖AI's Opinions

• ← Previous: 6. The art of turning down the 🤖AI's requests to check
• → Next: 8. The art of not tidying rules
• All articles: Introduction: The Proposal You Turned Down Comes Back

End of CC BY 4.0