Transcription
Today we're talking about how to actually build 10 times faster with Claude Code. Most people think it's better prompts, a smarter model, or installing more plugins. But none of that is the actual unlock. The unlock is six simple power phrases you type into Claude that change how every project starts, scales, and runs without you. And in this video, I'll walk you through all six, the exact thing to type into Claude, and at the end, I'll share a cautionary phrase that 99% of people get wrong, which costs them time and money.
Power phrase number one is launch sub agents. Before I explain how this single phrase can 10x your productivity, let me outline an issue everyone watching this has run into. You ask Claude to do something, you wait 10 minutes, you review the output, you ask it again, then you wait again, and you do this over and over again. Now, there are a number of reasons why this happens, which we'll address throughout this video, but one of the biggest reasons is you're running one Claude session at a time, sequentially, like a single-lane highway. And the whole time you're sitting there waiting, you could have had five Clauds doing five different tasks in parallel, like a five-lane highway. This is what Boris Cherney, the creator of Claude Code, swears by. Multiple Clauds at once, each focused on one task end-to-end. And that's why power phrase one is launch sub agents.
Sub agents are separate Claude sessions running in parallel. Each has its own context window, prompt, and permissions. And my favorite part is you don't have to set them up manually. You'll just say launch sub agents, and Claude splits the work for you. And yes, Claude can do this without you saying launch sub agents, but Claude out of the box underutilizes sub agents. There are a number of business reasons why they would do this, but for the sake of this, the main agent just thinks this is easy, I'll just do it myself, and keeps working in its own context when a sub agent would have served you better. So, knowing when to force the issue is a critical skill. But what kind of task should you use this on? There are three things that I use them on in my own business, as well as in my client's seven- and eight-figure businesses.
The first scenario is multiple perspectives. Five sub agents analyzing the same thing in parallel give you a diverse opinion. If you ask the same thing five times in one single chat, the model anchors on its previous's response, and it all converges to the same thing. In practice, for a non-technical output, you could use something like this prompt to analyze a social media post across three different lenses. Or for a technical output, you could review your code like this, where each sub-agent look at the same input through a different lens. For both of these, each sub-agent runs with its assigned task without seeing the others, meaning the results of the individual sub-agents won't impact the others, which is a massive unlock.
Now, scenario two is it opens the door for new possibilities. Having agents at your disposal opens a door to complete tasks that you would have never done before. For example, to help me find buildpartner.ai domain, I launched 10 different sub-agents to check 10,000 plus domains. Each agent focus on different groups. This is something that I just would have never done because it would have taken too long for a single agent to do, and it just would have been too much back and forth. So, it opens up the realm of possibilities of things that you would consider doing.
Now, scenario three is you can just work quicker. If your tasks are independent of each other, just launch sub-agents. To get started with all of this, it's as simple as writing this at the end of your prompt. Launch five sub-agents to handle this. And this is one of my favorite of all the power phrases because of how lazy you can be with it. There's one clear thing you have to avoid. No matter how many sub-agents you launch, if you aren't crystal clear about what they should be doing, you're going to be disappointed with the output.
And that brings us to power phrase number two, which is the only thing that will let these sub-agents be extremely powerful. Phrase two, write me an implementation spec. The creator of Claude Code is on record for saying that before you build anything, you need to create a plan or a spec so the AI knows how to build it. And you may have heard this before, but let me address one misconception you may be thinking. Doesn't Claude already have plan mode for this? And sort of, right? So, plan mode, which you can get to by hitting shift tab in Claude Code, helps you create the spec, but it doesn't replace it. As Andrej Karpathy, the former head of AI at Tesla, put it, I actually don't even like the plan mode. I I would I mean, obviously it's very useful, but I think there's something more general here where you have to work with your agent to design a spec that is very detailed, and And it's a maybe basically the docs, and then get the agents to write them. >> Okay, so that's from Karpathy.
Now, why is creating a spec so important? Everyone watching this has had this happen. Type in a Claude, you wait 10 minutes, you review the output, and it isn't even close to what you wanted. And this happens because unless you're extremely specific, Claude has to make assumptions. And statistically, those assumptions are just unlikely to be correct. So, to show this, let's say there are three steps in a build, and there are five potential options at each step in the process. The total number of combinations is 5 * 5 * 5, so there are 125 potential ways to build it. Now, if you build a proper spec before Claude does anything outlining these three steps and how to build it, there's now 1 * 1 * 1 option. There's only one possible solution, and Claude will get it right almost every single time. That's a simplified example, but in reality, you may be building something with thousands of options and hundreds of steps. So, without a proper spec, it's statistically impossible for Claude to get it right on the first try. And it literally doesn't matter how good these models get. It doesn't know what you you don't tell it.
In practice, here's what this could look like. Write me an implementation spec to build a daily overview automation. Claude will then write a spec doc for how it plans to do it. You can then review it, and now you can be confident that it'll build the right thing. If you want a more robust prompt, you can type this in or just take a screenshot of it and drag it into Claude. The most important line of this is for each step, show me the key decisions you'd make. This forces Claude to break down the build so you can override decisions before it builds anything.
Now, something you may be thinking to yourself is, how do you know what should be in the spec? And how do I know if that's even the best strategy? And we'll cover that in power phrase number three, but before that, I'm moving pretty quickly, and if you want a more in-depth breakdown, you can do it at your own pace. I have a free 5-day email series that covers the AI system I use to help build a $25 million-plus startup. Over 4,000 people just like yourself have gone through it and have absolutely loved it, but if you don't like it, you can unsubscribe at any time. So, to check that out, click the first link in the description. Again, it is entirely free.
Power phrase number three is interview me. So, you've created the spec, which sounds great in theory, but there are some real limitations. You have AI write the spec for you and then you realize you don't know what the you're looking at. You know what you want to build at a high level, but you don't know the details that make or break the project. But, I think you do know the details. You just don't know the right questions to ask and that's why power phrase three is interview me. Instead of you trying to use AI to give it enough context to write a perfect spec from scratch, Claude flips the switch. Claude then asks you the questions that you didn't know to ask. And the reality is when Claude's outputs aren't great, it usually boils down to a thinking problem. And by having Claude interview, very quickly you'll realize, "Man, I never thought about that. This Claude thing, it's pretty smart, huh?" And this will save you hours of building the wrong thing.
Here's a prompt you can use and within it there are a couple of key meta points you have to consider. The first is work with me to identify the core problem we're solving, who it is and isn't for. I cannot stress how important this is. One of the reasons Anthropic, the creator of Claude, has been able to grow so quickly is they have a clear focus on who they are initially building for and who they are not building for. For them, they were building specifically for developers. And you need to think about this in the same way because that impacts the final product. The second is work through any key decisions together. This invokes Claude to ask questions about each step. You may not know all the steps to building a thing, which is totally fine, but Claude does. And work through those steps with Claude and if you don't know the answer, just say, "Use your best judgment." That's basically the same as just yoloing it, but at least you now understand what impacts the actual final product. The third is summarize it back to me as an implementation spec. The interview me pulls the info out of you and then I'll create a spec from it. You go from a blank page to a complete spec in less than five minutes.
Now, the trap with interview me is it only works if you actually think before you answer. And don't just rush through it saying yes or no because you might as well just have Claude auto answer for you then. Sit with each question and answer with full context. And the pro tip here, use Hex or WhisperFlow to record your voice and have it write the answer for you, so it feels a little bit more like a real interview.
Now you've gotten the spec, the interview, and parallel sub-agents launched. You're moving extremely fast, but there's a massive problem that catches everyone off guard. And that's where power phrase number four, verify before you build, comes in. Unfortunately, Claude hallucinates, tells you task is complete when the thing isn't actually complete or it doesn't work as you want it. Boris, the creator of Claude Code, is on record for saying, "Give Claude a way to verify its work. If it has a feedback loop, it will two to three X the quality of the final result." But Boris actually took it one step further. He said the real move is to give Claude a tool to see the output of its work. Then tell Claude about that tool. Once it can actually see its own output, it can self-correct. So, if you're building a website, give Claude the ability to open a browser and check the work. If you're creating a report, give Claude a way to check it against your brand guidelines. The verification rule tells Claude what to verify, the tool tells Claude how to verify it.
So, to actually verify before you build, take a three-layer approach. Layer one is update your Claude MD. Have Claude add one line to your Claude MD file. Before you do any work, mention how you could verify that work. The Claude.md file gets inserted at the start of every prompt you write, so now Claude will bias towards telling you its verification plan first before anything is built. Layer two is enable the necessary tools. Ask Claude, "Based on what I'm building, what are some tools that could help with verification?" And these tools can be both external or internal and technical or non-technical. Two examples, the first one, an external technical example. Let's say you're deploying an app to Hostinger and you want to make sure that it's live. You can set up the Hostinger MCP to verify the deploy was successful. And in the other example, an internal non-technical example. Let's say you're writing a social media post. You can make a brand voice validator skill that checks output against your voice. And I'll cover later in this video of the best way to create these skills.
Now layer three is understand your human validation zones. Murphy's law states, "Anything that can go wrong will go wrong." And in the age of AI, this has never been more true. AI agents doing the majority of the work now means that humans are removed from the loop for almost everything that relates to execution. So, you can just guarantee that things will happen that you didn't want to happen. So, to actually verify agents outputs, you have to identify where cost of error is high. Those then become your human validation zones. Let's say you have an app and the website itself that the users interact, let's consider that low cost of error. But the payment system behind all of it, that's high cost of error. So, you would identify that payments is a human validation zone, which you would then require to sign off on on any changes. And then on the other hand, the low cost of error, the website itself, you're okay with building fast and breaking things there. Now, there's a whole rabbit hole on how to handle those human validation zones, but the simplest move is to require human sign off on changes, remove permissions entirely. I go a bit deeper into this in this video, but the 80/20, you can update your Claude MD to say this.
Now, to integrate all three layers that I just covered as quickly as possible, type this into your Claude code. This is the way to 80/20 the whole verification process.
Now, the first four power phrases set the foundation, but the last two are the most important ones that you can't ignore. But before we get to those, if this is your first video, welcome the channel. If it's your second or more, here is our anti-slop agreement. The visuals, the testing, the time I put into this is for humans, you watching this, not for AI Claude or robots. So, all I ask is that you subscribe as part of this agreement so that I can keep making videos for humans and not AI robots. Also, I do want to congratulate Floki Crypto for winning our Claude Max giveaway. For everyone else watching, comment below with what you're building to enter the next giveaway.
Power phrase number five. Based on this conversation, build me a skill. So, now you've got sub-agent specs, interview, verify. You're shipping clean work fast. But here's a problem you'll notice within a week. You're going to start doing things repeatedly. And that's where you're going to need the phrase, based on this conversation, build me a skill. To summarize what a Claude skill is, it's a folder with instructions that Claude can call automatically. Think of it like a set of directions that allows Claude to do the same thing every single time. But here's where most people get this wrong. They sit down and they think abstractly. They say, "What skill should I build?" And either they never build one because they just can't think of anything, or they build one and they never use it, which is why you should never build skills abstractly. You have to build them from conversations that you've already had. When you say, "Based on this conversation, build me a skill," you're forcing the skill to come from something you just did. The use case is already validated because you literally just did the work manually. Claude is just packaging it up to make it repeatable for the next time.
So once you do this, you've created a skill, but there's one move that'll 10x its quality. Anthropic just published an article on how they use skills internally. And the best thing you can do to these skills is add a gotchas section. What exactly is this? Well, when you first make a skill, you're going to realize that it's not perfect. And the small issues that come up when you're using it, these are what we call gotchas. These are edge cases, stylistic quirks, anything you had to go back and forth to get the final output correct. To enhance your skill over time, you'll include these gotchas as you use it so that it doesn't make the same mistake twice. You can say, "Based on this conversation, enhance any skill I use to include a gotchas section so we don't make this mistake again." The biggest takeaway from all of this is instead of asking, "What skill should I create?" you have to say, "Should I turn this process into a skill?" Concrete beats abstract every time. The faster you can identify gotchas and update the skill, the faster it'll improve. Tightening that feedback loop is what makes skills compound.
And that's why this next power phrase is the most powerful, yet the most dangerous of all of the phrases. Power phrase number six, automate this. As they say in Spider-Man, with great power comes great responsibility. And this power phrase is one that I'm the most skeptical of. There are two scenarios to consider when setting up automation with AI. The ideal, which it works all the time perfectly. And then the not ideal, it breaks and the output isn't exactly what you want. And the reality is, unlike a lot of the YouTube AI productivity hype boys, almost nothing is the ideal scenario. You'll end up with a lot of non-ideal automations. So, each one adds operational debt that you have to manage. So, the reality is you should be thinking about augmentation, which is using AI to streamline your processes, not just automating them entirely.
So, when should you automate this and when should you augment it? First, you need to run what I call the taste test. Ask yourself, does this task require taste to judge a good or bad output? Or is it entirely quantifiable? If it requires taste, then it has to be augmented. If it doesn't require taste, then it's a potential automation candidate. Then, once you do that, run the 80/20 output analysis. If the output was 80% as good, would I be okay with it? If yes, automate it. If no, augment it. For the 80/20 output analysis, here's a list of things that I'm okay with 80% as good. And then on the flip side, here is what I refuse to lose any quality on. So, these two filters are things that 99% of people don't do. Unfortunately, what happens instead of doing this, people create a ton of different automations that do nothing besides waste tokens and produce AI slop at scale.
Now, Claude has a bunch of features that help with both automation and augmentation, which I'm going to be making a whole video on, which you'll be able to find in the description once that's ready. But, on screen you can see three features the creator of Claude code calls the most powerful features: hook, schedule, and loops. If you bring this into Claude, it'll give you a starting point for how to think about automation and augmentation. Now, please, please, please be mindful anytime you say automate this. As someone who loves productivity and spends every day thinking about this, trust me, be careful using this phrase.
Now, that is the last of all six of the power phrases that we covered today. Now, if you like this video, you'll love this one where I build on the exact concepts we covered. I show you how to take these phrases and turn them into a system that will give you a competitive advantage for the next 5 to 10 years. I'll see you in the next one. Peace.