This is article 4 in the series "The Art of Not Telling." 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 about plans. I stopped typing "give me a plan first" to the AI. There is nothing I put down in its place. The plans come out even with the typing stopped. That is because a plan that has been written calls up the next plan.

In article 8 of the previous series, "The Art of Not Listening to the AI's Opinions," I wrote that the rules you hand the AI grow less the higher the tier. Plan documents are the opposite. They keep growing. And even as they keep growing, I have not asked for them to be written.

Start by counting just one thing.

The number of times, over the past week, that you typed "give me a plan first" or "write the design before you start" to the AI.

Of those, how many times did you read the plan that came back and fix it?

CC BY 4.0

There are 200 plan documents, and I have never once asked for one

The production project on my own machine (typingtube, a web service for practicing typing along with music videos on YouTube) has 200 plan documents. They are design notes, one per feature.

In article 2 I wrote that 0 of those 200 hold a numbered procedure. This time it is the other side. I searched the instruction file (102 lines), the hooks that cut in at moments such as a commit, and the definitions of the skills, for the word "plan." Instructions amounting to "write a plan document" came to 0. The instruction file touches plan documents in only 3 places, and every one of them points to where they live ("docs/plan/ - plans for features"). I have put down no hook and no automated test that asks for a plan document to be written.

There are 200 plan documents. I have never once said "write a plan document." Even so, on the side of the plan documents, "decided by the user," "the user's judgment" and "the user's instruction" are still there in 538 places, across 73 of them.

A plan document opens in roughly this shape. This is a real one.

# 212 Publishing the series inside the site (/articles, alongside Zenn)

- Raised: 2026-09-03 (the user's instruction: "the series I wrote for Zenn is up against
  the posting limit, and posting it all will take about a month. I want the newest article on the site")
- State: ✅ implemented, pushed to main

## 0. The conclusion first
The body lives in only 1 place. …

What I handed over was the single sentence inside the quotation marks. I did not type "make me a plan document," or "what about the chapter headings." Nor did I specify that what comes next is ## 0. The conclusion first and not ## Steps.

The reason they get written was not an instruction but the plan documents standing in a row

I measured it. To 2 workers that do not carry the conversation over (subagents), the same way as in article 1 of the previous series, I handed a single line of a request that is not implemented yet. "I want to be able to download the word deck's practice records as a CSV myself." I had them make no files, and answer with the first thing they would do and the reason for it.

Both of them put "write a plan document" at the end of 5 moves. The number would be 215, the next one; the format the same as the existing ones; the moment to write it right after getting hold of the current state and before touching any code. I had not asked for that. The grounds they gave, having first confirmed that the instruction file says nothing explicit about writing one, were that 200 existing plan documents stand in a row in the same format. 1 of them also cited the single line that points to where they live, but answered that the deciding factor was the real thing.

One more, the same way: I deliberately handed over a request that had already been implemented. "I want to add sorting to the listing." Both of them found the existing implementation and its plan document, and answered that they would not write a plan document. They have not been told to write one, so when one is not needed they do not write it.

Anthropic's prompting guidance, broken down by model, spells this behavior out.

Opus 5 does best when you give it the complete task specification up front and then let it run.

A specification, not an instruction. What happens when you type "give me a plan first" while the specification is not complete: what comes back is a plan with the missing premises filled in. The one who filled them in is the AI, not me.

What I understood fits in one sentence.

A plan does not get written because it was asked for. A plan that has been written calls up the next plan. So instead of asking, you leave the plans that have been written where they are.

The mechanism: there is nothing new to put down

There is nothing to put down. What is already down is the 200 plan documents themselves.

The first one may be one I had it write. The date of the oldest plan document in git is the same day I wrote into the instruction file where they live. From the 2nd one on, it was the 1st that called them. Before it starts, the AI reads the existing plan documents and takes the next number in the same format. Not because it was asked, but because that is how the precedent stands.

Sometimes it finishes without writing one. Those are the cases where one is not needed. The line the 2 of them drew was the same. A new table, a new screen, a judgment about the specification, and it is a plan document; a fix that closes within 1 session and leaves nothing to hand on to the next, and nothing gets left behind. Of the 1,177 commits since June, 508 did not name a plan document in the subject line.

Sometimes it goes into memory alone. Permanent constraints, and lessons about behavior that repeats, go to memory rather than to a plan document. The memory on my machine has had as much work put into it as the plan documents: a checklist of 5 items before a save (value, permanence, duplication, consistency, approval), and a hook that throws the diff back immediately after the save (article 7 of "The Art of Not Reading"). So a judgment written into memory is read by the next session, the same way a plan document is.

What I stopped asking for

"Write me a plan first." "Produce a design before you start." It is not that the plan documents went down: there are 200 of them, and they are still growing. What went down is only the line that asks for one before the work starts.

Caveat: the first one is not an accumulation

One, the first one gets written by somebody. What happens when the precedent is zero is something I have not measured.

If you want to try it, take all the plan documents out of the way in a throwaway clone and hand over the same request.

Two, 3 lines pointing to where they live are still there in the instruction file. They do not say "write one," but 1 of the 2 cited those lines among its grounds as well. The state with those lines deleted is something I have not measured.

Three, what a plan document gathers is a record of facts and judgments, and it does not decide what gets built. The judgments in those 538 places are still written by me. What this article stopped is asking for a plan, not deciding a plan.

How to verify: hand it over without asking, and see whether one gets written

Prerequisites

  • You have several plan documents or more built up on your machine (with 0 for precedent, this verification measures nothing)
  • You can arrange 3 places that do not carry the conversation over (3 subagents, or 3 new sessions)

Time required: 20 minutes

Steps

  1. You hand the 1st one a single line of a request that is not implemented yet ("I want to be able to download the practice records from the word deck as a CSV"). You do not let it make files. You ask for one thing only: "answer with the first thing you would do and the reason for it." Do not ask "do you need a plan document?" Ask whether something is needed and the answer leans toward the premise of the one who asked. You have it answer what it would do
  2. You deliberately hand the 2nd one a request that has already been implemented (you say you "want to build" a feature that is already there)
  3. You hand the 3rd one the same request as in step 1, with "give me a plan first" attached

Pass conditions (all of them have to hold)

  • In step 1, writing a plan document is among the steps it answered with
  • In step 1, it gives the existing plan documents standing in a row as its grounds for that
  • In step 2, it finds the existing implementation and plan document, and answers that it will not write a plan document

If it does not pass

  • The grounds in step 1 were "because the instruction file says so" — there is still an instruction to "write one" on your machine. It is a line you can go and find and delete
  • It answered that it would write a plan document in step 2 as well — the result of step 1 is "it writes one every time," not a judgment

What to look at in step 3 (this one is not pass or fail)

  • Whether there is anywhere in the plan that came back where a premise you have not decided has been filled in. The one who filled it in is the AI, not you. That is what this article is about

Cleanup

  • None needed. None of the 3 has made a file

Next time, the art of not driving the point home. I stopped driving the point home. Even so, a line that matters has never been ignored.

Series: The Art of Not Telling