I barely weigh up the AI's proposals anymore. Not the new features it offers meaning well, not the kind suggestions for improvement, not the carefully worded alternatives. The AI does not remember a rejection, so a proposal I turned down comes up again in the next session. Did my development go sloppy because of it? It did not. This series is about building that state one mechanism at a time.

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 recalling just one thing.

The place in your most recent session where you turned down a proposal from the AI.

How many times had that proposal come up by then?

If you are not building alongside an AI yet, of course you cannot recall turning one down. From here on we follow, one at a time, how that count piles up on the human side alone.

It will not have been the first time. The same feature, the same improvement, the same "while we are at it, shall we do this as well." You turned it down before, and it comes back. You turn it down. In the next session, it comes back.

Only the human ever turns it down

The AI does not remember being turned down. Nor has it forgotten. It never becomes a matter of remembering or forgetting in the first place. The AI in the next session looks at the same codebase, notices the same gap, and makes the same proposal. For you it is the second time; for the AI every time is the first.

Claude Code's documentation says each session begins with a fresh context window, and it names two mechanisms for carrying knowledge across sessions. One is an instruction file you write; the other is a memory the AI keeps for itself. A rejection spoken only in conversation goes into neither. Turning it down ends along with that session.

The same proposal comes back, but not because an AI returns identical output every time. Claude's API reference notes that even at temperature 0.0, results will not be fully deterministic. What arrives a second time is not a sentence repeated but a proposal of one kind. Show one model a codebase twice and wording shifts while destinations converge.

Proposals never run out either, and there is a reason. Claude Code's best practices warn, about AI review, that a reviewer prompted to find gaps will usually report some, even when the work is sound. Finding gaps was its assignment. Looking over a codebase for improvements is work of one kind, and something turns up whenever you look.

And putting a proposal forward costs the AI next to nothing. The cost of judging piles up on the human side alone. Every time you turn it down you recall the reason, arrive at the same conclusion as before, and give the same explanation.

Putting a rejection outside works because written files load at every session start. Claude Code's documentation also covers what survives a trim of an instruction file: it cuts whatever a model can derive from a codebase and keeps pitfalls, rationale, and conventions that differ from tool defaults. Rejections sit on the rationale side, and no amount of reading code derives them. In conversation I had been discarding exactly what official guidance marks as worth keeping.

What you put outside dilutes as you add to it, though, exactly as everything else does. A list of rejections eats the same attention budget as an instruction file, so a caution on that same page about aiming for under 200 lines applies here unchanged. This move holds only while new kinds stop appearing.

What I understood fits in one sentence.

The AI does not remember a rejection. A proposal costs it nothing to make, and the cost of judging is paid by the human alone. So a rejection is written out once, in full, and put outside.

This carries on from the previous series

The conclusion of the previous series, "The Art of Not Reading," was that a rule works only when it is read, while an automated test or a hook fails whether or not anyone reads it. You stop writing what you want honored into the instruction file and replace it with an automated test that fails when it is broken: article 6 is that implementation.

That article drew a line of its own, though. Only rules whose truth a program can decide can be translated into an automated test, and judgments and policies such as "we deliberately do not build this feature" cannot be, so they stay on the side that has to be read.

This series takes that leftover side as its subject. What we do is the same as before, from rules to mechanisms. Only what we handle moves up by one.

  • The previous series: it put the AI's output into a shape you do not have to read
  • This series: it puts the human's judgment into a shape you do not have to make twice

This says the opposite of the previous series

Article 2 of the previous series said this. Every time the AI saves something to memory, the amount every later session reads grows. One save becomes a cost you keep paying every time after that.

This time it is the other way around. One rejection becomes something you stop paying for, every time after that.

What differs is how they grow. Insights come without end. What you turn down does not. On my machine it has stopped at 17.

The 17 are the result of turning things down 17 times

This series is not about making a list of things you will not do.

The 17 I have were turned down one at a time, written down one at a time, and gathered onto a single sheet afterward. Not one of them is a prohibition I thought up in advance. What you put down today can be the single thing you have just turned down for the second time. As in the previous series, a mechanism put in place before the failure tends not to settle in.

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

How the series is laid out

The finale puts together how the 8 connect into a single line.

Next time, the nearest thing to hand. I do not weigh up the AI's proposals. Even so, I have never missed a good one.

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