This is Boris. And when people get stuck with Claude code, they ask him how to use it. But why would they ask him? It's because Boris works at Anthropic and he's the one who actually created Claude Code. Even if he says that his setup is pretty simple, it's not. That's just his perspective. What's simple to him might be a whole system to everyone else. Now we've got a lot to talk about as I was honestly surprised at some of the points. And while some things were

technically older, he still gave me a fresh perspective on those features as well. In one of [snorts] his tips, Boris corrects one of the biggest misconceptions people have when trying to build something with clawed code. They basically give it a task and then when there are minor errors or it's not able to complete it 100%, they get disappointed. But humans work in a very similar way. That's why he tells us that we should always give Claude a way to verify its work. For example, if you're

going to write any Python code for building a project, you should tell it to use tests as well. This is because Claude gets that feedback loop and this instantly increases the quality of the final result. And if you don't even want to get into the code, you can actually ask it which tests you should use and it's going to give you a test for every single thing that it implements. Even if you want it to work autonomously, which Boris also has a lot of tips on, you can

just edit the claude.md file which gets sent into every claude code session. In there, you can tell it that before it does any work, it should mention how it would verify that work. So, it gets that constant feedback loop. Another important point that Boris identifies is that verification is different for each domain. Again, it might be as simple as running a bash command or for UI based verification. You have a lot of different ways to do that as well. One of which is Claude's own browser

extension. We made a pretty extensive video on that, too, and we'll link it down below. Basically, Claude navigates the whole site and can verify everything. This works as verification for pretty much anything. For example someone asked how they could verify a mobile app that was being built. There are actually a lot of iOS and Android simulator MCPs that you can use as well. But if you think these MCPs are too token hungry, then you can use not just verification but verificationled

techniques., For example,, you, can, use test-driven development where tests for a new feature are written first and then you do the actual implementation. You can also use screenshots in that process to verify the UI as well. Speaking [snorts] of the claude.md, Boris also emphasizes how important this file is and how unique it should be to each Claude code repo. Think of it this way. It should contain all the basic information that a newly created claude session should have about your project.

This includes the text stack, the basic project structure, some code style and conventions that your team follows, and most importantly, the things that it shouldn't do. This is because if you encounter errors in any of your sessions, you probably don't want Claude to repeat them. So, he has made it a habit to ask his whole team to contribute to the claude.md multiple times a week. Anytime they see it doing something incorrectly, they add it there as well. Each member of the team also

has a specific responsibility for maintaining a specific file. Another great structure for full stack apps is that each microser you're running can have its own claude.md. The front end can have its own and the back end can have its own as well. Another important thing is not to bloat the claw.md. He confirms this by saying that his own claude.md is about 2.5k tokens and he even highlighted exactly what they cover in it. You [snorts] might already know about the different modes you can use

claude code with with plan mode being specifically for planning. We'll come back to this later as it's an important point. Then there's auto accept mode which basically auto accepts all file edits. But there's another option as well which is the dangerously skip permissions mode where Claude essentially has permission to run everything. Boris says he doesn't use this and he's right, especially in production environments where a single terminal command can mess up the entire

project. Instead, he uses the permissions in Claude code to set up which commands are allowed, which commands it should ask before running and which commands are completely denied. You can pretty much add any rule you want and set it at the project level and Claude is going to follow that. To share this with his team, the Claude folder also contains a settings.json file where all of these commands are written down and he can then share that file with the rest of the team. In

[snorts] a way, Claude code has been one of the most badly named products from Anthropic because it's not only used for code. You might have even seen people generating full-blown enaden workflows with it or even setting up entire SEO pipelines or different agents for analyzing business markets and other things. The point is that it's a full system for people to control a lot of different workflows. The example that Boris gives is that Claude pretty much uses all of his other tools for him as

well. For instance, he uses Slack with Claude code using the MCP server along with a bunch of other tools like BigQuery and Sentry all through their CLIs inside Claude Code. Again, this just shows that you can use cloud code as a form of orchestrator. For me specifically, one of the biggest ways I use it in this orchestration is inside notion where Claude connects to Notion via MCP. It's able to create databases populate them, and understand the context of all our video ideas. Of

