The instruction file getting shorter, not longer

The instruction file that grew for six months

Picture the instruction file the way most of them actually get built. It starts as three honest lines: what the project is, what stack it's in, maybe a note about a naming convention. Then Claude does something you didn't like, so you add a rule. A week later it happens again, a different shape, so you add another. Six months in, the file is forty lines long, half of them quietly contradicting each other in ways nobody's caught, because nobody's read the whole thing in one sitting since March.

That instruction file is basically what a well-meaning manager does to a new hire's onboarding doc, except the new hire never gets to say "wait, rule twelve contradicts rule thirty-one, which one do I follow."

The reported reversal

Here's the part worth sitting with. The claim making the rounds is that Anthropic trimmed a large share of Claude Code's own system prompt and saw no drop in performance. I'd flag that as reported rather than something I measured myself, and I'd treat the exact percentage with some skepticism. But the direction lines up with what I see constantly in my own sessions: a short instruction that states what you want and trusts the model to use judgment for the rest tends to beat a long list of "never do this."

It makes sense once you think about why the rules pile up in the first place. Every rule in that forty-line file was a reasonable response to one specific bad outcome. The problem is that rules written in response to one bad outcome start fighting each other the moment two of them overlap, and the model burns effort resolving the conflict instead of doing the task you actually asked for.

What judgment looks like instead of a rule

The fix isn't write less and hope for the best. It's a specific swap: replace a blanket rule with a judgment call. "Never write comments" becomes "match the style of the surrounding code." "Never use this library" becomes a short note on why, so the model can weigh it against a case you didn't think of when you wrote the rule.

The practical version: keep your standing instructions to what's genuinely fixed, the project's purpose and the small number of things Claude can't see just by reading the code. Everything situational, a department's formatting quirk, a client's specific exception, belongs somewhere that loads only when it's actually needed, not in a file the model rereads on every single request whether it's relevant or not.

The onboarding version of the same idea

I keep coming back to the same comparison in training, because it maps so cleanly. You don't hand a new senior engineer a forty-page manual on their first day and expect them to internalize it before writing a line of code. You tell them what the codebase is for, the two or three things that will genuinely trip them up, and you trust them with the rest.

Handing them the manual instead is a worse bet on their judgment. It produces someone who follows the letter of rule fourteen instead of noticing that the situation in front of them doesn't match any rule at all.

There's now a built-in way to check your own bloat too, a command that scans an instruction file and flags what's stale or contradictory, roughly the equivalent of someone finally reading the whole rulebook you've been adding to for a year. Worth running as a second opinion. Not a substitute for reading the file yourself at least once.

What to try this week

Open your own instruction file and count the rules that start with "never." For each one, ask what specific bad outcome it was written to prevent, and whether a one-line judgment call would prevent the same outcome without also blocking every case you didn't anticipate.

Most files I look at in training don't need rule twelve. They need rules three through nine deleted, and the judgment those rules were trying to force handed back to the model. Shorter isn't the lazy version here. Deciding what actually needs to be said, and saying only that, is the harder discipline.