A Request Is Not a Rule

A good friend of mine, Felipe, used to say one thing so often on a project that it became a running joke.

Take care of your tools and your tools will take care of you.

He said it when someone fought their shell instead of setting up an alias. He said it when someone clicked through three menus for something a keystroke would do. He said it when the test suite was slow and everyone had learned to live with it. It was funny how often he said it. It kept coming up because he was right every time.

That advice is older than any of the tools I use today. It was true when I was pairing with people and it is true now that I am “pairing” with an agent. If anything it matters more now, because the agent has no memory of yesterday and no instinct for the house style. It onboards in thirty seconds and does exactly what your project makes easy to do.

From request to rule

On a recent project we had a convention. It lived in CLAUDE.md, written out in plain English, next to a dozen other instructions. The agent read it every session and ignored it often enough to matter. Not always. Just often enough that we kept catching the same violation in review.

You know this feeling if you have worked this way for any length of time. You write the convention down. You make it clearer. You add an example. You put it in bold. And the agent still drifts, because a request competes for attention with everything else in the document.

So we stopped trying to improve it and instead moved it. We deleted the paragraph from CLAUDE.md and wrote a custom linter rule instead.

Now the linter checks the expectation on every run. When the code does not meet it, the lint fails, and a failing lint is not a suggestion the agent can talk itself past. It is direct feedback that there is still work to do. The agent fixes it and moves on, in the same loop, without a human in the middle.

The convention went from a request I hoped the agent would honour to a rule it must satisfy before the work is done.

Why the request gets diluted

Everything in CLAUDE.md is a request. It sits in the context window alongside the task, the files it has read, every skill and tool definition and every other instruction you have written. As that context fills up, any single instruction gets diluted. The model is weighing it against everything else you have asked for. Sometimes it wins that competition and sometimes it does not. You are relying on probability.

A linter rule does not care how full the context is. It runs the same way on the first commit and the ten thousandth. It does not weigh your rule against anything. It has one job and it does it deterministically.

Encode expectations where they get enforced, not where they get read. The same swap, from a request into a check, works in plenty of other places.

A convention you keep repeating in the prompt becomes a lint rule. “Remember to update X when you change Y” becomes a test that fails when the two drift apart. “Follow this structure” becomes a schema the code is checked against. “Handle this case” becomes a type that makes the bad state impossible to write.

Each one takes a soft instruction the model honours some of the time and turns it into a hard signal it has to clear. This is not new advice. It is how we built trust across a team long before any of this. Fast tests, strict linters, expressive types and a clean build were always how a reviewer could trust a change without re-reading the whole system. The agent is just a new “team-mate” who benefits from exactly the same infrastructure.

This is not the machine checking the machine

I still read every line the agent writes. I want to be clear about that, because the argument I am making is easy to misread as letting the tools do the reviewing for me.

They do not. A linter cannot tell you the design is sound. It cannot tell you the abstraction is worth it or the name matches how the team talks. That judgment is mine and it stays mine.

What the tooling does is clear the mechanical work out of the way. Every rule I move from a document into a gate is one thing I no longer hunt for by hand in review. The formatting, the structure, the conventions that have a right answer are handled before I ever look. So when I read the code, my attention goes where a human is actually needed. Is this the right design? Are these the right names? Does this belong here at all?

That is what the tooling gives me back. A review where I spend all my attention on the questions only I can answer.

Take care of your tools

The conversation right now is all about the new machinery: the setups, the harnesses, the elaborate prompting. Some of it is worth learning. But a lot of what helps is sitting in tools you already know how to use, pointed at a new kind of team-mate.

A lint rule you write once takes care of you on every pull request that comes after it. Including the ones an agent opens while you sleep.

Felipe was right. Take care of your tools and your tools will take care of you.