WEBVTT

00:00:00.000 --> 00:01:12.025
Most people use ClaudeCode completely wrong, and honestly, it's not their fault. The defaults, it teach you to type into one chat, hit enter, wait, and then type again. And that's the loop that everyone learns first. The guy who actually built ClaudeCode, he does basically the opposite. His name is Boris Shearney. He runs about 15 Cloud Code sessions at the same time, and he barely types most of his own prompts, and he's been writing about exactly how he does this for months now. Now I've read every public post that he's ever made about how he uses Cloud Code, I put this entire thing on this one page so that we could walk through it together. So if you've never run an AI agent a day in your life, it does not matter. You can copy this today, but let's get into it. Now some quick context before we actually jump into it. Everything that Boris has said publicly, it is going to be sourced on this page, and everything that I am adapting for people who do not write code, it's going to be labeled separately. So I will have this available to download inside of my free school community. Link will be down below in the description, so make sure to join that if you want access. Now Boris, he has about five Cloud Code sessions open in his terminal at the same time. Now each one, it is its own separate git checkout, so the changes, they're never going to be clashing with each other. Now he numbers the tabs just one through five, just to keep them pretty straight in his head. On top of that, he's been running another five to 10 sessions inside the browser on cloud.ai.

00:01:12.025 --> 00:01:29.170
And before he's even at his desk in the morning, he's already kicking off new sessions from his phone and then just picking them up on his computer when he actually sits down. Beyond that, he even uses a couple of built in commands, teleport and ampersand to just hand a session back and forth between his terminal and his browser without actually losing the conversation,

00:01:29.330 --> 00:01:52.740
without losing the context. Now the big rule that makes this whole thing work is one session, one job. So he never asks the same session to do two different things. Each one, it's going to be getting its own single task, its own context, and nothing else. That one configuration detail actually worth knowing before you set yours up is that Boris, he runs Opus with the thinking mode turned on for every single session. So it's not sonnet or haiku.

00:01:52.740 --> 00:02:28.980
His reasoning is opus, and it's going to be slower per prompt, but it's actually faster from task to done because it needs less steering, fewer connections, and fewer reruns as well. And the moment that you are actually running multiple sessions in parallel, the steering cost on each one, it matters way more than just speed of any individual prompt. So here's how to set this up. Open five different terminal tabs. In each tab, navigate into your project folder, and then just type Claude, and you can hit enter from there. So that right there, that is going to be five Claude code sessions running side by side. Each one is actually ready to take a separate task.

00:02:29.140 --> 00:03:04.740
Now for the web ones, you can just simply open up Claude dot a I slash code in about five different browser tabs, and you could be running the same project in each one. Now the separate git checkout part that only is going to be mattering if you're shipping code, so I would just skip that if you're not. But personally, I run about two at a time. I have one for research, generally one for writing, and the number isn't really the point. The point is just going from one session to more than one. Now this next piece, it's the one that most people miss when they actually try and copy this, and honestly, it's the highest leverage thing on this entire page, and it is the claudet.md

00:03:04.740 --> 00:03:16.205
file. This is effectively just the file that learns. So here's how it works. You're effectively just going to be dropping a file called claud dot m d inside of the root of your project folder.

00:03:16.205 --> 00:03:21.340
So that is it. Claude code, it is then going to be reading that file automatically

00:03:21.500 --> 00:03:36.865
every single time you start a session in that folder. So you don't have to attach it, you don't have to paste it in, you don't have to remind Claude that it actually exists. It's just going to be loaded into context before Claude reads anything else. So what actually goes inside the files, it is just going to be simple rules.

00:03:37.105 --> 00:03:45.940
So projects context, or things to do, things to never be doing. Stuff like never delete files in the assets folder without asking for my permissions,

00:03:46.100 --> 00:04:12.255
or when you do draft an email, just always read the offer document first. Or maybe if the project lives in this folder, the brand voice is going to be living in that folder. So anything that you would otherwise have to re explain in every single chat, you want to write into this file once and you are done. Now what actually makes this compound is every time Claude does something wrong inside of a session, the fix just gets written into the file as a permanent rule. Now Boris'

