A bloated CLAUDE.md file doesn’t make Claude Code smarter, it makes it forget. That’s the blunt takeaway from a benchmark one team just ran, and the numbers back it up. This Reddit user, who leads a dev team wrestling with Claude Code on a backend repo, watched their root instructions file grow from a handful of rules to 450 lines over two months, while the failure rate climbed right along with it.
Here’s how it started, and it’ll sound familiar if you’ve ever babysat a coding agent. Every time Claude Code made an architectural mistake, ran the wrong test command, or reached for a deprecated import, the fix was the same: add a bullet to CLAUDE.md. Reasonable in isolation, disastrous in aggregate. By month two, the original poster noticed the model following the first three rules and the last two, then quietly skipping the 25 specific edge cases buried in the middle, half of which pointed at file paths and mocking conventions the codebase had already outgrown.
So the team ran an actual test instead of just complaining about it. 40 multi-file refactoring tasks on their backend repo, split two ways: Setup A kept the full 450-line static file loaded every single session. Setup B swapped it for a lean 25-line root file paired with a harness that loads task-specific “skills” on demand and prunes the stale ones on its own. Setup B won, and not by a little.
- 📉 Regression errors dropped 38.4%. In Setup A, old rules kept fighting new codebase patterns, and the model kept hallucinating deprecated imports because of it. Setup B only loaded what the current task actually needed, so the working context stayed clean instead of arguing with itself.
- 💰 Token spend fell more than 45%. Baseline input tokens per turn went from roughly 18,500 down to under 3,200. Nobody was paying full price to re-read 400 lines of static text on every command round-trip anymore, and that adds up fast once you’re running real sessions all day.
- 🧹 Stale rules are the actual killer, not missing ones. This is the sharpest part of the author’s writeup: Claude Code doesn’t usually fail because it lacks instructions, it fails because old instructions are actively lying to it. Once a library API changes, an unpruned rule keeps training the model to write code that fails CI, and nobody notices until the build breaks.
To make Setup B usable for the rest of us, the team open-sourced the harness as autoharness. It watches your terminal sessions, and when you finish a debugging or setup task, it distills the verified command sequence into a modular SKILL.md file. Those skills only enter the prompt when that specific task comes up. If a skill goes untriggered for a while, or points at files that no longer exist, autoharness quietly retires it on its own. No daemons, no local vector database, no telemetry, just plain Python doing the cleanup for you.
That’s worth sitting with for a second, because most “give your agent memory” tools go the other direction. They stack on a vector database, an embedding pipeline, some background indexing service, and now you’re debugging your memory layer instead of your actual codebase. Autoharness skips all of it. It’s a pruning mechanism first, a storage layer second, which matches the whole point of the experiment: less loaded context, not a fancier way to load more of it.
Getting started looks simple on paper. Trim your root instructions file down to the handful of rules that never change, run your normal sessions, and let the tool distill the verified sequences into skills as you go. The tradeoff nobody in the thread has fully stress-tested yet is how this holds up on a much smaller repo, where 40 multi-file refactors and a 450-line file were never going to be the setup in the first place. One commenter raised exactly that: if the codebase changes shape every month anyway, is pruning old skills actually less work than pruning old rules? Fair question, and one worth testing on your own repo before you trust the defaults.
If your own CLAUDE.md has turned into a junk drawer, that’s the tell. I’ve seen this exact failure mode plenty of times myself: you add a rule to fix one bad session, and three weeks later that same rule is quietly lying to the model about your own codebase.
Worth pulling up the original Reddit thread. The full comparison is there, plus a comments section arguing about whether a harness like this is overkill for smaller projects or exactly what every growing repo needs.
Frequently Asked Questions
Q: How should I structure my agent instructions to avoid the 450-line problem?
Keep the root file lean, 25 to 110 lines max, focused on core goals, hard rules you never break, how to run your tests, and where truth lives in the repo. Then load task-specific instructions on demand instead of dumping everything at once. That’s the pattern wegster uses in practice, and it mirrors the article’s “Setup B” approach.
Q: Why does a 450-line static file cause more errors than a dynamic system?
It’s not that the model ignores your instructions. It’s that when you pile everything in one file, first and last rules dominate, the middle stuff gets buried and ignored. Worse, stale rules that no longer match your codebase are actively harmful: they teach wrong patterns with total confidence.
Q: How often should I prune or update my instruction rules?
Don’t wait for scheduled cleanup, update as soon as CI fails in a familiar way or you refactor a dependency. Stale rules accumulate silently, so catch them when they happen. Even without automation, staying on top of this as your codebase evolves pays real dividends.
Q: What’s the minimal instruction set I actually need?
Your root file should cover: core goals and principles, hard don’t-evers, how to run your actual tests, and where the repo’s truth lives. Everything else, library APIs, deprecated imports, custom conventions, goes into task-specific packs that load only when you need them.
Q: How do I know if I’ve pruned too aggressively?
After pruning, run a few tricky multi-file tasks to spot regressions, if failures jump, you cut something real. Also track something simple: how often are failures citing rules that don’t match your repo anymore? That’s your “junk-drawer tax” showing where instructions are out of sync.
We tested giving Claude Code a 450-line static prompt vs a self-learning harness (and measured a 38.4% drop in regression errors)
by u/Least_Arm3744 in PromptEngineering