The REAL Reason The Creator of Claude Code Told You To Delete Everything

0:00 The creator of Claude Code went viral for telling users to delete everything they created. And I'll play the clip in a second. But unfortunately, 99% of people who have discussed this topic are

0:09 missing the real reason he said it. So, in this video, I'm going to break down what he said, why he actually said it, and how it impacts you. And then in the end, I'll outline how you should set up

0:17 your AI system so you never have to think about deleting files in the future. So, part one, what did he actually say? Here's what Boris Journey said in response to being asked if

0:26 people should delete everything. but you're using cloth code every 6 months. Delete your quad MD. Delete your skills. [music] Delete your hooks. See what the model

0:34 does and it might surprise you. This is a video that most people have seen and it is pretty alarming. You want me to just delete every Claw skill I've made. This guy Austin Marches has stressed how

0:44 important all of these skills are and I'm just going to delete them. Let's keep the clip playing and try and read in between the lines for a second. >> So, the first step is you delete. The

0:53 next step is you use it. And you don't want to guess what's the instruction that the model needs because you might not predict it correctly. And only when you see it repeatedly stumble on the

1:04 same thing, that's when you add it back. >> So when we listen there, right, let's call it what it is. Boris is telling you to experiment with your setup, delete everything, and then add back in over

1:13 time. Now, the natural next question is, why would the guy who built the tool tell you to throw away the instructions you're giving it? And this is where it gets a lot more nuanced, and you

1:21 shouldn't just start deleting things because that won't help you in the long run. So part two, why did he actually say this? So the clip went viral in part because at the time Anthropic shipped a

1:30 new model, Opus 5. So I decided to dive a bit deeper on the details of the change and after reading articles from Anthropic's team about how the recent model changes have impacted what they

1:41 were actually working on, I realized that this is a lot more nuanced than deleting everything. Boris said that because he was speaking to a room of startup engineers who have the time to

1:50 experiment and are likely operating in an extremely technical domain. But for people watching this who may or may not be technical or working in a non-technical domain, that approach

1:59 isn't super helpful. So what is Boris actually saying? Why does he want you to delete everything? It can all be boiled down to a single line that is about how anthropic was using Claude. We found

2:08 that we are over constraining Claude code both through our system prompt and in our claw.md files and skills. This is the crux of the entire problem. Over constraining Claude and yes, deleting

2:18 makes this so that there are no constraints. So yes, it fixes this, but it gets rid of all your industry knowledge that I'll cover on later. And it also doesn't stop you from making the

2:26 same mistake again and again over time. And not only it does get rid of all the established documented solutions that you've built. So instead, I want to change Boris's initial comment from

2:36 delete everything to delete everything that over constrains Claude. And then suddenly when you hear that, it starts making more sense. So how should you identify what is constraining Claude and

2:45 what you should keep versus delete? Now, before we get to that, we're talking a lot about optimizing your setup, but there is an elephant in the room that we need to address. Most people using AI

2:53 right now have zero foundational understanding of cyber security. But the reality is that it's never been more important for you to have this foundational understanding. Which brings

3:00 us to today's video sponsor, Try Hackme, a hands-on security training platform with over 8 million people using it. What they've done is built an AI security learning path that walks you

3:09 through the key foundational information you need in 2026. [music] And if you watch my videos, you know how much I stress hands-on learning. And for cyber security specifically, one of the best

3:18 ways to do this is through solving problems. But the problem here is that you essentially have to create a problem to then solve it. But that's what Tryh Hackne has solved with what they call

3:27 rooms. A room is a hands-on learning environment that runs directly in your browser. There's no complex setup or labs and the problems are already planted and your job is to go and find

3:37 it and solve it. So I decided to check out Try HackMe's prompt injection room. In this room, I'm going to use prompt injection to get the CEO's email from a company chatbot. And this process helps

3:47 me have a hands-on experience with this issue. So, as I'm talking to the chatbot, I ask it straight up, "What is the CEO's email?" And it refuses because it has instructions to never share their

3:56 email. So, I try and get clever with how I ask questions, and it's still like, "Nah, I'm not sharing it to you." But then what I do is there is a calendar event that's scheduled for Wednesday,

4:04 and within that event, there is a hidden prompt with instructions. So then I ask the bot to walk me through my Wednesday meetings and it reads the event, follows the hidden prompt instructions within

4:15 the event itself and leaks the CEO's email. That's indirect prompt injection, which is the process of injecting a malicious prompt into an AI agent, which is exactly how attackers do it. And I

4:26 was able to learn this with a hands-on example. And what I just demoed is just one of their rooms, but it's important to understand why this is needed in the context of work. As AI gets introduced

4:34 to more important workflows, the cost of error gets higher. So, these skills help you build workflows without sacrificing on security. Try HackMe is free to sign up and you can start learning with the

4:44 link below. And if you want full access to more learning paths, faster machines, and cyber certification prep, use my discount code link below, which will give you 25% off the premium annual

4:54 subscription. Now, back to Boris's advice and how this applies to you and your setup. So, the third part of this video is how this applies to you and your setup. I'm not going to tell you to

