Should You Delete Your CLAUDE.md Every 6 Months? What Boris Cherny Actually Meant
Boris Cherny told a Y Combinator crowd to delete your AI layer every six months. Cole Medin ran the actual benchmark to find out which parts of that advice hold up and which don't.
Posted
1 weeks ago
Duration
Format
Essay
educational
Views
8.9K
192 likes
57 · 43
Big Idea
The argument in one line.
Boris Cherny's 'delete everything every six months' advice is really a call to run ablation, and it only holds for global rules like CLAUDE.md — not skills, hooks, or sub-agents, which cost nothing until they fire.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You maintain a CLAUDE.md, skills, or hooks for Claude Code (or any coding agent) and haven't revisited them since your last model upgrade.
You saw the Boris Cherny quote floating around and want to know what he actually meant before you delete anything.
You want an actual before/after benchmark, not just a hot take, before you start pruning your own rules.
You maintain a large, mature codebase where your AI layer has quietly grown past a few hundred lines.
SKIP IF…
You're brand new to coding agents and don't have a CLAUDE.md or skills yet — there's nothing to ablate.
You only use Claude Code as a one-off tool with no ongoing project rules to prune.
TL;DR
The full version, fast.
Boris Cherny said Claude Code users should delete their CLAUDE.md, skills, and hooks every six months and see what the model does without them. That's shorthand for 'ablation' — Anthropic strips its own system prompt and adds instructions back line by line to measure each one's real impact, which is how they cut 80% of it for Opus 5. This video's creator ran the same test on a mature codebase: a 1,000-line CLAUDE.md versus a stripped ~20-line version. Both handled hard architectural decisions equally well. The stripped version broke on project-specific house rules — test registration, function style, imports. Conclusion: cut global rules aggressively, but leave skills and sub-agents alone.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Cole opens with the viral tweet quoting Boris Cherny's Y Combinator remarks about deleting your AI layer every six months, framing the video around what it actually means.
01:16 – 02:48
02 · What Boris Cherny Actually Said
Clips from the live Y Combinator talk: Boris says to delete your CLAUDE.md, skills, and hooks every six months and see what the model does, and that people are misreading this as 'just delete everything.'
02:48 – 03:28
03 · Ablation Is an Eval, Not Just Deleting
Boris clarifies that Anthropic doesn't fully delete their system prompt — they run 'ablation,' stripping instructions and restoring them line by line to measure each line's actual impact, like an eval.
03:28 – 04:21
04 · The Over-Specification Mistake
Boris describes a common failure: giving Claude Code overly rigid step-by-step instructions instead of describing the task, guardrails, and exit criteria and letting the model work it out.
04:21 – 05:16
05 · Why Ablation Gets Expensive
Cole agrees with the theory but flags that full ablation — wiping everything and re-adding it line by line while testing — is extremely token-expensive and impractical for most teams.
05:16 – 06:43
06 · The Unlimited Token Budget Problem
A clip shows Boris describing a Claude Code agent that ran for a little over two weeks migrating a codebase from Electron to Swift, which Cole argues reveals an unlimited-token-budget blind spot.
06:43 – 08:36
07 · Sponsor: CodeRabbit
Sponsor segment for CodeRabbit's Change Stack feature, which reorganizes large pull requests into ordered, reviewable cohorts instead of a flat file list.
08:36 – 10:29
08 · The AI Layer Spectrum
Cole introduces his own framework, the 'AI Layer Spectrum,' running from always-loaded CLAUDE.md (highest prune pressure) to on-demand sub-agents (lowest), arguing prune pressure should follow load frequency, not word count.
10:29 – 12:38
09 · Where I Agree With Boris and Where I Don't
Cole cites Anthropic's own Claude Code documentation on common failure patterns — an over-specified CLAUDE.md and a target of under 200 lines — to argue aggressive pruning applies mainly to global rules.
12:38 – 15:02
10 · Testing Full Ablation on Archon
Cole runs his own benchmark on Archon, his mature open-source harness builder, comparing its 1,000-line CLAUDE.md against a fully stripped ~20-line version and a stripped project skill, on identical GitHub issues with the same model.
15:02 – 17:57
11 · Architecture Held Up, Conventions Broke
Results: both layers handled hard architectural calls equally well, but the stripped layer broke on project-specific house rules like test registration and code style — the conclusion is rules that fix reasoning decay, rules that direct attention don't.
17:57 – 19:38
12 · The Ablation Skill (Any Coding Agent)
Cole walks through the Claude Code skill he built to automate this process: mapping the AI layer, generating a real probe task, running it with and without the full layer, and grading the difference.
19:38 – 20:00
13 · Outro
Cole points to his new public skills repo on GitHub and closes with a like-and-subscribe ask.
Atomic Insights
Lines worth screenshotting.
Boris Cherny's 'delete everything every six months' advice is really describing ablation — stripping instructions and adding them back line by line to measure each one's impact — not a one-time wipe.
Anthropic didn't delete Claude Code's entire system prompt; they cut roughly 80% of it through this line-by-line ablation process.
Overly rigid step-by-step instructions hurt modern coding models more than they help — describing the task, guardrails, and exit criteria works better than scripting every step.
Full ablation is extremely token-expensive, since it means wiping an entire AI layer and rebuilding it back up piece by piece while testing.
A Claude Code agent using Opus reportedly ran for a little over two weeks migrating an entire codebase from Electron to Swift, burning what would be millions of tokens.
Prune pressure should follow how often a piece of context loads, not how much of it you wrote — a bloated skill costs nothing until it fires, while a bloated CLAUDE.md costs tokens on every session.
Anthropic's own Claude Code docs recommend keeping CLAUDE.md under roughly 200 lines, warning that an over-specified file gets ignored because important rules get lost in the noise.
On a real 1,000-line CLAUDE.md test, a fully stripped ~20-line version handled hard architectural decisions just as well as the full file.
The stripped-down AI layer broke specifically on project-specific house rules — test registration, function style, import order — not on reasoning.
Rules that exist to fix an LLM's reasoning gaps decay as models improve; rules that direct the model's attention to your specific conventions don't decay at the same rate.
The practical rule of thumb: cut CLAUDE.md and global rules hard and often, but leave skills and sub-agents alone unless you're willing to do a full ablation about once a year.
A repository's own AI-authoring skills and sub-agent instructions can stay bloated for a long time with almost no measurable performance cost, because they only load on demand.
Takeaway
Cut your CLAUDE.md hard; leave skills and sub-agents alone
WHAT TO PRUNE
The parts of your AI layer that cost tokens on every single session deserve aggressive, frequent pruning, while the parts that only load on demand can stay bloated for years without hurting performance.
02What Boris Cherny Actually Said
Boris Cherny's viral line was 'every six months, delete your CLAUDE.md, delete your skills, delete your hooks, and see what the model does' — often quoted stripped of its context.
Read alone, the quote sounds like a mic-drop claim that any AI layer you built is now obsolete because current models are simply better.
03Ablation Is an Eval, Not Just Deleting
Anthropic doesn't actually delete its entire system prompt; they strip it down and add lines back one at a time, calling this process ablation.
Ablation functions as an eval: each restored line gets measured for whether it actually changes the model's output before it's kept.
04The Over-Specification Mistake
A common failure mode is giving Claude Code overly rigid step-by-step instructions instead of describing the task, the guardrails, and the exit criteria.
Modern models do better when you describe the outcome you want and let them work out the steps, rather than scripting every move.
05Why Ablation Gets Expensive
Running full ablation — wiping an entire AI layer and rebuilding it back up while testing each piece — is extremely token-expensive to do properly.
That expense makes ablation impractical for anyone paying per token or working within a capped subscription, not just enterprises with unlimited budgets.
06The Unlimited Token Budget Problem
Anthropic's own team described letting a Claude Code agent run for a little over two weeks migrating a codebase from Electron to Swift.
That kind of session implies a token budget most builders don't have, which undercuts how universally applicable the 'just let it run' advice really is.
08The AI Layer Spectrum
Context sits on a spectrum from always-loaded (CLAUDE.md, global rules) to on-demand (skills, sub-agents), and prune pressure should track how often something loads, not how much was written.
A bloated skill or sub-agent costs nothing until it actually fires, so it doesn't deserve the same pruning urgency as a bloated global rules file.
09Where I Agree With Boris and Where I Don't
Anthropic's own Claude Code documentation recommends keeping CLAUDE.md under roughly 200 lines, warning that an over-specified file causes the model to ignore important rules.
The case for aggressive ablation is strongest for global rules specifically, and weakest for skills, sub-agents, and other on-demand context.
10Testing Full Ablation on Archon
A real-world test compared a mature project's 1,000-line CLAUDE.md against a fully stripped ~20-line version, run against the same GitHub issues with the same model.
The stripped version also removed a 350-line project skill entirely, forcing the model to infer how to work in the codebase from the code itself.
11Architecture Held Up, Conventions Broke
Both the full and stripped AI layers made equally good hard architectural decisions, meaning most of that guidance had genuinely become dead weight.
The stripped layer broke specifically on project-specific conventions — how tests get registered, how functions are styled, how imports are organized.
The conclusion: rules that exist to fix an LLM's reasoning gaps decay as models improve, but rules that direct attention to your specific standards don't.
12The Ablation Skill (Any Coding Agent)
A public Claude Code skill automates this process: it maps your AI layer, generates a real probe task, runs it with and without the full layer, and grades the difference.
The skill works with any coding agent, not just Claude Code, since the underlying ablation method is agent-agnostic.
Glossary
Terms worth knowing.
Ablation
Anthropic's term for stripping an AI agent's instructions down to nothing and adding pieces back one at a time to measure each piece's real impact on performance.
AI layer
The combined set of a coding agent's CLAUDE.md, global rules, skills, hooks, and sub-agents that shape how it behaves on a given project.
CLAUDE.md
The global instructions file Claude Code loads into context at the start of every session, regardless of what task is being worked on.
Skill (Claude Code)
An on-demand markdown instruction set that only loads into context when the agent decides to use it, unlike always-loaded global rules.
Sub-agent
A delegated worker in a coding-agent workflow that runs a specific task with its own instructions, separate from the main session's context.
Hook
A deterministic script that fires automatically at a defined point in an agent's workflow without consuming ongoing attention or context.
10:29linkClaude Code docs — Store instructions and memories / Write effective instructions
Quotables
Lines you could clip.
01:22
“Be comfortable and brave to press delete.”
Boris's own soundbite from the stage — tight, punchy, no setup needed.→ TikTok hook↗ Tweet quote
06:29
“It's been a little over two weeks.”
Sets up the reveal about a two-week, multi-million-token Claude Code session.→ IG reel cold open↗ Tweet quote
04:00
“Let the model cook.”
Short, quotable summary of Boris's core advice on instruction style.→ newsletter pull-quote↗ Tweet quote
15:02
“Rules that fix reasoning have decayed. Rules that direct attention have not.”
The single-sentence thesis of the whole benchmark, displayed on screen and clean enough to stand alone.→ TikTok hook↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogystory
You and I both know that the AI space is always moving too fast because there's always that next thing you're told you should learn, like loop engineering or graph engineering. And even worse than that, a lot of times you're told that what you currently have is obsolete and you should move away from it as soon as you can.
So Boris Churney, the creator of Clawd Code, he recently said some things that make it seem like we're running into this again, where we're being told what we've built is obsolete. Because he said in an interview recently, every six months, we should delete our entire AI layer, our global rules, our skills, our hooks, everything we worked hard to build because you'd be surprised what the LLM is capable of without your guidance.
And so taking this at face value, it just seems like Boris is looking down on us saying, your hardest, your AI layer that you worked so hard to build is now obsolete because Opus five is just that good. And that's not exactly what he's saying. There's a lot more nuance we have to get into here.
A lot of people are misinterpreting what he really is saying because they're reading this tweet and just moving on. So that's what I wanna cover with you, what Boris really means because there's a lot of truth and good suggestions with what he's talking about, but also some disagreements that I have as well.
So I wanna break this down nice and simple for you because there are some actionable things that I would recommend you do right away. So we'll cover that as well. But first, let's get into what Boris is really saying here.
So let's hear it from the man himself. I'm gonna play just a couple of clips from the live Y Combinator event. You might have seen this already.
If you did, don't worry. I'm not gonna watch the entire thing with you here. Just a couple of clips to set the stage.
I'll also link to this in the description. So let's start right here with the big mic drop moment. 100%.
Yeah. And and for people that aren't building agentic products but you're using Cloud Code Here we go. Every six months, delete your CloudMD.
Delete your skills. Delete your hooks. See what the model does, and it might surprise And actually for Opus five, this is something we really do recommend is just try deleting all of these things because the model might
really just not need all those instructions that you needed for past models. Wow. So just those few sentences, if you don't watch the rest of the talk, it really does seem like Opus is too good for you.
Just delete all of your instructions. But then just like a minute before he says that, he says something a bit softer where they're not just deleting everything. They're doing a process called ablation.
I'll I'll let him just explain it really quick right here. That's right. That's right.
We So to be fair, we don't delete the entire codebase, but we do delete a lot.
So every time there's a new model, we try In research, we call this ablation. And so what this means is you delete the entire system prompt and then you bring it back line by line to figure out what is the impact of each individual line. It's sort of like an eval, and you can kind of like evaluate it, and ablation essentially it's an eval, but you delete things to figure out the impact.
And There we go. That's the real truth there. So we're not just wiping everything and trusting the model entirely.
We're doing it for the sake of really evaluating what we actually need in our AI layer. So you're bringing things back as you recognize that, oh, this skill or this rule actually did help the model get better results for me even if it is the latest and greatest LLM.
And so the general premise that Boris is presenting here, it makes sense. As LLMs get better and better, there's less you need to specify as far as your rules and guardrails to make it so that it works up to your standard.
And so there might be a lot that you have in your harness that might be actually hurting the LLM more than helping because you're restricting it. There's a bit more that he has to say about that right here. Let me play this clip for you as well.
A really common mistake that I see is people are using quad code, they're using quad in, they they just give it, like, way overly specific instructions. They're like, I want you to do this. Want you to do it in this way, this way, this way.
You must do, like, one, then two, then three, then four. And for modern models, that's actually really not the way to do it. You wanna go a little bit higher level.
You wanna describe the task, wanna describe the guardrails, you wanna describe like the exit criteria, and then just go with the model cook.
And Let the model cook. And so really, ablation is the process for us to figure out where are we being too specific with the modern large language model. But we just do it backwards because we start with nothing and we add things back in as we figure out the coding agent really needs that guidance even if it is Fable or Opus or GPT Soul, whatever the top model is.
And so it's good in theory, but there's a couple of problems that I have with this. It's very, very expensive to do this process of ablation, and there are definitely some things that it really doesn't make sense to scrap and add back in.
Let's talk about this. And I'll also show you a lot of testing that I did that shows that Boris is right. His advice is solid, at least to an extent.
The larger problem that I have with this is it's not always practical for us to wipe our entire AI layer and build it back up. And at the end, I'll also give you a skill that I built to guide you through the same ablation process that I went through as I was testing and auditing things on my own code bases. But anyway, the main problem that I have with ablation as Boris presents it is it's extremely token heavy.
It is so expensive to go through that process of wiping everything and then adding things back in one piece at a time as you are testing and working with your agent. In fact, a lot of the things that Boris talks about throughout that live event, it just makes it really obvious that he's blind to the fact that tokens are actually pretty expensive.
I mean, he just makes it so obvious that he works for Anthropic where they give him an unlimited token budget because so many of the strategies that he talks about is just letting the agent run for a very, long time. And let me tell you, that's just not always practical because you're at an enterprise setting where you're paying per token or you just have subscriptions where you're already hitting rate limits all the time with Fable and Opus.
And so when he talks about running these sessions for two weeks to do these really incredible things, Sometimes it just seems like he's in his own little bubble of having unlimited tokens, just him and Peter Steinberger. And I know I'm probably beating a dead horse here showing you a clip from the talk where he talks about how long his agents run for, but it's kinda funny just to hear him talk about this.
So he just finished sharing how he migrated an entire code base from Electron to Swift. And then she asks him, well, how long did it take? Take a look at this.
And how long did this take to run? It's still running.
When did you start it? It's been it's been a little over two weeks.
A little over two weeks.
It's gonna be millions of tokens. I don't if anyone in the audience saw it. Okay.
I'm gonna pause it there. Yeah. It's just it's crazy.
Like, we can't do that even with a Max Claude subscription unless maybe you're using like a mixture of Sona and Haiku, but he's talking about using Opus five. Let's take a quick break for today's sponsor. This one fits really well with this video because when you're coding with agents, the bottleneck stops being writing code and it becomes reviewing it.
And CodeRabbit is incredibly helpful for removing that bottleneck. I use them personally all the time across all my open source projects including my big one, Arkon.
And today, I wanna show you their new review surface called change stack. A pull request is the most classic way to make any changes to a code base. The problem is every PR is just a flat list of alphabetically organized files.
There is no organization here. So you have to go through the entire git diff to review everything. And this works fine when you have a few small scope changes, but when you're scaling the amount of work you're doing with the coding agent, pretty much no matter what, you're gonna have massive pull requests, dozens of files that are changed.
You need a way to organize things better to be able to scale your review. So what change stack does is it reorganizes the same PR into cohorts. So we have the individual pieces of work in the change and it even orders them into layers.
So the data models and contracts come before the code that depends on them. It's exactly how an engineer would go through a PR and it builds that organization for us. And there are a lot of great features in here.
For example, the semantic diff shows me move code as moved, not just an addition and a removal so I don't have to reconcile that in my head. And I can click on any one of the functions here to also see the definition and then where it is referenced in my code base. And going to my actual Arkon PR, we can see CodeRabbit running in the wild, giving the full walkthrough as it's reviewing the changes.
And sure enough, it found real issues with this PR and also giving suggestions for each of these things and I can also reply to Codebabbit to have a conversation to clarify anything I need. Codebabbit is free for open source, which is how I've been using it and ChangeStack is free during launch. I'll have a link to them in the description.
And so the point is, yes, your AI layer is probably too bloated. You're probably being too specific on certain things for LLMs these days, but it's not realistic to just prune everything.
I don't think you should. It's gonna take you so much time. It's gonna be so expensive.
And there's so many things in our AI layer where even if it is a little too bloated, it really doesn't hurt the performance of your coding agents. Let's talk about the spectrum now. And this is really the core of where I disagree with Boris.
So when we think about our AI layer, there are really three components of it that contribute to the context for our agent. We have our rules, like our global rules and other contexts that we have the agent read or that we inject. We have our skills, our workflows, and then we have our sub agents, the workers that we delegate to.
And out of everything that we have here, it's really only the rules that we should be cutting hard because this is the context, especially your global rules. It's the context that's loaded in at the start of every single conversation.
So we have the largest risk there of over specifying things and restricting the LLM because it always has to follow those guidelines. And Anthropic talks about this a lot in the Claude Co documentation, and this is good advice no matter the coding agent you're using.
So they have this section talking about the common failure patterns to avoid for your rules, And one of the big ones right here, the over specified Claude dot m d. If your global rules are too long, Claude ignores half of it because important rules get lost in the noise. It can actually hurt performance.
And then when they're covering memory, writing effective instructions, they say to actually target under 200 lines per claw dot m d file. Your global rules need to be concise because the spectrum that we have here goes from what is dumped in the agent every single time versus what are the things that are more context efficient, not always taking up that mental bandwidth of your agent.
And so this spectrum actually kind of also speaks to how much I agree with Boris on certain things. Right? Like with the rules here, there is a lot of pruning pressure.
It's important to keep this lean. I agree with Boris that you do pretty frequently want to test out a very shrunken version of your rules. But then as you go up the spectrum here into skills and other kinds of on demand context your agent is only sometimes reading, it gets a lot less important for you to go through the process of trying to make things more concise.
And if you're focusing primarily on just your global rules, that also makes things a lot less of a pain for you and a lot less expensive to go through this ablation process. And so, like I said, Boris' ideas here are sound. I just don't think they apply to as much as he's really saying.
Like sub agents, skills, other kinds of on demand context you might have as markdown or confluence pages. Like these are the things that I don't touch very often. I make it work initially and then I'm sticking with that through all the new model releases.
But then, yes, I'll concede to him that for the global rules, like, definitely, you want to be picky here. And, yes, in a perfect world where you have unlimited time and budget like it seems Boris has, of course, it makes sense to go through the ablation process for everything in your AI layer because each large language model interprets your instructions even just a little bit differently.
So there's always gonna be room to optimize and even build things from the ground up if you really want to. It's just in the real world, there has to be a line that we draw for where does it make sense for our time and tokens, what should we ablate. And so that's my argument that we wanna stick more to this side of things.
And if you really wanna push it to skills or sub agents, maybe do that once in a while like, you know, every year for example. I just wouldn't recommend doing it every single time an LLM releases and doing it every six months like Boris said just seems a little aggressive to me. And maybe you actually like that idea quite a bit.
I'd be curious, let me know in the comments if you think like, okay, I actually do wanna go through and wipe everything every half year. If you wanna spend the time to do that, let me know. I'd be curious as to your reasoning why.
And then as promised, of course, I also wanna show you my own testing that I did on one of my code bases. And this is important because it shows us the kinds of rules we really need no matter what versus other rules we really can get rid of as LLMs get more capable. And so the stripped bare, the ablated AI layer, it did hold up for some things.
Boris is right to some extent, but then there are some kinds of rules where when I took them away, my performance degraded quickly. Quickly. So if you've seen my content before, then it probably comes as no surprise that I wanted to test out on Arkon, my open source harness builder.
I'll link to a video right here where I cover it. Not really the point of this video, I just wanted to pick a pretty complicated code base. Arkon at this point is a very evolved and mature application.
And so I kind of hate to admit this on camera, but the global rule file that we have right now, rclaw dot m d to work on Arkon is a thousand lines long. And, yeah, like the Anthropics and their docs, you should generally keep it to around 200 lines or less.
Like, this is definitely too long. But I gotta say, we have tried to prune this in the past back when we were using, I don't know, like Opus 4.5, Opus 4.7 and we did get worse results and we took out different conventions that we have in here.
And so we have tried our best to prune it before, but now that we have Fable five and Opus five and you know, GPT 5.6 Soul, we have that next generation of models where I I know now that, like, we don't need rules that are this long. And so I did a test where I took the claw dot m d file and I actually turned it into this.
Like this is full ablation here, just giving it a couple of commands, a little bit of a context on what Arkon is, and that is it. And so I compared Arkon side by side working on a bunch of different GitHub issues. One using our really bloated current rules and another using the rules that we have here.
And then I also have a skill that just teaches generally how to use Arkon, like how to run commands and things like that. And so I also ablated this.
And so we have a really long scale. This one's like 350 lines long.
And I actually tried removing it entirely. So now the model to understand how to use ARCON has to base it on just understanding the code base itself. And so I thought, I really did think that Claude code was going to bomb on this version of the AI layer.
But going back to our diagram here, we can see that for a certain kind of development, actually half of the testing that I did, both of the layers performed equally. So this was crazy to me.
Basically, two layers that we have here is how much was the coding agent able to make the hard architectural calls in our code base. And the other category is how much is it able to follow the conventions that are very specific to our project.
And so the important thing here is, of course, our full AI layer, it held up for both. The quality was the baseline here with our full layer. Now when we had it stripped bare, whereas like the, you know, 20 line claw dot m d and no archon skill at all, for the hard architectural calls, it held up.
It was able to architect new features in our code base just as well as when we had the full claude.md. Where it really didn't perform well though is just complying with the conventions that we have in our code base.
Like this is how we like to register our tests. That's something it failed at. This is how we want to write our functions like the style and how we import things.
That's where it broke. And so what this really teaches us here is that as the large language model gets better and better and better, we don't have to guide it to work well as a software engineer. Like, lot of times, the rules that we used to have for the LLMs were more to fix the gaps that we had in them versus actually teaching them something for our own code base.
But when it comes to the rules for like here's how we like to work, those still matter. You can't fully ablate your AI layer because there's a lot in the AI layer that really just teaches your agent how to customize things for you. So you don't have to teach it how to do a good job in general, but you do have to teach it how to do a good job by your specific standards.
And so my final recommendation here is yes, you should go through the process of ablation. I just don't think you have to go through everything like Boris says. Start for sure with your rules because you're gonna have all the low hanging fruit there so you're not wasting all your time and tokens.
And you can identify the things where you're more just trying to teach general practices to the LLM to fill in gaps versus really teaching how to work on your code base specifically. Those are the things that you should remove and you'll probably never have to bring back. Now, of course, even things that are specific to you.
Sometimes your coding agent is able to identify those things as it's operating in the code base. So there's still more that you can test with the ablation process. I'm just trying to speak more to, you know, what's the low hanging fruit, what are the things that you should sometimes try to do, and then maybe the other things that you should do very rarely if at all.
So think about it this way, rules that fix reasoning have decayed because LLMs have gotten good enough at reasoning. But rules that direct attention and customize things, those are just as important. Alright.
So the last thing that I have for you here is a Claude skill that I've built to guide you through the same ablation process that I went through myself after I saw Boris' talk. Now I could dedicate an entire video to covering this skill and maybe I will in the near future. And so I'm not gonna go through everything here because it would take a while.
But basically, when you invoke this skill and you can do it for really any coding agent, it's going to first identify your AI layer. So figure out like here are your skills and hooks and rules and sub agents, and then it's going to identify tasks that it can create to run against your code base and test it both with the full AI layer and without.
So it's going to run those tests, uh, the exact same task side by side and then essentially just grade things at the end. So evaluate and give you a report of, you know, how much is your AI layer and each part of it really helping you in your day to day work. And I didn't, like, test this for hundreds and hundreds of hours or anything, obviously.
So I'm not sure, like, how well this will generalize to every single code base, but I just wanted to try to put together some resource for you so you can immediately apply what we've been covering in this video here. Because like I said, going through some form of ablation is definitely important to do once in a while. The question is more like how much of your AI layer do you ablate and how much time do you really dedicate to it.
And so I hope this skill will just help you get started with it. So feel free to install this. There's actually a new skills repo that I've just put out on GitHub.
And so I have installation instructions here for how you can bring in the entire plugin. And then this ablation skill is just one of them that we have here. So of course, I will have a link to this in the description.
And that's everything that I have for you. What Boris is saying, the right interpretation of it, and what I really think about the strategies here. Definitely worth paying attention to and doing to an extent.
And so if you appreciated this video and you're looking forward to more things on agentic engineering and skills, I would really appreciate a like and a subscribe. And with that, I will see you in the next video.
The Hook
The bait, then the rug-pull.
A tweet quoting Claude Code creator Boris Cherny went viral for saying you should delete your CLAUDE.md, skills, and hooks every six months and see what the model does without them. Read alone, it sounds like a verdict that everything you've built is now obsolete — but the full context, and a real benchmark, tell a more specific story.
Frameworks
Named ideas worth stealing.
08:36model
The AI Layer Spectrum
CLAUDE.md
.claude/rules/
hook-injected context
skills
.claude/references/
subagents
A left-to-right spectrum from 'always loaded, paid on every session' (CLAUDE.md) to 'on demand, free until it fires' (subagents). Prune pressure follows how often something loads into context, not how much you wrote — so global rules deserve aggressive cutting while skills and subagents can stay bloated with little cost. Hooks are called out as a special case: deterministic and zero attention cost, so they never sit on this axis at all.
Steal forauditing any AI coding harness before deciding what to prune
15:02model
Held Up vs. Broke — the ablation test result
Hard architectural calls: full layer held up / stripped bare held up
The repo's own house rules: full layer held up / stripped bare broke
Testing a 1,000-line CLAUDE.md against a stripped ~20-line version on identical coding-agent tasks: architectural decisions were equally good with almost no rules, but project-specific conventions (test registration, function style, imports) broke down once the rules were removed. Stated as: rules that fix reasoning have decayed, rules that direct attention have not — cut the left, leave the right, prune inside a skill rather than deleting the skill itself.
Steal fordeciding exactly what to delete when ablating your own AI layer
CTA Breakdown
How they asked for the click.
VERBAL ASK
19:38product
“I'll have a link to this in the description... if you appreciated this video and you're looking forward to more things on agentic engineering and skills, I would really appreciate a like and a subscribe.”
Soft dual pitch folded into the sign-off — points to his new public skills GitHub repo containing the ablation tool used in the video, then closes with a standard like/subscribe ask. No hard sell.
A software engineer who hasn't handwritten a line of code in over a year opens up the actual skill library and two-loop system that runs his AI-assisted development process end to end.
A 25-minute honest breakdown of loop engineering — what the AI coding elite actually mean by it, why it gets expensive fast, and how to build a harness that makes it reliable.
The same update that let Claude Code and Codex turn a screen recording into a skill quietly taught both of them to watch raw video, no plugin required.
00:22
00:37
00:52
01:07
01:37
01:52
02:07
02:22
02:52
03:07
03:22
03:37
04:22
04:37
04:52
05:07
05:22
05:37
05:52
06:20
06:52
07:04
07:22
07:37
07:52
08:11
08:22
08:52
09:07
09:22
09:37
09:49
10:07
10:37
10:52
11:07
11:22
11:37
11:52
12:07
12:22
12:37
13:07
13:22
13:37
13:52
14:07
14:22
14:37
14:52
15:22
15:37
15:52
16:07
16:22
16:37
16:52
17:07
17:22
17:37
17:52
18:22
18:37
18:52
19:07
19:22
19:52
23:00
24:39
21:55
14:49
16:42
13:12