00:04:12.255 --> 00:04:16.660
exact words is anytime we see Claude do something incorrectly,

00:04:16.740 --> 00:04:57.335
we are going to be just adding it to the Claude dot m d. And Claude is very, good at writing rules for itself, so you can literally ask the session update claud. Md so you don't have to make that mistake again, and it'll draft the rule for you. So you just read it, you save it, and you're done. That's it. Now an entire team, they could be sharing the same claud. Md just by checking it into git. So when one person is adding a rule, everyone is going to be getting it on their next session as well. Now the move that Boris does specifically that's going to be worth copying for you is when he's actually doing any code review on a coworker's poll request, he tags at Claude in the comment. And it's not to review the code, but to instead update the claude.md

00:04:57.335 --> 00:05:05.255
based on what the poll request just taught the team. So the lesson, it isn't just going to stay inside of his own brain. It's not gonna stay isolated.

00:05:05.255 --> 00:06:08.230
It doesn't stay in the PR thread or anything like that inside of GitHub. It just goes straight into the file every future session in that repo reads. Now it actually calls this whole loop the compound engineering loop, and the name it's actually very accurate because week one, you're clauds at m d, maybe it's five rules. And then month three, it's going to be 50 different rules, and each correlation, it compounds across every session that follows. So this is the part that literally nobody else can copy from you. Anyone can paste the same prompts into Claude. Nobody else is going to have your same Claude's at MD, however. Moving on to section number three, you might already be familiar with this. You might already be utilizing it, but it is one of the most important pieces to be enabling. So in any active Claude code session, when you hit shift and then tab, and then tab a second time, the prompt indicator at the bottom of the terminal, it just shows you that you are in plan mode. Now when you just type your task, Claude, it doesn't just do the work, it writes the plan first. So you read it, you fix whatever may be wrong, and then you tell it to proceed with that plan that it had constructed.

00:06:08.310 --> 00:06:24.395
Now Boris, he actually starts most of his sessions this way, where he iterates on the plan until it's actually solid, and then he switches to auto accept, and he just lets the model just one shot on the implementation. Now his phrases for it is, do you just pour your energy into the plan so Claude can one shot the implementation?

00:06:24.770 --> 00:07:21.175
Now I legitimately utilize this every single day before pretty much anything that is not a one liner. So maybe having two prompts instead of one. The first prompt is something like, don't do it yet. Just write me the plan step by step. Tell me what you'll touch and what the output will look like. That's where I come in, I review the plan, and then fix whatever's wrong, if there's anything wrong. And then the second prompt is just good, go ahead and do it. Now one more move actually worth copying is that if the work goes off the rails, maybe halfway through, you don't just try to patch it inside of the same session. You can just hit shift tab again to drop back into plan mode and replan from there. Section number four, this is the slash commands and the sub agent. So the dispatching that Boris does, thing the that I mentioned at the start of the video, is he runs through two kinds of tools named the slash commands and the sub agents. So here's how the slash commands actually work, where inside of your project folder, you just create a folder called dot claud slash commands.

00:07:21.530 --> 00:07:30.970
Now inside of that, this is where you're going to be dropping a markdown file. Now the file name, this is where it becomes the command name. The file called commit push p r dot markdown,

00:07:31.290 --> 00:07:49.670
it instead becomes slash commit dash push dash p r. Now the contents of the file, they're just the prompt itself, and that is the entire setup. Now in any session in that project, typing the entire command, it runs the prompts now. Now Boris' actual commands are slash commit push p r slash simplify

00:07:49.670 --> 00:08:17.310
slash verify and slash go. So he actually uses these dozens of times a day. They're checked into git, so the whole team is going to be sharing them. Now sub agents, these are the next layer up. It's the same idea, just a much bigger scope, where you define them in a folder called dot claud slash agents. And each one, it's its own markdown file with a role, its own permissions, and its own reference files. Now Boris' actual sub agents, they're just a code simplifier,

00:08:17.310 --> 00:08:19.550
a verify app, code architect,

