Transcription
Boris Churnney, the creator of Clawude Code, says that his setup is pretty vanilla. So, I started researching Boris and how he worked. I dug up interviews, threads, everything he shared publicly about how he actually uses Clawude Code. Despite him having an engineering background, all the principles he uses, anyone can apply. So, in this video, I'm going to show you exactly how he starts every project and show you how I've personally been applying these workflows.
Let's get into the first section, which is all about plan mode. So, here's one of the biggest features that you're probably missing. And here's a clip of him talking about how he uses it and how he babysits Claude code.
"Probably 80% of my sessions I start in plan mode. And once the plan is good, it just stays on track and it'll just do the thing exactly right almost every time. And so, you know, before you had to babysit after the plan and before the plan, now it's just before the plan."
So, 80% of his sessions start in plan mode. And he clearly outlines the importance of babysitting before Claude Code starts building. And he mentioned that once a good plan is locked in, building is almost automatic. So, why does this matter so much? Well, most people, they open clawed code, they type what they want, and then they let it run. And there's really not a lot of planning that's involved. And yes, AI is great at solving problems, but the problem it thinks it should be solving and the problem that you actually want it to solve aren't necessarily the same thing. If your request is vague, you get the wrong solution, and then you spend hours debugging something that you could have avoided from the start. And generally speaking, AI is set up to solve problems as quickly as possible, not necessarily correctly. So, you may think a problem is solved, but it didn't actually solve what you wanted it to solve. And I've seen this firsthand. So, one of the clients I was working with, they had a bug on their website and the numbers weren't correctly displaying. And instead of fixing the display, Claude actually went into the database where it was getting the information, changed the value, and then marked it as resolved. It fixed one thing, but then that broke like five other things in the app because it changed the value. So, it didn't actually solve the problem the way we wanted to solve it.
And so Boris's approach is different, right? He's not trying to just attack it right away. He's planning. This is a quote that I love to reference from the Navy Seals and it's "move slow to move fast." He has all the thinking that happens up front and then the execution is essentially automatic. So before you build anything, hit shift tab twice in your terminal and that will enter plan mode in clawed code. So go back and forth until it's something you really like. Perhaps ask it to interview you to see if there's any gaps in your assumptions and then you can have it start building. Here's a specific prompt you can use before we start building: "Interview me about this. What is the core problems this solves? Who is this for? What does success look like? And what should this not do? Summarize it back to me before you write any code." Now Claude will proactively ask you questions about things that I previously probably would have made assumptions about. So this was all about putting Claude in the best position to succeed.
Now the next part is probably what surprised me the most about his entire strategy. Section two, Claude MD. So, when you've used Claude code, you might have seen a file called claude.md. It's essentially a set of instructions that Claude reads every time you start a new chat. Think of it like giving Claude a cheat sheet about how you want to work, and it's specific to you. And Boris uses this how a lot of people use it. Whenever there is a mistake, he'll update the claw.md file to make sure it doesn't happen again. A simple prompt that you could use here is "based on this conversation, can you update claw.md so this doesn't happen again?" And this is extremely powerful, but there are limitations. And a lot of people, they think the more instructions that I give, I'll get better results. So, they just create this massive claw.md file with like every rule they can think of, and they never try and clean that up. But Boris does the opposite. Here's a clip of him talking about how he handles it when this file is getting extremely long.
"So, our quadm is actually pretty short. I think it's like couple thousand tokens, maybe, something like that. Um, if if you hit this, my recommendation would be delete your quad and just start fresh."
"Interesting."
"Mhm. I think a lot of people like they try to overengineer this, right? And and really like the capability changes with every model. And so the thing that you want is do the minimal possible thing in order to get the model on track. And so if you delete your quad MD and then you know the model is getting off track, it does the wrong thing. That's when you kind of add back a little bit at a time. And what you're probably going to find is with every model you have to add less and less."
His advice is counterintuitive, at least to me. But what he's saying is that if claw.md is bloated, just delete the entire thing and start fresh. And his point is that because these models are getting better every day, what you needed six months ago is likely built into the model right now. And generally, if you give it a ton of instructions, the more you give it, the more likely Claude is going to get confused and not apply the rules that are actually critical. So, he'll just delete the whole thing, which for me is a little bit scary. And that might be him just believing in Claude code a little bit too much. Honestly, I'm not sure about that. But Boris's approach where he says "do the minimal possible thing to get the model on track" is absolutely spoton. And what he does is if he sees the same issue again, he'll just add it to the claw MD. To be totally honest, this isn't something that I do. I feel like I'm a little scared. But what I do do is instead of deleting it, I run a simple command. I say "update my claw.md to remove anything that's no longer needed, contradictory, duplicate information, or unnecessary bloat impacting effectiveness." I found that this is an effective middle ground, but feel free to take Boris's advice and just periodically yolo and delete the entire thing. And if you're not using the claw.md file and updating it over time, make sure to do that.
So now, these first two strategies that we've covered are all about getting better results. But how do you actually make sure it did what you were hoping it was going to do? Section three, the next key thing he does is about verification. Here's a post from Boris on Twitter that really stuck with me. "Give Claude a way to verify its work. If Claude has that feedback loop, it will two to 3x the quality of the final result." In theory, this sounds awesome, right? You can just have Claude check what it did and see if it did it correctly. But how do you do this in practice? You can see his tweet on the screen, but he gives two steps. One, give Claude a tool to see the output of its work. And two, tell Claude about that tool. That's really it. And then he says, "Claude will figure out the rest." Again, Claude is pretty damn powerful. So for me and you, what does this look like in practice? If you're building something with a website, Boris uses claude code, opens a browser, tests what it built, and iterates until it actually works. And here are some other strategies. If you're writing code, what's a bit more interesting for me are things that aren't necessarily right or wrong, like the more creative components. So, if you're using Claude for content or writing, you could say, "Review this against my brand guidelines and flag anything that doesn't match." Or if you're building automations, you could say, "Run this workflow and verify the output matches what we expected." Above all that, the simplest approach that just kind of catches everything is you can add to your claw.md before you do any work, mention how you could verify that work. Now, Claude will tell you what its verification plan is before it actually starts building. And if there's no clear way to verify it, maybe there's a better way to go about it. And a pro tip here, after going back and forth with Claw Code a bunch, here's something you could run. Say, "Please go back and verify all of your work so far. Make sure you use best practices, were efficient, and didn't introduce any issues."
So you're planning, you're keeping instructions minimal, and you're verifying. But what if you could do more at once? And this is probably the biggest force multiplier to increase your efficiency with these tools. So this is about multiplying yourself. And Boris has a tweet where he talks about the importance of working in parallel. There's a lot of technical jargon here like Git Work trees. And if you want to look that up on your own time, go ahead. But it probably doesn't matter because that's for more robust engineering teams. Instead of that, what's important for you is his concept of partitioning different workflows. he'll have multiple clawed sessions running at the same time, each one focused on a different task. And the key here is that each task is partitioned so they're not overlapping. A simple way to think about this is if you had two people working on the exact same thing at the exact same time, you'd have wasted effort and they'd likely clash with whatever files you're working on. This is the same thing with Claude. If you have multiple sessions working on the same thing, it's counterproductive. Boris would approach it with this in mind. He says, "Two context windows that don't know about each other tend to get better results." So, a fresh session could look at a problem with no baggage, and it might see something obvious that your first session missed because it was too deep in the weeds and it had context that was fogging its problem solving. Creating a new window and just starting from scratch is the equivalent of like you turn it off and you come back and it just works.
Now, his fifth strategy is about creating an inner loop. Boris calls repeated tasks his inner loop. And these are things that he does many times throughout the day. You may not realize it, but if you think about it, you're going to find a lot of these inner loops. Quote from him, "I use slash commands for every inner loop workflow that I end up doing many times a day. This saves me from repeated prompting." Slash commands allow him to do is just to quickly call things that he repeatedly does. And he's taken a more systematic approach. Now, Boris uses something called slash commands to handle these more repeatable things that he does throughout the day or his inner loops. But there's something called clawed skills that's way more applicable to what you're doing. Clawed skills are essentially a way to document a process so that you can call it directly in clawed code to complete that every single time. In a sports analogy, let's say a prompt is you telling a player to like dribble the basketball. But a clawed skill is the exact play to run. So that could be a pick and roll and AI knows exactly how to run that play every single time. For clawed skills, think about the inner loops that you have throughout the day. For me, some of these skills that I use for my clients, like one example is I work with an engineering firm and there's something called a local law 97 report, whatever, boring. But I'm able to use a skill/l7 that generates the same report in the same format in the same style every single time I run it. And the only thing that changes is the data that I reference. This is an inner loop that my team has to do throughout the day. But once we've created a skill for it, it's infinitely repeatable. These are so so powerful and I cannot stress how important these are. I have a full video on my YouTube where I break down exactly how I use Claude skills and how you can use them. I'll reference it at the end of this video, but Boris uses this in his own way. And this is something that you just can't ignore. If you don't know where to start, just use this prompt: "Based on the project I'm working on, what Claude skills should I create?" It'll give you the juice. You can just go from there.
Now, there's one more mindset shift that ties all of these different concepts together that Boris explains extremely well. The last section is build for the future. This is something that a lot of people ignore. Here's an excerpt directly from Boris.
"We have a framed copy of the bitter lesson on the wall. Um, and this is this like rich sutton uh like everyone should read it if you haven't. Uh, and the idea is the more general model will always be the more specific model. And there's a lot of corlaries to this, but essentially what it boils down to is never bet against the model."
Restating this, every piece of scaffolding or micro tweaks to improve the model's output that you do will probably be unnecessary in the next 6 months. And the reason is that the model is just getting better. Now, that's not a reason to not build things. But it's important to understand that AI models get better every single day. So, it's about thinking where should you focus your energy? And if you've watched some of my other videos, you know how stupid I think it is writing optimized prompts. Respectfully to everyone out there who's saying to optimize prompts because ultimately the model is just getting better and you don't really need an optimized prompt. You need to just give it the right direction. Instead, you should be spending your time on your information mode and that's everything that you're feeding the model and the system that you're using to get AI better over time. This is the context that is put on top of the model to get you those fire outputs. So remember this when you're tweaking with prompts like "is this worth the 10% improvement right now or should you just spend your time assuming the model will be better next month and working on other things because AI will never be as bad as it is today which is frankly very scary."
So with all that in mind let's recap Boris's system. His first thing he does is he uses plan mode. Move slow to move fast. Have the conversation before Claude starts building. Two is create a minimal claude.md file. Less is more and if you have to start fresh. Three is verification. Give Claude a way to check its own work. Four, multiply yourself. Parallel sessions, fresh context for hard problems. Five, systemize your inner loops. Document once, run forever. Use Claude skills. Six, build for the future. Expect that the models are going to get better, not worse. Plan accordingly.
Now, if you like this video, make sure to check out this video where I do a deep dive on Claude skills and how you can transform your workflow and set up your own operating system. Combining the content I cover over there with the pro tips from Boris, you will become a Claude code savage. I'll see you in the next one.