I have almost stopped telling the AI what to do. Not how to do it, not the procedure, not the plan, not the reminders, not the corrections. This is not the same as dumping the work on it — saying "just handle it" without preparing anything to hand 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. The series can be followed by reading alone. Each article starts with what happened on the ground, goes on to what I put down, and ends with what went away. Near the end of each article there is a section called "How to verify." You do not need to read it first. Come back to it when you want to see for yourself why the mechanism you put down is needed.

Learning the remedy from the symptom

Each article starts with a symptom, something that is not working. The remedy comes with the relevant behavior and specifications of the AI, and an explanation of why that remedy fits.

You do not need to learn why it fits before you use it. Put one mechanism down and the symptom is handled.

Even when you know the behavior and the specifications, the AI can still get it wrong depending on how they combine. Ordinary design and development is unlikely to catch these pitfalls, where several behaviors and specifications are tangled together. You learn them from the symptom, one at a time.

Start by checking what you recognize

Start by counting just one thing.

Scroll your most recent session back to the top and pick out only the words you typed.

How many were there?

Of those, how many are things the AI does without being told?

If you are not building alongside an AI yet, of course there is nothing to count. From here on we start with how the instruction file on my own machine shrank twice. It reads fine without numbers of your own.

The instruction file shrank twice, on its own

The introduction to the previous series said that an instruction file thins out the more you add to it. The instruction file on my own machine (CLAUDE.md) grew in exactly that way. Follow its line count all the way through the git history and it draws the same curve twice.

In February it grew from 85 lines to 99, and one day it fell to 52. From there it grew again to 119, and one day it fell to 81.

And now it is 102 lines.

The 2 days it fell had something in common. On both, the same commit that cut the instruction file also touched an automated test or a hook. The first was the day I tidied up the commit-message hook for actual operation, the second the day I moved the design ratchet from CI to a pre-commit hook. Both commit messages say chore:, and neither says it was done on purpose.

So the instructions that live in a file do get cut, because they can be counted. They have a line count, and when they grow you notice.

The other side is the one nobody counts. The words I type, every time.

These have no line count. They do not stay in a file, and they wash away when the session ends. Nobody notices when they grow. So the day they get cut never comes. That is the side I asked you to count at the top.

The previous 2 series were about no longer reacting to what the AI says and does

This is the third series.

Reading the previous 2 series back, I noticed something. Everything I stopped saying there was a reaction to something the AI had said, done or proposed. Corrections during the work, the reason for a rejection, asking whether something was a violation, replies to a request to check. I moved them into mechanisms one at a time.

What was left was only the words I hand over at the start.

One sentence was left without its explanation

In the finale of the first series I wrote this. Apart from when I am weighing up a direction, the words I type to the AI are almost only these 2 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

The 2nd sentence got a whole article to itself: why I do not automate it, what it picks up, what it cannot pick up.

The 1st sentence has none of that. All I added was a single line, "it is a promise that the human will not cut in during the work," and beyond that I never explained once, across 28 articles in 2 series, why the work goes ahead without specific instructions, what the model does on its own, or what the human has to hand over.

This series is the 12 articles that fill that gap.

This is not a plea to write less

What gets cut is instructions: procedures, prohibitions, requests to verify, reminders, strategic advice. What grows is the premises, and I write more of those than before. Things only I know, things that happen only in this environment, boundaries that must not be crossed. The axis is not length, but whether the model can get there on its own.

The better it works for you, the less it reproduces when you teach it

There is another reason I wrote this series.

It runs well for you, and yet when you teach someone else it does not come out the same.

Does that sound familiar?

The reason is simple: when it works, the result comes out of what that person did not say.

But what you can hand over when you teach is only what you said, and what you did not say never makes it into the material. The person on the receiving end fills the empty space with the usual recommendations. Give specific instructions, have it verify, point out the mistakes and have them fixed. Every one of those is sound advice, and it is exactly what this series takes away. Teaching degrades it because teaching adds input.

So no article ends at "do not say this." Each one names 1 thing to put down in place of saying it. That is because a prohibition with nothing to replace it either goes unhonored or turns into dumping the work.

The setting is the same as the previous 2 series: typingtube, a web service for practicing typing along with music videos on YouTube. I run it on my own, and it is live in production.

⚠️ One thing to be clear about first. This is the record of one person's workplace. On a team of several people, plans and reviews are communication aimed at others, so parts of them are left that an automated test cannot replace. You can start here without having read the previous 2 series—each article opens with a single line about what the earlier series said, and that line is enough. Reading in order means starting from the first series, but it is not a requirement.

How the series is laid out

Each article is finished once you put down a single file or script. You do not have to put them all down today.

Each one opens with a way to check the symptom in your own environment, so pick up the article whose symptom you are seeing.

Next time, the nearest thing to hand. I stopped asking the AI to verify. Quality is no different from the days when I was asking.

Series: The Art of Not Telling