You're Using Claude Code WRONG! (Here's how to fix that)

You're probably using Claude wrong. Not because Claude is bad, not because you're doing something incorrect, but because most people use Claude like a chatbot. This week, Boris Churnney, the creator of Claude Code, shared how he actually uses it day-to-day. This was not a demo or not a marketing scheme, but his actual real setup. So, let's walk through it step by step exactly as he posted it. Before we start the thread, quick context for anyone new. Cloud code is Enthropic's coding environment built around cloud models. It's not autocomplete and it's not just a chat window. Claude can read your repo, edit files directly, run commands, execute tests, reason across an entire project. And that matters because everything in this workflow depends on Claude being able to actually touch the code, not just suggest snippets. Now, let's start with Boris's first tweet. Morris opens up by saying his setup is surprisingly vanilla. That's important framing because he's not saying that this is the best way to use Claw Code. He's saying there's no single correct way. And this tool is intentionally built so different people can use it differently. So this is not going to be a tutorial. It's a real workflow from one person who happens to be the guy who created Cloud Code. So if I were to actually use Cloud Code, I would probably listen to Boris and follow the way he uses Cloud Code. So let's get into it. So the first step he does is that he runs five claude sessions in parallel in his terminal. He numbers the tabs one through five and uses system notification to know when claude needs input. So this is quite different from how most people might use cloud code. What most of us might do is that we might give it a command, wait for it to finish, and then give it the second command, follow up. But instead, Boris is treating cloud code like his employees. One Claude might be refactoring, another one running test and another fixing a bug. Claude is working in the background and when it needs him, it pings him. So this is the first key step. On top of the terminal sessions, he also runs 5 to 10 Claude sessions in the browser. Sometimes work moves from the terminal to web or sometimes it goes the other way. And this part is easy to miss but important. He also stores sessions from his phone and usually does that in the morning and checks in later on them. Claude isn't something he opens and closes. It's something that's already running during the day and is happening in the background. And he only goes in when things are done and he's actually using Claude like an actual AI agent, which is something that it was meant for anyways. So, this is something to keep in mind. You don't have to rely on the terminal alone. Cloud code is also available on the web and even your phone, which is something that you can take advantage of. Morris also says that he actually uses Opus 4. 5 with thinking enabled for basically everything. Even though it's bigger and slower than Sonnet, he's actually doing it on purpose, which kind of makes sense because you have to guide it less. This is kind of an important trade-off. A faster model that needs constant correction often is going to end up being slower overall. So, he's optimizing for endto-end speed. So, the next time you're using Cloud Code, maybe try switching to Opus 4. 5 instead of Sonnet. This might be the most important idea in the entire thread, but the team shares a single claw. md file checked into git. Anytime claude does something wrong, unclear or undesirable, they don't just fix it, they write it down. Rules like always use bun, not mpm, never use enums, run specific checks before PRs. Over time, this becomes the shared memory for Claude. Claude doesn't relearn the same lesson every session. The system improves permanently based on this working file that they have going on. During code reviews, Boris will tag atclaude directly on APR. He asks Claude to update claude. md as part of the review. Claude makes the change, commits it, and now every future session benefits. This is what people mean by compounding engineering. But this is what it actually looks like in practice. Most of his sessions actually start in plan mode. He goes back and forth with Claude until the plan actually feels right. Only then does he switch to auto accepted mode and lets Claude finally execute. He's not asking Claude to just code. He's using it as a planning partner first. And because he's spending that time to make sure that his plan is correct, then he's able to often oneshot the whole process. So this is why the plan mode is really important and is not something that you should just accept automatically. To save a bunch of time, Boris actually uses slash commands for workflows he repeats constantly. For example, the commit push PR command is a command that commits changes, pushes them, and opens a PR. Instead of reprompting, he turns the repeated work into reusable commands. And this allows him to improve his whole workflow process and save bunch of time that obviously is very valuable for everyone. Boris also mentions that he uses sub agents for common workflows. This part is easy to gloss over, but it's actually a big deal because instead of prompting

Claude differently every single time, he creates small specialized agents that have a very narrow role. For example, one agent focused on simplifying code, one focus on architectural decisions, one focused purely on validation. Each agent has a clear job and a clear way of thinking. The benefit here isn't intelligence, it's trying to be consistent and saving you a bunch of time. When you reuse the same agent, you get predictable behavior. You're not relying on a fresh prompt every single time. You're relying on a role that already knows what good looks like. And this is another example of moving away from chatting and towards proper workflow system. Next, Boris talks about post tool use hooks. In simple terms, this means Claude's output gets automatically formatted after it finishes a task. Why does this matter? Because formatting issues are one of the biggest sources of friction when using AI for real work. Extra white space, wrong conventions, small problems that don't break the code but kind of slow you down in the whole process. So instead of fixing those manually or reprompting Claude, the system just cleans it up automatically. This is one of those small improvements that doesn't sound super exciting, but when you're using Claude all day, it saves a surprising amount of mental energy and time. Boris also mentions how he handles permissions. Instead of skipping permissions entirely, which can be risky, he pre-approved save common commands in shared configuration files. That means Claude doesn't interrupt constantly. He doesn't have to click approve every few seconds, but dangerous commands are still blocked. This is a theme you see throughout the workflow. He's not trying to remove safety. He's trying to remove unnecessary friction. That's a recurring pattern in how he uses Claude code and how you should be as well. This is where Claude stops becoming just a coding tool. Boris explains that Claude can use MCP's model context protocol tools to interact with real systems. That includes things like posting messages to Slack, curing Big Cury, pulling logs from monitoring tools, all from inside the Cloud workflow. This matters because now Claude isn't operating in isolation. It has access to the same information humans use to debug, review, and make decisions. At this point, Claude isn't just writing code. It's participating in the engineering process. Boris says that this is the single most important thing for getting good results. Claude needs a way to verify its work. That could mean running tests, opening a browser, checking UI behavior, validating outputs against expectations, and without verification, Claude is basically just guessing. With verification, however, Claude can iterate. And he makes a strong claim here. Output quality improves two to three times when Claude can check its own work. That's not because the model gets smarter. It's because the feedback loop gets tighter and it helps improve the model overall. When you zoom out and take a look at the whole thing, a pattern starts to show up. This isn't really about clever prompts or tricks or knowing the right words to say to the model. It's about how the work is structured. Instead of waiting on one response at a time, he's running things in parallel. Instead of jumping straight into code, he spends time planning first. And instead of fixing the same mistake over and over, he writes them down so they don't happen again. And finally, instead of trusting the output blindly, he gives the system a way to check itself. That's the difference. Most people use Claude like a chatbot, Boris uses it like a system. Make sure to subscribe to our channel. We do real tests, not just headlines. Make sure you're also subscribed to the world of AI. And don't forget to check out our newsletter for deeper breakdowns you won't see on YouTube. And I'm growing my Twitter following, so make sure you follow me on Twitter as well. Hope you guys enjoyed today's video and I'll see you in the next