00:08:19.550 --> 00:08:51.280
build validator, and an on call guide. So with this, he tags them the same way that he would be tagging a coworker. Now I have around five of these saved. Other ones I actually use the most is a slash command called a sponsor reply, and that's just going to be pulling my rate card from a file inside the folder and drafts the response in my voice and my tone, and it saves me roughly a couple hours every single week. And the whole thing, it's just one markdown file and a dot claud slash command. Moving on to number five, the slash loop. So slash loop, it just turns a one shot agent into a process that's going to be running in the background.

00:08:51.520 --> 00:08:57.520
So here's how to actually run one. In any active Claude code session, you can just type out slash loop

00:08:57.685 --> 00:09:07.605
and then the interval, which is about five m for five minutes, or one h for, obviously, one hour, and then the prompt or the slash command that you want to be repeating.

00:09:07.845 --> 00:09:20.920
From this, obviously, just hit enter, and it's gonna run on that schedule until you cancel it, or maybe three days pass, whichever comes first. Now the four loops that Boris is actually running right now is slash loop about every five minutes slash babysit.

00:09:20.920 --> 00:09:29.725
So that one, it is going to be addressing code review, rebases branches in Shepard's pull requests. So the slash loop, for example, every 30,

00:09:29.885 --> 00:09:31.965
slash slack feedback,

00:09:32.205 --> 00:09:33.165
slash loop,

00:09:33.325 --> 00:10:30.705
slash post merge sweeper, slash loop every hour, slash p r pruner. Now there's four agents going on in the background, taking care of stuff that he would otherwise be doing by hand. Now you do have one catch here that matters, and that's your machine it has to be staying on. So if you close the lid, if you shut it down a loop, it's going to be dying. Now the right move that you wanna be making for any overnight work, I'll cover in the next section. But me personally, I tried running three loops at once for about a week or so. I turned them all off, and I really found that about two, it is going to be the sweet spot. At least personally for me, anything more, and I really just stopped trusting any of them because I couldn't keep track of what was actually running, so it wasn't worth it. Now the two that I actually keep, they're just gonna be an inbox sweep every fifteen minutes during the workday, and a lead status check about every hour. So the shape, it's always going to be the same, where every x minutes, do y, notify me if z. Moving on to number six, the slash schedule and routines.

00:10:30.785 --> 00:10:34.945
So slash schedule, this is the same idea as slash loop.

00:10:35.025 --> 00:10:54.895
But with this, it's going to be running inside of the cloud instead of on your machine. So this actually launched as a feature called routines back in about April. So here's how to be setting one up. So we're going to go in our terminal, and you just type slash schedule. You know, with the schedule, could say something like every night at 11PM,

00:10:54.975 --> 00:11:09.190
or a Chrome style string you can input there, and then the prompt, or the slash command. Now you just have to configure the job once with this prompt, the repo, and your connectors, and then from there. It's going to be running on Anthropix infrastructure

00:11:09.350 --> 00:11:33.320
on the schedule that you actually set up. So if you do close your laptop, if you do shut down your computer, if you walk away, you go to bed, whatever it may be, this is going to keep running. The job will keep running for you. So this whole distinction, it comes down to just two different lines. So the slash loop, that is going to be local, and it's about up to three days. The machine has to stay on the slash schedule. This is cloud, it runs indefinitely,

00:11:33.480 --> 00:11:46.575
your laptop can be closed. And the way that Boris actually talks about picking between them is that the minute a job needs to survive the laptop closing or shutting down, it becomes a slash schedule. So this is relatively self explanatory.

00:11:46.655 --> 00:12:01.950
And the other thing that he specifically called out is the GitHub event trigger. So a routine that could actually kick off the moment that a PR opens or a deploy finishes without anyone needing to type anything. So the one that I am running right now, it is an AI news scan. So basically,

00:12:02.190 --> 00:12:10.385
a content system for me. So it effectively just pulls anything from the AI world, not just only overnight, but actually throughout the day, so twenty four seven.

