WEBVTT 00:00:00.000 --> 00:00:02.120 Picture treating Claude Code like an exhausted 00:00:02.120 --> 00:00:05.400 intern. You hand over a single task. Right. Just 00:00:05.400 --> 00:00:07.519 one thing at a time. You sit back and wait for 00:00:07.519 --> 00:00:10.619 an answer. Then you assign the very next piece. 00:00:10.859 --> 00:00:13.119 Which is totally sequential. Exactly. Doing this 00:00:13.119 --> 00:00:16.219 sequentially is a massive mistake. It's actually 00:00:16.219 --> 00:00:19.300 the fastest way to waste tokens. Tokens are the 00:00:19.300 --> 00:00:22.320 basic units of data AI reads. Every single prompt 00:00:22.320 --> 00:00:25.399 resends your previous history. You drain your 00:00:25.399 --> 00:00:28.199 context window completely dry. And the context 00:00:28.199 --> 00:00:30.879 window is the AI's short -term memory limit. 00:00:31.059 --> 00:00:33.200 You end up spending your entire afternoon just 00:00:33.200 --> 00:00:35.619 waiting for answers. Well, welcome to this deep 00:00:35.619 --> 00:00:38.520 dive. Today, we're exploring the six power phrases 00:00:38.520 --> 00:00:41.479 of cloud code efficiency. A lot of developers 00:00:41.479 --> 00:00:44.500 think faster AI just requires better underlying 00:00:44.500 --> 00:00:47.579 models. Yeah, or they assume they need to install 00:00:47.579 --> 00:00:51.060 more external plugins. Or write incredibly complex 00:00:51.060 --> 00:00:53.719 prompts. We operated under that exact same assumption 00:00:53.719 --> 00:00:56.320 initially, you know. The real speed jump happens 00:00:56.320 --> 00:00:58.200 differently, though. it comes from building a 00:00:58.200 --> 00:01:00.939 highly structured system true speed is not about 00:01:00.939 --> 00:01:03.280 mashing the gas pedal it requires rethinking 00:01:03.280 --> 00:01:06.079 the architecture of your workflow that is exactly 00:01:06.079 --> 00:01:09.019 the shift we need the secret really lies in using 00:01:09.019 --> 00:01:12.980 six specific phrases these phrases build a system 00:01:12.980 --> 00:01:15.640 that works in parallel Right. And it forces the 00:01:15.640 --> 00:01:19.019 AI to plan properly beforehand. It empowers the 00:01:19.019 --> 00:01:21.319 system to catch its own mistakes. You stop working 00:01:21.319 --> 00:01:23.540 sequentially and start working systematically. 00:01:23.879 --> 00:01:26.620 So let's jump in. We must change how we assign 00:01:26.620 --> 00:01:29.659 the workload. Forcing one session to handle everything 00:01:29.659 --> 00:01:32.319 just breaks down. That brings us to our first 00:01:32.319 --> 00:01:35.019 phrase. You want to say, launch subagents to 00:01:35.019 --> 00:01:37.120 handle this. Launch subagents to handle this. 00:01:37.219 --> 00:01:40.299 Exactly. This phrase unlocks the sheer power 00:01:40.299 --> 00:01:43.730 of parallel work. Claude can theoretically spin 00:01:43.730 --> 00:01:47.109 up subagents by itself. But it rarely uses them 00:01:47.109 --> 00:01:48.989 when it actually should. The main agent usually 00:01:48.989 --> 00:01:51.370 tries to do everything alone. It forces heavy 00:01:51.370 --> 00:01:54.150 lifting into one single context window. Which 00:01:54.150 --> 00:01:57.390 creates a massive bottleneck for complex projects. 00:01:57.629 --> 00:01:59.530 It really grinds the whole process down. Take 00:01:59.530 --> 00:02:02.049 code review as a very practical example. Don't 00:02:02.049 --> 00:02:04.689 ask for one vague general review. You should 00:02:04.689 --> 00:02:07.790 launch five specific subagents instead. Yeah. 00:02:08.090 --> 00:02:11.550 Agent 1 actively checks the code for bugs. Agent 00:02:11.550 --> 00:02:14.650 2 looks exclusively for hidden security flaws. 00:02:14.949 --> 00:02:17.330 Agent 3 searches for any underlying performance 00:02:17.330 --> 00:02:20.569 problems. Right. Agent 4 reviews the final user 00:02:20.569 --> 00:02:24.330 experience flow. And Agent 5 flags any messy 00:02:24.330 --> 00:02:26.889 code. It's like an assembly line instead of one 00:02:26.889 --> 00:02:28.689 person running around the factory. Right. And 00:02:28.689 --> 00:02:31.069 they operate at the exact same time. Every single 00:02:31.069 --> 00:02:34.189 subagent gets its own specific task. It gets 00:02:34.189 --> 00:02:36.750 isolated context and its own distinct permissions. 00:02:37.449 --> 00:02:39.430 Claude eventually brings all those parallel results 00:02:39.430 --> 00:02:41.389 back together. You end up with a fundamentally 00:02:41.389 --> 00:02:44.669 cleaner review. Every agent knows exactly what 00:02:44.669 --> 00:02:47.129 it is responsible for. And it returns its findings 00:02:47.129 --> 00:02:49.949 ranked strictly by severity. The crucial mistake 00:02:49.949 --> 00:02:52.870 here involves being far too vague. Vague instructions 00:02:52.870 --> 00:02:55.810 will absolutely ruin the subagent process. You 00:02:55.810 --> 00:02:58.169 can't simply say, launch subagents to improve 00:02:58.169 --> 00:03:00.729 this. That sounds convenient, but it gives Claude 00:03:00.729 --> 00:03:03.490 too much room. The assigned tasks must be strictly 00:03:03.490 --> 00:03:06.259 independent. What happens if their assigned resources 00:03:06.259 --> 00:03:09.219 heavily overlap during this process? They basically 00:03:09.219 --> 00:03:11.719 trip over each other and waste valuable compute 00:03:11.719 --> 00:03:14.580 time. You must define what each agent should 00:03:14.580 --> 00:03:17.400 avoid doing. Keep tasks strictly independent 00:03:17.400 --> 00:03:21.280 to prevent wasted compute? Exactly. Subagents 00:03:21.280 --> 00:03:24.039 act as our parallel workers here. But parallel 00:03:24.039 --> 00:03:26.979 workers without a blueprint just create faster 00:03:26.979 --> 00:03:29.199 chaos. They definitely do. We need our second 00:03:29.199 --> 00:03:31.930 power phrase to fix that. Write me an implementation 00:03:31.930 --> 00:03:34.610 spec. We have to force Claude to write the manual 00:03:34.610 --> 00:03:36.930 before the code. This solves one of the biggest 00:03:36.930 --> 00:03:40.129 problems in AI coding. Claude simply cannot read 00:03:40.129 --> 00:03:42.509 your mind. If you give it a vague build request, 00:03:42.770 --> 00:03:45.389 it guesses. It guesses the file structure and 00:03:45.389 --> 00:03:47.810 the core logic. It guesses the necessary tools 00:03:47.810 --> 00:03:50.750 and the edge cases. Some of those guesses might 00:03:50.750 --> 00:03:53.610 actually be brilliant, but many will be slightly 00:03:53.610 --> 00:03:56.770 wrong or misaligned. You waste hours fixing architectural 00:03:56.770 --> 00:03:59.210 decisions you never actually agreed to. It is 00:03:59.210 --> 00:04:01.669 incredibly frustrating. Now, Cloud Code does 00:04:01.669 --> 00:04:04.150 have a built -in plan mode. You trigger it by 00:04:04.150 --> 00:04:06.810 hitting Shift plus Tab. Right. It helps you plan 00:04:06.810 --> 00:04:09.990 the immediate short -term work, but you cannot 00:04:09.990 --> 00:04:12.370 treat it as a comprehensive replacement. You 00:04:12.370 --> 00:04:15.169 still need a very detailed, overarching implementation 00:04:15.169 --> 00:04:18.490 spec. Consider Andres Karpathy's specific workflow 00:04:18.490 --> 00:04:21.269 method here. He prefers writing detailed docs 00:04:21.269 --> 00:04:23.670 with the agent first. You essentially write the 00:04:23.670 --> 00:04:25.990 manual before building anything. People always 00:04:25.990 --> 00:04:28.089 want to skip that planning phase, though. They 00:04:28.089 --> 00:04:30.589 want the AI to start coding immediately. And 00:04:30.589 --> 00:04:32.310 then they get annoyed when the output fails. 00:04:32.689 --> 00:04:35.009 Let's break down the actual math of guessing. 00:04:35.209 --> 00:04:37.990 Okay. Imagine your upcoming project has three 00:04:37.990 --> 00:04:40.910 major steps. There are five possible ways to 00:04:40.910 --> 00:04:43.889 execute each step. That gives Claude five times 00:04:43.889 --> 00:04:48.529 five times five choices. Yep. 125 possible outcomes. 00:04:48.829 --> 00:04:55.000 Whoa. Beat. Imagine 125 chaotic timelines shrinking 00:04:55.000 --> 00:04:58.620 to just one perfect execution. That is the exact 00:04:58.620 --> 00:05:01.740 mechanism of a proper spec. You reduce the massive 00:05:01.740 --> 00:05:04.519 guessing game down to one intended build. Claude 00:05:04.519 --> 00:05:06.620 now understands the intended structural truth. 00:05:06.879 --> 00:05:09.459 It knows the preferred tools, the order, and 00:05:09.459 --> 00:05:11.480 the strict constraints. This makes those sub 00:05:11.480 --> 00:05:13.680 -agents much more effective later. Without a 00:05:13.680 --> 00:05:15.819 plan, they sprint in completely different directions. 00:05:16.160 --> 00:05:18.779 With a spec, every agent works from the same 00:05:18.779 --> 00:05:21.860 foundation. Your prompts need very specific details 00:05:21.860 --> 00:05:25.279 here. Tell Claude to break the build into clear 00:05:25.279 --> 00:05:27.759 steps. Force it to highlight key decisions for 00:05:27.759 --> 00:05:30.480 each step. Make it explain the complex trade 00:05:30.480 --> 00:05:33.860 -offs behind each decision. Demand asks what 00:05:33.860 --> 00:05:36.319 it needs from you before building. Never let 00:05:36.319 --> 00:05:38.540 it start implementation until you explicitly 00:05:38.540 --> 00:05:41.720 approve the spec. Right. When does an implementation 00:05:41.720 --> 00:05:45.019 spec become entirely too detailed to use? Well, 00:05:45.060 --> 00:05:47.079 if the spec takes longer to read than writing 00:05:47.079 --> 00:05:48.939 the code yourself, you definitely went too far. 00:05:49.449 --> 00:05:52.389 Focus on key architectural decisions, not every 00:05:52.389 --> 00:05:56.850 single line. Exactly. Beat. A spec clearly fixes 00:05:56.850 --> 00:05:59.730 the AI's guessing problem. But what if you were 00:05:59.730 --> 00:06:01.790 the one guessing? What do you mean? What if you 00:06:01.790 --> 00:06:03.870 lack the technical details yourself? Ah, that 00:06:03.870 --> 00:06:05.990 is exactly when you deploy power phrase number 00:06:05.990 --> 00:06:08.490 three. You tell Claude, interview me. Interview 00:06:08.490 --> 00:06:11.769 me. This phrase radically flips the entire workflow 00:06:11.769 --> 00:06:14.389 dynamic. Claude stops acting like a passive builder 00:06:14.389 --> 00:06:16.310 for a moment. It steps up and acts like a senior 00:06:16.310 --> 00:06:18.660 project lead. You might know what you want at 00:06:18.660 --> 00:06:22.519 a high level, but you probably miss the crucial 00:06:22.519 --> 00:06:26.199 granular details. The database choice, the user 00:06:26.199 --> 00:06:29.680 flow, the edge cases. Right. The permission rules, 00:06:30.000 --> 00:06:33.399 the error states, the final review process. These 00:06:33.399 --> 00:06:36.079 invisible details shape the final product entirely. 00:06:36.439 --> 00:06:38.480 They really do. I still wrestle with the blank 00:06:38.480 --> 00:06:40.540 page problem myself when starting out. It's a 00:06:40.540 --> 00:06:42.500 very common hurdle. That's why this interview 00:06:42.500 --> 00:06:45.079 phrase matters so much. Claude asks you the questions 00:06:45.079 --> 00:06:47.829 you may not know to ask. it extracts the vision 00:06:47.829 --> 00:06:51.250 hiding in your head then it turns your scattered 00:06:51.250 --> 00:06:53.870 answers into a solid spec there are some very 00:06:53.870 --> 00:06:56.110 specific rules for this interview process though 00:06:56.110 --> 00:06:59.029 yeah you must demand that claude asks only one 00:06:59.029 --> 00:07:01.350 question at a time that is a critical constraint 00:07:01.350 --> 00:07:04.329 if claude gives you 15 questions at once the 00:07:04.329 --> 00:07:06.490 process fails you will inevitably rush through 00:07:06.490 --> 00:07:09.230 them and give weak answers Asking one question 00:07:09.230 --> 00:07:11.769 at a time creates a real dynamic conversation. 00:07:12.269 --> 00:07:14.370 You might also want to use voice dictation tools 00:07:14.370 --> 00:07:17.189 here. Speaking your complex answers often feels 00:07:17.189 --> 00:07:20.689 much easier than typing them. Tools like Hex 00:07:20.689 --> 00:07:23.709 or Whisperflow make this highly conversational. 00:07:23.850 --> 00:07:25.990 It makes the whole architectural process feel 00:07:25.990 --> 00:07:28.910 much more natural. There is a dangerous trap 00:07:28.910 --> 00:07:31.569 with this interview phrase, however. Vague answers 00:07:31.569 --> 00:07:34.209 will ruin the final output entirely. It's a huge 00:07:34.209 --> 00:07:37.370 trap. If Claude asks who the tool is for, Don't 00:07:37.370 --> 00:07:40.149 just say founders. That is way too broad and 00:07:40.149 --> 00:07:42.810 vague. You need to be incredibly specific with 00:07:42.810 --> 00:07:46.370 your user constraints. Say solo founders who 00:07:46.370 --> 00:07:49.269 need to review daily customer feedback. That 00:07:49.269 --> 00:07:51.990 small contextual difference changes the entire 00:07:51.990 --> 00:07:54.470 build direction. Claude needs to help you actively 00:07:54.470 --> 00:07:56.509 narrow the idea down. It should ask about the 00:07:56.509 --> 00:07:58.870 core problem we're actually solving. This stops 00:07:58.870 --> 00:08:01.170 you from building random, unnecessary features. 00:08:01.430 --> 00:08:03.990 It asks about the target user to drive specific 00:08:03.990 --> 00:08:07.339 product choices. and about the non -user to tightly 00:08:07.339 --> 00:08:10.000 prevent broad scopes. What if I simply do not 00:08:10.000 --> 00:08:11.879 know the answer to Claude's interview question? 00:08:12.240 --> 00:08:14.980 You just tell the AI to use its best judgment 00:08:14.980 --> 00:08:17.779 and explicitly justify the choice later. Just 00:08:17.779 --> 00:08:19.480 hand the steering wheel back to Claude, the sponsor. 00:08:19.879 --> 00:08:22.540 Coming back to it, you have a solid spec. You 00:08:22.540 --> 00:08:24.959 survived the interview. The sub -agents built 00:08:24.959 --> 00:08:28.839 the code. But AI can be confidently wrong about 00:08:28.839 --> 00:08:31.439 its work. Beat. It sounds incredibly confident 00:08:31.439 --> 00:08:34.279 even when the task is incomplete. It might claim 00:08:34.279 --> 00:08:36.259 the new feature is totally finished. Or it might 00:08:36.259 --> 00:08:39.240 state the database bug is completely fixed. You 00:08:39.240 --> 00:08:41.419 test the application and realize something is 00:08:41.419 --> 00:08:44.580 clearly broken. This creates an incredibly expensive 00:08:44.580 --> 00:08:48.080 mistake in AI coding workflows. You lose trust 00:08:48.080 --> 00:08:50.299 and have to manually inspect everything anyway. 00:08:50.600 --> 00:08:52.860 This risk is why we need power phrase number 00:08:52.860 --> 00:08:56.259 four. You must tell Claude, verify before you 00:08:56.259 --> 00:08:59.320 build. This creates a vital automated feedback 00:08:59.320 --> 00:09:01.879 loop. The engineer Boris Cherny points out something 00:09:01.879 --> 00:09:05.029 fascinating here. A strong feedback loop improves 00:09:05.029 --> 00:09:08.450 model results massively. It can improve the final 00:09:08.450 --> 00:09:11.049 code quality by two to three times. Make Claude 00:09:11.049 --> 00:09:13.450 explain its detailed verification plan before 00:09:13.450 --> 00:09:16.269 it touches code. It must state clearly what actual 00:09:16.269 --> 00:09:19.009 success looks like. It must list the exact diagnostic 00:09:19.009 --> 00:09:21.370 checks it will run. It must name any external 00:09:21.370 --> 00:09:23.950 tool it needs to verify work. Maybe it needs 00:09:23.950 --> 00:09:26.570 a browser to visually inspect a website layout. 00:09:26.830 --> 00:09:29.370 Or maybe it needs a deployment MCP to confirm 00:09:29.370 --> 00:09:33.049 an app. A deployment MCP is a tool that publishes 00:09:33.049 --> 00:09:35.190 your app to the internet. Right. Maybe it needs 00:09:35.190 --> 00:09:38.009 linting to check recent code changes. Linting 00:09:38.009 --> 00:09:41.070 refers to automated tools that flag basic code 00:09:41.070 --> 00:09:44.129 errors. You add this crucial rule directly to 00:09:44.129 --> 00:09:48.529 your ClawU .md file. ClawU .md is a file storing 00:09:48.529 --> 00:09:51.610 your project's AI rules. This forces verification 00:09:51.610 --> 00:09:54.509 to happen on every single task. Doesn't stopping 00:09:54.509 --> 00:09:57.169 to verify constantly slow down the magic of AI 00:09:57.169 --> 00:10:00.090 coding? It might feel slightly slower at the 00:10:00.090 --> 00:10:02.889 very beginning, but fixing invisible architectural 00:10:02.889 --> 00:10:06.250 errors later is much, much slower. You also need 00:10:06.250 --> 00:10:08.370 to heavily define your human validation zones. 00:10:08.710 --> 00:10:11.070 Those zones are boundaries where the AI must 00:10:11.070 --> 00:10:13.730 stop. Some parts of a project are safe for very 00:10:13.730 --> 00:10:16.269 fast movement. A landing page color layout is 00:10:16.269 --> 00:10:18.730 usually very low risk. If Claude accidentally 00:10:18.730 --> 00:10:20.830 breaks a visual section, you fix it quickly. 00:10:21.049 --> 00:10:23.529 But other specific parts need strict human approval. 00:10:23.809 --> 00:10:26.070 The ultimate cost of an error is simply too high. 00:10:26.509 --> 00:10:28.570 If Claude attempts to change underlying billing 00:10:28.570 --> 00:10:31.370 logic, you must intervene. You cannot let it 00:10:31.370 --> 00:10:33.809 run freely with financial data. The same strict 00:10:33.809 --> 00:10:36.309 rule applies to authentication and user permissions. 00:10:36.649 --> 00:10:39.929 It heavily applies to production database schemas 00:10:39.929 --> 00:10:42.950 and security sensitive files. How should Claude 00:10:42.950 --> 00:10:45.919 react? If a verification check actually fails 00:10:45.919 --> 00:10:47.980 during the build, it should immediately halt 00:10:47.980 --> 00:10:50.580 the process, explain the failure clearly, and 00:10:50.580 --> 00:10:53.259 propose a specific fix. It needs to hit the brakes 00:10:53.259 --> 00:10:55.779 and propose solutions. Exactly. Setting up these 00:10:55.779 --> 00:10:57.779 boundaries every single day gets exhausting, 00:10:57.899 --> 00:11:00.159 though. Two -sec silence. Power phrase number 00:11:00.159 --> 00:11:03.919 five solves that tediousness entirely. Tell Claude, 00:11:03.919 --> 00:11:06.320 based on this conversation, build me a skill. 00:11:06.600 --> 00:11:09.100 After a few days, you notice a very annoying 00:11:09.100 --> 00:11:11.639 pattern. You keep asking Claude to do the exact 00:11:11.639 --> 00:11:14.720 same conceptual work. You repeatedly ask it to 00:11:14.720 --> 00:11:17.659 review code in the same specific format. You 00:11:17.659 --> 00:11:19.740 ask it to write implementation specs the same 00:11:19.740 --> 00:11:22.580 way. You keep correcting its tone, file structure, 00:11:22.840 --> 00:11:25.480 or testing process. A Claude skill is basically 00:11:25.480 --> 00:11:29.039 a set of reusable targeted instructions. Instead 00:11:29.039 --> 00:11:31.220 of explaining the long process every time, you 00:11:31.220 --> 00:11:34.070 package it. You turn a highly successful conversation 00:11:34.070 --> 00:11:36.570 into something Claude can seamlessly repeat. 00:11:36.809 --> 00:11:39.070 You are fundamentally altering its base behavior 00:11:39.070 --> 00:11:42.129 moving forward. Exactly. But most developers 00:11:42.129 --> 00:11:44.509 think about these skills in the wrong way. They 00:11:44.509 --> 00:11:47.610 try to invent abstract, complex skills completely 00:11:47.610 --> 00:11:49.990 from scratch. They create something far too abstract 00:11:49.990 --> 00:11:52.610 and then never use it again. The right way requires 00:11:52.610 --> 00:11:56.019 waiting patiently. for real -world success you 00:11:56.019 --> 00:11:58.740 wait until you finish a highly successful organic 00:11:58.740 --> 00:12:01.960 workflow then you ask claude to package that 00:12:01.960 --> 00:12:04.659 exact proven process the biggest upgrade here 00:12:04.659 --> 00:12:07.360 is adding a dedicated gotcha section the gotchas 00:12:07.360 --> 00:12:09.860 are the small annoying issues you discover later 00:12:09.860 --> 00:12:12.740 they cover strange edge cases strict style rules 00:12:12.740 --> 00:12:16.000 or frequently repeated mistakes Unclear instructions 00:12:16.000 --> 00:12:18.500 or minor fixes you explained more than once. 00:12:18.659 --> 00:12:20.919 You update the custom skill to remember these 00:12:20.919 --> 00:12:23.879 exact contextual issues. For example, always 00:12:23.879 --> 00:12:26.360 double check off logic before editing user permissions. 00:12:26.659 --> 00:12:30.179 Or perhaps never use inline styles. Always use 00:12:30.179 --> 00:12:32.980 Tailwind CSS classes. How many of these custom 00:12:32.980 --> 00:12:35.960 skills are too many for one single project? If 00:12:35.960 --> 00:12:38.120 you spend more time searching for the right skill 00:12:38.120 --> 00:12:40.820 than working, you definitely have too many. Only 00:12:40.820 --> 00:12:43.360 keep skills that actively save you time. With 00:12:43.360 --> 00:12:45.620 your custom skills saved, putting everything 00:12:45.620 --> 00:12:48.500 on autopilot sounds very tempting. It does. But 00:12:48.500 --> 00:12:50.840 that introduces brand new risks to the system. 00:12:51.159 --> 00:12:54.559 Beat. This brings us to the sixth and final power 00:12:54.559 --> 00:12:58.259 phrase. Automate this. People get extremely excited 00:12:58.259 --> 00:13:01.399 about this specific phrase way too early. It 00:13:01.399 --> 00:13:03.679 sounds powerful because nobody wants to repeat 00:13:03.679 --> 00:13:06.840 boring manual work. But automation with Claude 00:13:06.840 --> 00:13:10.000 code creates a brand new systemic problem. If 00:13:10.000 --> 00:13:12.299 the underlying output is slightly wrong, you 00:13:12.299 --> 00:13:15.120 produce bad work faster. Before you automate 00:13:15.120 --> 00:13:17.659 anything, decide if it truly needs full automation. 00:13:18.019 --> 00:13:20.139 It might only need a simple augmentation layer 00:13:20.139 --> 00:13:22.600 instead. Automation means Claude handles the 00:13:22.600 --> 00:13:26.059 entire process with zero human input. Augmentation 00:13:26.059 --> 00:13:28.220 means Claude does the heavy lifting, but you 00:13:28.220 --> 00:13:30.399 still review the result. There are two critical 00:13:30.399 --> 00:13:33.019 filters to use before automating any task. The 00:13:33.019 --> 00:13:35.110 first one is called the taste test. Does the 00:13:35.110 --> 00:13:38.289 task need human judgment or specific brand sense? 00:13:38.629 --> 00:13:41.629 Writing final sales copy absolutely needs real 00:13:41.629 --> 00:13:44.330 human taste. Making nuanced product decisions 00:13:44.330 --> 00:13:47.629 needs taste. Handling sensitive customer complaints 00:13:47.629 --> 00:13:50.490 needs taste. You should strictly augment these 00:13:50.490 --> 00:13:53.610 complex tasks. But what if the task is strictly 00:13:53.610 --> 00:13:57.009 measurable with clear binary rules? Checking 00:13:57.009 --> 00:14:00.370 if 100 website links are broken is totally measurable. 00:14:00.690 --> 00:14:03.870 Creating simple daily summaries. or running basic 00:14:03.870 --> 00:14:07.029 unit tests is measurable. Sorting simple IP support 00:14:07.029 --> 00:14:09.809 tickets is measurable. You can safely, fully 00:14:09.809 --> 00:14:12.570 automate these repetitive tasks. The second critical 00:14:12.570 --> 00:14:16.129 filter is the 80 -20 output check. If the final 00:14:16.129 --> 00:14:19.110 output was only 80 % good, would you survive? 00:14:19.470 --> 00:14:22.590 If the answer is yes, full automation may be 00:14:22.590 --> 00:14:25.429 perfectly fine. If the answer is no, you must 00:14:25.429 --> 00:14:28.350 keep a human in the loop. I have to push back 00:14:28.350 --> 00:14:31.169 on that framework a bit. Isn't settling for 80 00:14:31.169 --> 00:14:33.830 % defeating the purpose of a high -end AI tool? 00:14:34.090 --> 00:14:36.830 Not necessarily, because context dictates the 00:14:36.830 --> 00:14:39.570 value of the output. Right. Getting 80 % accuracy 00:14:39.570 --> 00:14:42.409 on 100 broken links saves you hours of tedious 00:14:42.409 --> 00:14:45.289 time. You can easily fix the remaining 20 % manually. 00:14:45.529 --> 00:14:47.809 But an 80 % success rate on a checkout sales 00:14:47.809 --> 00:14:50.889 page, that missing 20 % loses you actual revenue. 00:14:51.289 --> 00:14:53.950 Never fully automate changing payment gateways 00:14:53.950 --> 00:14:56.779 or deep security logic. You must also be incredibly 00:14:56.779 --> 00:15:00.320 careful with things like hooks. Hooks are automated 00:15:00.320 --> 00:15:02.960 triggers that run code in the background. A bad 00:15:02.960 --> 00:15:05.980 one -time output is slightly annoying. A bad 00:15:05.980 --> 00:15:08.340 scheduled workflow can keep running and creating 00:15:08.340 --> 00:15:11.500 endless systemic problems. How do we safely combine 00:15:11.500 --> 00:15:14.220 full automation with our parallel subagents? 00:15:14.379 --> 00:15:16.720 Have one subagent thoroughly design the automation 00:15:16.720 --> 00:15:20.259 workflow and another explicitly hunt for potential 00:15:20.259 --> 00:15:23.580 failure cases. Use one agent to build, another 00:15:23.580 --> 00:15:27.059 to test limits. Yep. Two sec silence. We need 00:15:27.059 --> 00:15:29.000 to step back and look at the big picture here. 00:15:29.200 --> 00:15:32.139 Speed in AI is not about mashing the gas pedal 00:15:32.139 --> 00:15:34.980 on simple prompts. It really is not. It is about 00:15:34.980 --> 00:15:37.379 building a highly structured parallel system. 00:15:37.639 --> 00:15:40.360 You use independent subagents when you need deep 00:15:40.360 --> 00:15:42.700 parallel work. You write a strict implementation 00:15:42.700 --> 00:15:45.299 spec before building anything at all. You let 00:15:45.299 --> 00:15:47.779 Claude interview you when the core idea is still 00:15:47.779 --> 00:15:50.399 unclear. You build a secure system that verifies 00:15:50.399 --> 00:15:53.220 its own output safely. It learns from past conversational 00:15:53.220 --> 00:15:55.720 successes by building custom skills. It respects 00:15:55.720 --> 00:15:57.960 human judgment and understands strict operational 00:15:57.960 --> 00:16:01.100 boundaries. You actively choose thoughtful augmentation 00:16:01.100 --> 00:16:04.159 over blind automation when taste truly matters. 00:16:04.460 --> 00:16:07.340 Used properly together, these six phrases give 00:16:07.340 --> 00:16:09.509 you a much cleaner way to build. The process 00:16:09.509 --> 00:16:12.549 becomes faster, highly structured, and requires 00:16:12.549 --> 00:16:15.730 far fewer messy fixes later. We want you to pick 00:16:15.730 --> 00:16:18.730 just one of these power phrases today. Try implementing 00:16:18.730 --> 00:16:21.830 it in your very next Claude Code session. I highly 00:16:21.830 --> 00:16:24.070 recommend starting with the interview me script 00:16:24.070 --> 00:16:26.950 flip. It immediately changes how you interact 00:16:26.950 --> 00:16:29.409 with the underlying model. Try flipping the script 00:16:29.409 --> 00:16:32.149 today and consider this final thought as we wrap 00:16:32.149 --> 00:16:35.009 up. Yeah. If Claude Code is fully capable of 00:16:35.009 --> 00:16:37.409 interviewing you. If it can actively plan the 00:16:37.409 --> 00:16:39.830 entire architectural build. If it can assign 00:16:39.830 --> 00:16:42.450 its own parallel sub -agents to execute tasks. 00:16:42.889 --> 00:16:45.529 If it can rigorously verify its own work against 00:16:45.529 --> 00:16:48.269 your rules. At what point do you stop being the 00:16:48.269 --> 00:16:50.750 coder and officially become the CEO of your own 00:16:50.750 --> 00:16:52.850 digital agency? Outro music.