course, you're going to see them blurred because these are upcoming video ideas but I hope you get the point. Now, if you're wondering how Boris actually uses Claude code before starting to implement any feature or task, he first switches over to plan mode and clearly describes what he wants. Once Claude has a plan he continues from there. He argues that having a good plan is extremely important and that all the back and forth he needs to do with the agent

happens during plan mode. He only starts the agent once he's verified that the plan is actually valid. After that, he kicks it off in autoaccept edits mode not the dangerously skip permissions mode. As for how he uses it at scale, he also mentions that he runs five of these clawed code sessions in parallel. While working with them, he basically numbers his tabs. He does this so that when he receives notifications from different tabs, he knows which terminal tab

they're coming from. On top of that, he also heavily uses the web sessions of Claude Code. This is where you connect the web version of Claude Code to your GitHub, give it access to a demo repo and it's able to work on that in the cloud. The way Boris works with this is that he uses the background agents feature to put any longunning task into the background. Sometimes he even uses it on his phone where Claude can automatically do all the work in a cloud session and when it's done it creates a

new branch and pushes all the code changes there for you to review. There is also the teleport command which brings the cloud sessions back into the local terminal and allows you to view and work on it yourself. And this is truly the definition of working with any AI agent where he's basically treating it as a junior developer. Another interesting point he mentioned is that he pretty much uses Opus 4.5 with thinking enabled for everything. He argues that even though it's a bigger

and slower model and takes more time than Sonnet and significantly more time than the Haiku models, it has a much lower chance of making errors. As a result, the overall time spent working with the model and steering it is actually much lower with Opus 4.5. He also [snorts] uses the Claude code GitHub action, which is basically a bot that you can call inside your authorized GitHub repos. He's provided a really strong use case for this as well. During PR reviews, whenever he finds mistakes

he simply asks Claude to add those mistakes to the Claude.md file. As for long-running tasks, he uses three different approaches. The first is asking Claude to verify its work using different tests that Claude code itself comes up with and then putting those tasks into the background. These are not the cloud agents we're talking about. These are just background tasks that run silently and report back to the main agent once they're done. The second approach is using a stop hook to

automatically trigger this verification when Claude stops outputting. The third option he mentions is based on this idea as well, which is what the Ralph Wigum plugin is built on. We did a pretty extensive video on the Ralph Wigum plugin. We showed how we use the Ralph plugin and how we test during development to verify that the UI clawed code is producing is actually correct. It essentially removes the human from the loop entirely. Again, [snorts] repeating the pattern of verification

that he's talked about, he also uses it to verify the format of the code being written by using different kinds of llinters and formatterers for various languages. He basically says that while the models do generate correct code these formatterers help clean up the remaining 10%. And this is important so there aren't any errors when the code runs in CI as part of their GitHub integration pipelines. Now, moving on to some of the simpler features that have been in Claude Code for a long time, but

still save a lot of time and that many beginners don't know very well. As he has already mentioned, his own workflow is surprisingly vanilla. This applies to most of us. We don't need to over complicate everything in Claude code to be truly productive. These simple built-in features already get you about 90% of the productivity you're trying to achieve. Starting with slash commands he refers to his repetitive workflows as his inner loop workflows, things he has

to repeat many times a day. He gives a very simple example of a GitHub/ command that he uses frequently. Since all of these /comands are stored inside yourclaw folder in a command subfolder you can actually commit them to git. This is also how he shares them with his entire team. After that, another really simple built-in feature is sub aents. People have gone a bit crazy with this feature, building sub aents for almost every use case imaginable, like market researchers or product validators.

Everyone has their own use cases, but Boris uses sub agents to automate simple workflows that require completely different instructions. For example most of his agents are used to verify that the architecture of his code is correct, to refactor the code that's been written, and to validate that the final builds actually work. Let's talk about Automator now. After teaching millions of people how to build with AI we started implementing these workflows ourselves. We discovered we could build

better products faster than ever before. We help bring your ideas to life whether it's apps or websites. Maybe you've watched our videos thinking, "I have a great idea, but I don't have a tech team to build it." That's exactly where we come in. Think of us as your technical co-pilot. We apply the same workflows we've taught millions directly to your project. Turning concepts into real working solutions without the headaches of hiring or managing a dev team. Ready to accelerate your idea into

reality? Reach out at hello@automator.dev. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this you can do so by using the super thanks button below. As always, thank you for watching and I'll see you in the next one.