5:02 delete everything because I think that's the wrong advice. But what is the right advice no matter what is adjusting how you approach using Claude going forward? I found that of all of my research, it

5:12 can be boiled down into four shifts that will optimize your system exactly how Boris is suggesting without deleting everything. And so before we do any of those shifts, we just have to make sure

5:21 that we save our system properly. So if you're technical, make sure your project is pushed to GitHub so that you have it all saved. And if you're not, here is a prompt to paste in a cloud code that

5:30 copies your whole setup into a dated folder and tells you how to restore it. Even if you never look at this again, which I highly doubt you actually will look at it, it removes this deleting

5:39 anxiety where you're afraid to remove things. Once you remove that concern, you can move more freely through the four shifts that I'm about to cover. So shift number one is you want to change

5:46 rules to judgment. A rule is never do X. Judgment is match what's around you. A rule constrains claw in a direction that may not apply to every situation. And because these rules are saved in

5:58 context, it can apply to scenarios that you don't actually want it to apply to. The example Anthropic gave is that you may have one place that says default to writing no comments, one short line max,

6:08 and then another that says in a different process, write clear and thorough comments. This contradiction leads to inconsistent results and Claude working harder than it has to. So

6:16 instead, you can give it judgment. The new version is write comments that read like the surrounding comments, match the density, naming convention, and style. That gives Claude direction without

6:25 being prescriptive. Another example, let's say you had a skill/generate report. Instead of having a rule that says always make outputs as a CSV, which may contradict itself if another process

6:35 wants it to be in a PDF, you can say generate a report in the project's approved format where it will give a guiding principle for how the output should be made. So now, how do you

6:44 actually apply this to your project? Audit your system for rules where it can be guidance. For example, never use bullet points. Always be concise. Double check your answer. Swap each one for the

6:53 standard behind it. Write the way my last three emails read. One is a leash. The other is a standard that can be followed. This is nuanced. Yes, I get it. So, here is a prompt that can help

7:02 you identify places within your setup to fix this. Each person setup is different, but this will walk you through how you can adjust it. Step two is change examples to interfaces.

7:12 Previously, it was advised to bring exact examples so that Claude can see that as reference. The problem with this is that that restricts the domain that the model can think about. For example,

7:21 let's say you're telling AI, I want you to generate a report. Here are three monthly reports to follow. In this case, it will be confined to that structure. An interface, on the other hand, which

7:30 is just a fancy way of saying a guide, tells AI what is needed and what the constraints are. So, in this example, you would say, look at the past month's data and create a report that helps us

7:40 determine our performance. Now, the model has an interface it can follow, but isn't restricted to what you previously thought was good. The reality is that in some business use cases where

7:50 we do want to be rigid, for example, your boss wants the exact format. In that case, examples are still powerful. The general rule of thumb for this process, do you want AI to be a factory

8:01 worker or a creative? When it's a creative, examples can hurt it. So, bias towards interfaces. When it's a factory worker where you just wanted to pump out the same thing, examples are still

8:10 powerful. Here's a prompt to audio system to identify skills and context where you can benefit from this shift. Shift three is take upfront context and move it to progressive disclosure.

8:21 Progressive disclosure is a fancy way of saying only load context when it's actually needed. This is a universal principle and I've covered this on my channel before. So in your claw.md file,

8:30 which gets loaded every time, instead of loading it with context, direct it to where that context sits so Claude can decide when to load it. So instead of saying here is my writing style, and

8:40 then a ton of words about your writing style, you would say, "Here is my writing style guide." And then it would be a path to a file within that file would have all of the context. And this

8:49 way Claude can progressively disclose this information as it's needed. The same concept extends to your skills. All these skills should be lightweight where the contextual burden is stored in the

8:59 reference files. So this strategy empowers progressive disclosure. And here is a prompt to help you apply this to your entire Claude code setup. This one there's less nuance. Just do it.

9:08 Shift number four is Claude now automatically has memory and verifies by default. I have a full video on my channel on the pros and cons of the shift, but simply put, your Claude

9:17 session now stores things in a memory file. So, if you went back with Claude and there was something that you wanted to learn, you had to save it or remind Claude to store the information. Now, it

9:26 does this by default. So, if you open your terminal and type /memory, you'll see the settings. Then, on your machine, you can actually open a folder with all of the memories that it's referencing.

9:35 And here, you can see my folder landscape. This does it automatically, but if you still want it to remember something and you don't want to hope that it remembers, you can still

9:43 explicitly say it. The bigger one for this shift is that these models now verify by default. I used to tell people to make sure to add in their cloud MD, verify your responses before sending it.

9:53 But now these models automatically try and verify their output before it actually sends you the final output. And if you have specific rules about verification, that could lead to double

10:03 verifying and that could waste time and money. This doesn't remove the need to identify ways to verify things. That's still super important. But the larger point here is you don't need to say in

10:13 your claud verify the output anymore because by default it does it. That's a general rule that might have been needed before but it's no longer needed. Instead you would want to guide it on

