Andrej Karpathy posted his four CLAUDE.md rules and the internet did what it does. Ask before you assume. Prefer the simplest solution. Don’t touch unrelated code. Flag uncertainty explicitly. Clean, sane, hard to argue with. Thousands of people pasted them straight into their own config and moved on.

Then the most-upvoted reply added a fifth rule, and it quietly reverses the whole thing: don’t hesitate to suggest a better way. The person who wrote it had noticed that Karpathy’s four had turned Claude into a vending machine. You put a spec in, code comes out, it never argues. Every one of the four rules is a restraint. Not one of them leaves room for the model to think back at you.

The Four Rules Are About Control

Look at what they’re each defending against:

  • Ask don’t assume defends against a model that guesses wrong and runs with it.
  • Simplest solution first defends against a model that over-engineers.
  • Don’t touch unrelated code defends against a model that sprawls across your codebase uninvited.
  • Flag uncertainty defends against a model that bluffs.

Every rule is patching a failure mode of a model that wanders. They are guardrails, and guardrails exist because something is prone to leaving the road. That’s not a criticism. For a lot of models, on a lot of days, it’s exactly right.

But guardrails have a cost, and the cost is the thing the fifth rule is reaching for.

Rules Aren’t Model-Agnostic

Here’s the part nobody puts in their config notes: the right CLAUDE.md depends on which model you’re running, and the dependency is inverse. The stronger the model, the more your defensive rules cost you.

I’ve watched this play out in the data before. Architectural constraints that weak models violated 80% of the time, strong models followed for free, which means the constraint stopped protecting anything and became pure noise in the context. A 25-word restraint in the system prompt that read fine in isolation degraded a strong model’s coding by 3%, because it starved the model of the working-thought bandwidth it actually uses to reason. And we know instruction density itself degrades compliance: every rule you add dilutes every other rule, and a frontier model has more reasoning capacity to lose.

Put those together and the picture is clear. A defensive rule that stops a weak model from rewriting your auth layer is the same rule that gags a strong model from telling you the auth layer is wrong. Same words. Opposite effect. The model got better and your config didn’t move.

You are paying frontier prices for a model that second-guesses itself, and then writing four rules whose entire job is to stop it from second-guessing you. The fifth rule isn’t an addition to the framework. It’s the admission that the first four were tuned for a model you’ve stopped running.

Permission to Reason Is the Expensive Part

The whole headline feature of the current top models is doubt. Opus 4.8’s standout trait is that it spends tokens catching its own mistakes and flagging what it isn’t sure of. That self-correction is the thing you’re buying. A CLAUDE.md that only ever says “do less, ask first, stay in your lane” is a config that suppresses the one behaviour worth the money. It’s telling a grandmaster to only consider the first three moves.

The fifth rule turns that back on. It says: when you see a better path, say so. When my spec is wrong, push. Reason out loud and I’ll decide. That’s not loosening the rules. It’s matching them to a model that can actually carry the weight.

Rule five and rule three are in tension on purpose

“Suggest a better way” and “don’t touch unrelated code” point in opposite directions, and that conflict is the actual lesson. You don’t resolve it by deleting one. You resolve it by separating proposing from acting: the model is free to tell you the whole approach is wrong, and still not allowed to go rewrite three files to prove it without asking. Suggest loudly, act narrowly. Most people’s configs forbid both, and then they wonder why the model feels lobotomised.

What This Doesn’t Mean

Don’t over-correct into the opposite mistake:

  • You still need some rules. “Suggest a better way” handed to a model that genuinely wanders produces a confident rewrite of your working code every third prompt. The defensive rules aren’t wrong, they’re un-calibrated. The skill is knowing which of yours are guardrails and which are gags.
  • Strong models still wander on big codebases. Capability isn’t a free pass. The bigger the repo and the longer the session, the more even a good model benefits from “don’t touch unrelated code.” Context size pulls the dial back toward restraint regardless of model strength.
  • Viral configs are a starting point, not a setting. The reason to read Karpathy’s four rules isn’t to copy them. It’s to see your own implicit rules reflected back, including the one you never wrote down because you didn’t know you believed it.

Closing

A CLAUDE.md is a statement about what you want from intelligence. Four rules of restraint say you want a careful typist. A fifth rule of “suggest a better way” says you want a colleague who’ll tell you when you’re wrong. Both are legitimate. They’re just for different models, and the upgrade that should change your config is the one most people never make: the model under the file got smart, and the file stayed scared of it.