I deleted my CLAUDE.md. All 340 lines, one shot, no editing, no sorting through which rule still earns its place. The 9 skills went too, along with the 4 hooks and the 6 custom commands. Everything landed in a timestamped backup folder, nothing lost for real, just nothing active anymore. 6 days of normal work with zero rules to steer the agent, and I logged every single thing that broke.
What I actually wanted to know was simpler than it sounds and harder to answer. Out of everything I deleted, what actually mattered over those 6 days? And what was I about to re-add out of pure reflex, because it felt safer, not because it did anything? That question doesn't answer itself in an afternoon. It took the whole week, and even then part of the answer stayed open.
I figured the scary part would be the security guardrails. Never running rm -rf, never pushing straight to main, never touching the .env file, the kind of line you write once and hope you never have to stress test for real. Turned out that fear didn't pan out at all. Deleting a 340-line config in one shot felt like starting a permadeath run and hoping the boss patterns hadn't changed underneath me. They hadn't, mostly. What actually surprised me showed up somewhere else entirely.
Same Guy, 6 Months, Completely Different Advice
Back in January 2026, Boris Cherny (the guy who built Claude Code) described his own workflow in an InfoQ piece. Every team at Anthropic keeps a CLAUDE.md in git, and he tags Claude on his colleagues' pull requests to add each new lesson straight into the file. Compounding engineering, they called it. His team's file sat around 2,500 tokens at the time.
In July 2026, at Y Combinator's Startup School, same guy, opposite advice. Delete everything every 6 months, he told the room, and for Opus 5 specifically, he strongly recommends doing exactly that. Anthropic removed more than 80% of Claude Code's system prompt when Opus 5 shipped.
I'm not writing this to catch him in a contradiction. Both statements are true, just true on different dates, and that's the actual point. Config has a shelf life. I never tracked mine, and I'd bet you haven't tracked yours either. I wrote the structure I wrote up in February back when 340 lines still felt like discipline instead of debt.
Convention or Patch: The Sort That Never Happens
Every line in a config file belongs to 1 of 2 families, and they age completely differently. Some lines are project conventions. We use pnpm. Clerk handles auth. Supabase is blob storage only, nothing else touches it. Those don't expire until the project itself changes shape. Other lines are behavior patches, written the day the model screwed up. Don't overwrite the tests. Call Glob before you propose changes. Those expire the moment the model stops making that exact mistake, which is usually the next release.
Both families live in the same markdown file, same syntax, no date stamped on either one, no author, no reason attached. Nothing on the page tells you which is which. That's why I never actually went back and reread my own file front to back. There's no sorting mechanism, so the only strategy left is to keep piling on. One reader put it better than I could when he called his own file scaffolding for weaknesses that stopped existing 2 versions ago, still sitting there, still burning context on every single call. That's the whole disease in one sentence.
Take the Glob rule. I added it in April 2026 after Opus 4.7 got weirdly literal about following instructions, so "check the project structure" turned into "you MUST call Glob," in the exact rewrite I shipped for Opus 4.7. I never went back to check if Opus 5 still needs that shove. Not once, and I'm the one who wrote it. It just sat there getting reread on every turn, eating instruction budget for a bug that might already be dead.
Every dead patch you never questioned is doing the exact same thing right now, in your file, quietly. You just haven't noticed which lines they are yet.
The Protocol: What to Cut, What to Measure
This is the protocol, in order, if you want to run it yourself.
Back everything up to a timestamped folder instead of deleting outright. No save state, no backsies, that's how horror movies start, not experiments.
Cut in layers, not all at once, especially on production code: skills and hooks first, then custom commands, then CLAUDE.md itself, with the security guardrails held back until the very end of the cut, not the beginning.
Decide what you're measuring before you start, or you'll measure nothing. I tracked 3 things: manual corrections per session, how often I had to re-explain context the agent should already have had, and any real incident with its severity attached.
Run it for several days minimum. A single session tells you nothing, you'll mistake noise for a real signal (and I nearly did, on day 2, when nothing broke and I got cocky about it). The log is the actual tool here. Not the config file. The log.
Day 3, my nephew came over and wanted help with a Scratch project that kept crashing for reasons neither of us could explain. 20 minutes debugging block logic with none of my usual tools. Makes you appreciate stack traces 😅
I'll admit the timing of this whole thing is basically an accident. I wasn't planning a 6-day ablation test, I was planning a normal week, and it turned into one because enough broke on day 1 that I decided to just keep going and see.
What Came Back, and in What Order
3 families came back, and not evenly.
The security guardrails came back first, same day, no debate, respawning like NPCs that reset on schedule whether you want them to or not. The cost of a false negative there is permanent, not a probability you gamble against for the sake of a cleaner file.
Project conventions the model couldn't infer from the code came back next, because the model kept guessing wrong without them. A Convex query can't call a mutation, it has to go through an action, and no amount of staring at the codebase tells you that on its own.
Behavior patches, the actual patches, almost none of them came back. The model just wasn't making those old mistakes anymore. Out of 340 lines, 11 survived the cleanup.
A rule doesn't die when the bug does. It dies when someone finally deletes it.
That gave me an actual threshold, pulled from the log rather than decided in advance: a line only earns its way back after at least 2 identical failures, because every single-occurrence failure in my log never repeated. That's the rule I'm keeping, not my specific file. Your 11 lines will look nothing like mine.
Honest caveat, and I'm not dodging it: some of what came back might be comfort, not necessity. I never ran a real line-by-line A/B test, so a few of those 11 might survive purely because removing them felt worse than keeping them, not because the log actually demanded it.
The threshold holds for 1 model on 1 harness. Whether it holds anywhere else is a different question entirely, and not one 6 days can answer.
11 Lines, and What I Still Doubt
Most of my config was scaffolding for model weaknesses that had already been fixed, and I was making the agent reread it on every single turn for nothing. 11 lines made it back.
What I don't know, I'll say plainly. I'm honestly not sure if those 11 lines are load-bearing or just reassuring, I never ran the A/B test that would tell me for sure. I don't know how long this leaner file stays clean either, and nothing here suggests decay runs on any kind of predictable schedule. And I don't know if any of this transfers past Claude, since Anthropic trains and evaluates against its own harness, which means an AGENTS.md read by a different model isn't guaranteed to behave the same way just because the file looks the same.
That last one isn't hypothetical for me anymore. I've been leaning on Grok and Codex more this year on top of Claude Code, and I've quietly moved from a Claude-only CLAUDE.md to an AGENTS.md with CLAUDE.md as a symlink pointing at it. Model-agnostic config, in theory. Whether the 11 surviving lines mean the same thing to 3 different models is exactly the part I can't verify yet.
The next ablation is already on the calendar 📅
Sources
- Boris Cherny, "Building Claude Code," Y Combinator Root Access transcript, July 28, 2026
- "Inside the Development Workflow of Claude Code's Creator," InfoQ, January 2026
This post may contain affiliate links. If you click them, I might earn a small commission (costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure).
Top comments (0)