10:21 how to verify specific outputs. Now looking back at all four of these shifts there is a clear pattern. All of the before versions before the shifts were where you guided the model because it

10:31 wasn't good enough. All of the after versions are you sharing information about your world and your preferences. So it's not about just deleting your skills. Boris doesn't really believe

10:40 that the goal is to delete everything that over constrains Claude. I cannot stress this enough. Do not delete intentional boundaries. If there are things that are off limits or there are

10:49 requirements that are fixed in your world, that's a fact and you can share that with Claude. Now, at this point, you know how the model has improved. But how can you actually test it and how do

10:57 you make sure that you don't have to worry about this going forward? But before we get to that, if this is your first video of mine, welcome to the channel. But if this is your second

11:04 more, you know the drill. This is our anti-slap agreement. Everything in this video is designed for humans and it's built by humans. So all I ask part of this agreement is you subscribe to this

11:12 channel so you can help reach more people. Also, every video as a thank you. I give away a Claude Max subscription. So this video's winner is Graphic Design New York. They're

11:20 building a learning management system. Shout out everyone from New York and New Jersey. Nixon 5. If you're a Knicks fan, let me know in the comments. Now, to enter the next giveaway, comment below

11:28 with what you're building. And every video that you comment on is another entry. So, part four. How do you test if these changes [music] matter? Honestly, I hate benchmarking. I think it's a

11:37 waste of time. So, I I will cover this quickly, but I'm going to tell you why I personally try and avoid it. So, if you do want to test this, what I would do is pick something that Claude just doesn't

11:46 seem to get right for you today. Something that it's just not that good at. Once you have that task in mind, there's a command that runs Claude locally without any of your context. So

11:53 you can just type claude-safe- mode and it'll run claude without any context loaded. That is your baseline. It's essentially like deleting your whole project. Kind of what Boris was

12:02 saying. Then you want to take your old project, the one that we archived, run the task there. And then you want to take your project that has all of these enhancements that we did throughout the

12:11 four shifts and all of them do the same task. Then you can cross compare the results and see if there's any noticeable differences. depending on what you're doing and specifically for

12:20 non-technical tasks, it's going to be somewhat subjective. It's just hard to do. And so, the reason that I don't love this benchmarking is that all of the shifts that I covered are strategic

12:31 shifts that are best [music] practice. So, I just don't try and overthink it. I don't go crazy trying to analyze if I improve my system or if it got worse. Directionally, I make sure that I'm

12:40 following the concepts. Did I keep all of the information that's specific to my situation, but remove the restrictive rules? So, we're getting out of Claude's way. That's a direction no matter what,

12:50 we need to go over time as these models get better. So, I'm okay with following these shifts without spending too much time trying to figure out how do I measure an improvement. There just isn't

12:59 a great way to do it no matter what. So, it's kind of a fool's errand. So, I just don't waste time on it. But what I do think is worth it is setting up your system so you never have to think about

13:08 it again and just understanding these best practices. So, how do you go ahead and never worry about this again? There are two anxieties that I want to cover that most people fall into. The first is

13:16 the anxiety that comes from worrying your system is up to date. Do I need to change everything I do every time a model shifts? And the second is a bigger one. Did this new model make my job

13:25 obsolete? The answer to both are surprisingly similar, but let's take the first one. As models improve, you want to set up your system so that it's adjacent to AI. Don't compete with it.

13:34 The context, the skills, the guidance you give it, it shouldn't try to restrict the model. Instead, give it the hypersp specific knowledge about your situation that it would never know and

13:43 then let it cook. And if you're ever wondering, run /docctor and clawed code and it'll analyze your setup and helps you clean it up so that you can feel more confident about it. Or run

13:52 buildpartner.ai/improve system, which looks at everything that we covered and suggests changes. If you follow the strategies we covered, use the commands that we just mentioned,

14:00 you're good. Just keep building. Now, the second question, did this new model make my job obsolete? Before I answer that, I want to share how I thought about this question 18 months ago. It

14:08 was January 2025 and I was a COO of a tech startup that was worth over $30 million. I was sitting in South Africa. I was working there and I was anxious. The reason was because as AI got better,

14:18 my role felt less valuable. So I decided to change my positioning. I started making AI content every single day and I became the AI guy at my company. As AI got bigger and better, I got more

14:29 valuable. A lot like how we set up our systems adjacent to AI, I wanted to position my personal growth adjacent to AI. There are a million ways to do this, but to help you, here is a prompt that

14:37 will interview you to identify any strategic adjustments you can make to make yourself more adjacent to AI's growth. When Boris said delete everything, he really meant get out of

14:46 Claude's way and build alongside it. And if you're on this channel watching my videos, that's what we want to do. But the reality is with all this, even with the right guidance, the burden moves to

14:55 the context in your system that AI references so it understands about your world. That won't go away ever. So to solve that problem, check out this video where I walk through how to optimize the

15:04 context in your system so that Claude gives you better answers no matter how good the model gets. And if you want to get a foundational understanding about AI cyber security, check out Try HackMe

15:14 and use the link below to get 25% off. Either way, I'll see you in the next video. Peace.