45 lines. That's where one developer's CLAUDE.md started - clean conventions, tight instructions, everything followed. Three months and 190 lines later, Claude was ignoring more rules than when the file was lean.
The pattern is familiar to anyone who's spent serious time with Claude Code. Something slips through, so you add a rule. Something else slips through, so you add another. The file grows, and the compliance rate drops. Instructions past roughly line 100 start getting treated as suggestions rather than requirements.
This isn't a mystery if you think about how context windows work. CLAUDE.md gets injected into every conversation as system-level context. The longer it gets, the more each individual instruction competes for attention against everything else in the prompt. It's the same reason a one-page brief gets followed more carefully than a 20-page specification.
Rules That Don't Enforce Themselves Are Wishes
The core insight is the difference between telling Claude what to do and building systems that make the wrong thing hard to do. A line in CLAUDE.md saying "always run tests before committing" is a suggestion. A pre-commit hook that blocks the commit if tests fail is infrastructure.
Claude Code already supports hooks - shell commands that fire on specific events like tool calls and conversation turns. Moving your most critical rules from passive text into active enforcement means they work every time, not just when Claude happens to weight that part of the context highly enough.
Some concrete moves that work better than adding more lines:
- Pre-commit hooks for code standards instead of "please follow our style guide"
- Validation scripts called by hooks instead of "always check X before Y"
- File templates instead of "new files should include these sections"
- CI checks instead of "make sure the build passes"
What Should Actually Stay in CLAUDE.md
The file still matters - it's how you give Claude project context, coding conventions, and architectural decisions it can't infer from the code alone. The key is keeping it focused on things that genuinely need to be understood, not things that need to be enforced.
Good candidates for CLAUDE.md: project architecture explanations, tech stack decisions and why they were made, naming conventions, file organization patterns, and domain-specific context that helps Claude make better decisions.
Bad candidates: anything with the word "always" or "never" that you actually need followed 100% of the time. Those belong in hooks, linters, or CI.
The practical ceiling seems to be around 80-100 lines of genuinely useful context. Past that, you're not adding clarity - you're adding noise. If your CLAUDE.md has grown past that range, it's worth auditing which rules could become hooks and which context is actually helping Claude make better decisions versus just making you feel like you've documented everything.