00:12:10.705 --> 00:12:48.515
So any model releases, any big feature launches, or threads that are picking up traction, and it just drops a one page brief into my Slack channel before I am at my desk. So every morning, I'm checking just the most important releases, or if there's any new releases throughout the day, I'll get notified right then and there. So that just means I'm not having to refresh x, go on my YouTube all day, every day trying to catch what dropped, because by the time I open my laptop, I can just see on my phone in the morning, you know, the top things that I need to be knowing about. So I am in the know about all the important things. Now if you take one thing away from this video, you need to be taking this one, and it is the verification.

00:12:48.755 --> 00:13:14.185
So Boris' exact words, you you wanna give Claude a way to actually verify its work. Now this has always been a way to two or three x what you actually can get out of Claude, in Claude code specifically. So he calls it his number one tip, and he's been saying it since January. So here's how he actually runs it. There's about three challenge prompts that he adds at the end of his own tasks. So grill me on these changes, prove to me this works, scrap this, and implement the elegant solution.

00:13:14.425 --> 00:13:42.805
Each one, it's going to be forcing the session to just switch from doing the work to checking the work. So I added a version of this to every important prompt that I run all in one afternoon, and the quality jump, it is literally immediate. So if you do one single thing from this video, follow this one. So the line that you actually bolt on, it's going to be changing, of course, depending on the task that you are going to be doing. So for a draft email, for example, it's maybe just reread this against my offer doc and flag anything inaccurate,

00:13:42.885 --> 00:13:47.925
or maybe if it's for a research report, it's gonna be just list every claim that has no source,

00:13:48.245 --> 00:13:49.525
and hypothetically,

00:13:49.525 --> 00:13:55.570
for a numbers report, cross check against the raw data, and then flag anything off by more than 5%.

00:13:55.570 --> 00:14:00.210
Now what you can actually do with this is you can add this as a skill. So you can do slash

00:14:00.530 --> 00:14:07.905
prove or a slash approve, where you're just telling Claude, add this as a skill. You're just taking exactly everything from this HTML,

00:14:08.065 --> 00:14:17.105
and putting it, saying, I want you to run this, and run it whenever I ask for this, or here's some context you need to know about. So again, if you guys want access to this entire HTML,

00:14:17.105 --> 00:14:23.710
you can get inside of my free Skool community. Now moving on, I'm gonna be completely honest that a lot of this stuff that I just covered, it's probably not gonna be necessarily

00:14:23.710 --> 00:14:49.990
relevant or applicable or consequently helpful to you, because Boris, he's just a developer working in a developer's environment. So the split that I would be going with this is the most important things to be copying, maybe two or three sessions running in parallel. You don't need 15. You can just have a rules document that you reference in every single prompt. Make sure that you are planning first in having this discipline pretty much every time you're starting something that's going to be relatively complex.

00:14:50.310 --> 00:14:56.470
And then using named prompts for anything that you are going to be doing twice, running one loop during your workday,

00:14:56.875 --> 00:16:24.020
one schedule running overnight, and a verification line on every important task that you have. That is the entire adoptable system that I would be employing. Now the things that you might be able to skip is, again, not needing 15 parallel sessions. That's just gonna be unnecessary. It's gonna be expensive for you. Having git work trees, this only really helps if you ship code. So I personally tried work trees for only just a few days, because the original post made them sound very essential, and then I realized I had zero use for them, and I just completely dropped it. And it's the same thing with, you might not even be familiar with it, but BigQuery and Sentry. So those are just dev stack tools. And then the slash go skill, it assumes a code base. And anything that ends in a pull request, you really are not gonna be needing. So if anything didn't make sense, just obviously, don't you need to focus on it too much. Now that's it for today's videos and everything I wanted to cover from Boris. Hopefully, you can see now how the guy who built Cloud Code actually utilizes Cloud Code, and how to start running yours the same way, if not very similar. So if you're not subscribed, make sure to hit subscribe. Make sure to get all the free resources inside of my free school community down below in the description. And if you're looking for something more hands on, more courses, more support, then make sure to check out our paid community. Link is also down below in the description. So with that being said, thank you guys for watching. Let me know what you guys think of if you guys are using any specific tips and tricks in your stack or anything that I didn't cover in this video, drop it down in the comments. Eager to see what you guys are using. But with that being said, thank you for watching. Hopefully, you found some value within this video, and I'll see you in the next