WEBVTT 00:00:00.000 --> 00:00:03.580 You paste a massive code base into Claude. You 00:00:03.580 --> 00:00:06.500 hit enter. 10 seconds later, it spits out 500 00:00:06.500 --> 00:00:09.080 lines of code. It looks like absolute magic. 00:00:09.119 --> 00:00:11.619 Beat. Until you actually run it. Right, and your 00:00:11.619 --> 00:00:13.720 application completely crashes. We have all been 00:00:13.720 --> 00:00:16.120 there, honestly. You are using the smartest model 00:00:16.120 --> 00:00:19.579 on Earth. So why is the code garbage? Well, the 00:00:19.579 --> 00:00:22.239 secret isn't writing a better prompt. No, it 00:00:22.239 --> 00:00:25.250 is the system around the prompt. Exactly. Generating 00:00:25.250 --> 00:00:27.890 text quickly doesn't guarantee good architecture. 00:00:28.350 --> 00:00:30.550 You have to stop treating the AI like a magical 00:00:30.550 --> 00:00:33.289 slot machine. Welcome to the deep dive. Okay, 00:00:33.429 --> 00:00:36.490 let's unpack this. Today, we are exploring a 00:00:36.490 --> 00:00:40.130 playbook of 12 distinct habits for professional 00:00:40.130 --> 00:00:43.130 AI engineering. Yeah, a strong, deliberate system 00:00:43.130 --> 00:00:46.109 turns a basic prompt into production -ready code. 00:00:46.369 --> 00:00:48.649 We are going to start by laying a clean, solid 00:00:48.649 --> 00:00:51.390 foundation. Then we will move into planning and 00:00:51.390 --> 00:00:54.450 building out the code. And finally, we will explore 00:00:54.450 --> 00:00:56.750 some advanced parallel workflows. These aren't 00:00:56.750 --> 00:00:58.969 just minor workflow tweaks either. These setups 00:00:58.969 --> 00:01:01.530 fundamentally change how you ship software. Let's 00:01:01.530 --> 00:01:04.090 start with the foundation. You simply can't write 00:01:04.090 --> 00:01:07.329 good code if the AI lacks context. No, it has 00:01:07.329 --> 00:01:09.450 to understand your specific coding environment 00:01:09.450 --> 00:01:11.909 completely. Yeah, and the easiest way to establish 00:01:11.909 --> 00:01:15.189 that is initializing your workspace. Before you 00:01:15.189 --> 00:01:17.430 start chatting, you run a command called slash 00:01:17.430 --> 00:01:21.560 init. Right. When you do that, The AI scans your 00:01:21.560 --> 00:01:24.340 local code base. It then creates a small markdown 00:01:24.340 --> 00:01:28.359 file called claylode .md. Think of this file 00:01:28.359 --> 00:01:31.079 as a short project briefing. It captures your 00:01:31.079 --> 00:01:33.400 overall project structure and your technology 00:01:33.400 --> 00:01:36.420 stack. It lists the main folders and your specific 00:01:36.420 --> 00:01:39.799 coding conventions. So you skip the painful introduction 00:01:39.799 --> 00:01:42.200 phase forever. You don't have to explain your 00:01:42.200 --> 00:01:44.480 project rules every single time. Yeah, the AI 00:01:44.480 --> 00:01:46.900 just reads the file and instantly knows the rules. 00:01:47.079 --> 00:01:48.939 But you really need to keep this file incredibly 00:01:48.939 --> 00:01:52.170 short. You want to aim for roughly 150 lines. 00:01:52.390 --> 00:01:54.810 Definitely. This file loads into every single 00:01:54.810 --> 00:01:57.170 session you start automatically. That means it 00:01:57.170 --> 00:01:59.709 costs you tokens every single time you chat. 00:01:59.930 --> 00:02:02.090 Tokens, which are just the basic data units, 00:02:02.109 --> 00:02:04.469 the AI processes. Right. You pay for those tokens 00:02:04.469 --> 00:02:07.049 on every single reply. So a massive briefing 00:02:07.049 --> 00:02:09.550 file drains your wallet incredibly fast. You 00:02:09.550 --> 00:02:11.689 should set up a status line to monitor those 00:02:11.689 --> 00:02:15.289 costs. Use the slash status line command to track 00:02:15.289 --> 00:02:17.590 your context percentage. You can literally watch 00:02:17.590 --> 00:02:19.990 that percentage climb in real time. time. Seeing 00:02:19.990 --> 00:02:22.849 that number physically climb trains you to keep 00:02:22.849 --> 00:02:25.150 sessions clean. Which brings us to the most common 00:02:25.150 --> 00:02:28.310 mistake developers make. People love to paste 00:02:28.310 --> 00:02:30.870 their entire code base directly into the chat. 00:02:30.949 --> 00:02:33.430 Oh yeah, they think a bigger context window will 00:02:33.430 --> 00:02:36.229 yield much smarter answers. It sounds completely 00:02:36.229 --> 00:02:39.169 logical on the surface, but in practice it works 00:02:39.169 --> 00:02:42.969 the exact opposite way. When you dump 50 unrelated 00:02:42.969 --> 00:02:46.750 files into the chat, things break. The context 00:02:46.750 --> 00:02:49.150 window, the AI's short -term memory during a 00:02:49.150 --> 00:02:51.590 chat, gets overwhelmed. Totally overwhelmed. 00:02:51.849 --> 00:02:54.289 Think of a bloated context window like a cluttered 00:02:54.289 --> 00:02:56.930 physical desk. If there's too much junk, you 00:02:56.930 --> 00:02:59.330 cannot find the stapler. Right. Under the hood, 00:02:59.569 --> 00:03:02.590 the AI relies on attention mechanisms. It assigns 00:03:02.590 --> 00:03:04.849 a mathematical weight to every single word you 00:03:04.849 --> 00:03:07.530 provide. If you feed it too much noise, the weights 00:03:07.530 --> 00:03:10.370 get diluted. Important details simply get buried 00:03:10.370 --> 00:03:13.169 under all the irrelevant boilerplate code. Exactly. 00:03:13.449 --> 00:03:16.030 The AI's attention is pulled away from what actually 00:03:16.030 --> 00:03:18.909 matters. The final output becomes incredibly 00:03:18.909 --> 00:03:21.870 vague and generally unhelpful. So before you 00:03:21.870 --> 00:03:24.009 send a prompt, ask yourself a simple question. 00:03:24.569 --> 00:03:27.129 Would a new engineer need this file to do this 00:03:27.129 --> 00:03:30.169 task? If the answer is no, the file stays out. 00:03:30.469 --> 00:03:33.599 Beat. But realistically sessions do inevitably 00:03:33.599 --> 00:03:36.199 get heavy over time anyway Yeah, yeah back and 00:03:36.199 --> 00:03:38.780 forth debugging and the history just piles up 00:03:38.780 --> 00:03:41.419 That is why session cleaning tools are so critical 00:03:41.419 --> 00:03:45.340 here when a session feels sluggish Run the slash 00:03:45.340 --> 00:03:47.699 context command. It shows a complete breakdown 00:03:47.699 --> 00:03:50.719 of what is actually using tokens. You stop guessing 00:03:50.719 --> 00:03:53.000 what is bloating your session. You might see 00:03:53.000 --> 00:03:55.939 an MCP server eating 30 % of your window. An 00:03:55.939 --> 00:03:58.819 MCP server, a tool connecting the AI to external 00:03:58.819 --> 00:04:01.539 beta. Exactly. Or you might see an old irrelevant 00:04:01.539 --> 00:04:03.939 error log. Once you see the breakdown, you can 00:04:03.939 --> 00:04:06.460 cut the noise immediately. Around the 60 % mark, 00:04:06.960 --> 00:04:09.370 you run the slash compact command. This command 00:04:09.370 --> 00:04:11.449 compresses the conversation history effectively. 00:04:11.750 --> 00:04:13.789 It keeps the actual meaning while dropping the 00:04:13.789 --> 00:04:15.990 messy back and forth chat. You can even tell 00:04:15.990 --> 00:04:18.550 it exactly what to keep during compression. Like, 00:04:18.649 --> 00:04:20.730 you can ask it to preserve specific database 00:04:20.730 --> 00:04:24.009 schema decisions. Right. Then there is the nuclear 00:04:24.009 --> 00:04:27.550 option, the slash clear command. You use this 00:04:27.550 --> 00:04:29.709 when you switch to a completely new task. It 00:04:29.709 --> 00:04:32.209 wipes the chat history entirely, but your project 00:04:32.209 --> 00:04:34.370 files stay. You aren't starting from absolute 00:04:34.370 --> 00:04:37.079 zero. You are starting fresh with all your long 00:04:37.079 --> 00:04:40.639 -term project context preserved. Beat. So how 00:04:40.639 --> 00:04:43.600 quickly does token bloat actually degrade the 00:04:43.600 --> 00:04:47.259 AI's logic? It happens surprisingly fast in complex 00:04:47.259 --> 00:04:50.060 projects. More noise means important details 00:04:50.060 --> 00:04:53.000 simply get buried and lost. So bloated sessions 00:04:53.000 --> 00:04:55.480 just waste your money and confuse the AI? Yeah, 00:04:55.600 --> 00:04:57.519 pretty much. Now that our workspace is clean, 00:04:58.079 --> 00:05:00.709 we need some actual direction. if a bloated session 00:05:00.709 --> 00:05:03.629 is the first way we sabotage AI. The second is 00:05:03.629 --> 00:05:06.250 letting it run loose without a clear map. Right. 00:05:06.490 --> 00:05:08.550 How do we put guardrails on it? Well, you always 00:05:08.550 --> 00:05:10.649 start your workflow in plan mode. In plan mode, 00:05:10.850 --> 00:05:13.509 the AI can read, search, and research deeply, 00:05:13.649 --> 00:05:17.029 but it absolutely cannot edit your actual files. 00:05:17.149 --> 00:05:18.910 It gives you a detailed plan before changing 00:05:18.910 --> 00:05:21.790 any code whatsoever. It lists the steps and the 00:05:21.790 --> 00:05:24.089 exact files it will touch. Importantly, it also 00:05:24.089 --> 00:05:25.889 lists the assumptions it is currently making. 00:05:26.079 --> 00:05:28.819 You read that plan and decide if it makes logical 00:05:28.819 --> 00:05:31.680 sense. Let's say you ask it to build a user login 00:05:31.680 --> 00:05:35.060 page. The plan might say it will use email and 00:05:35.060 --> 00:05:37.180 password authentication. But you actually wanted 00:05:37.180 --> 00:05:40.019 a Google single sign -on flow? Catching that 00:05:40.019 --> 00:05:41.860 in plan mode takes about 10 seconds of reading. 00:05:42.379 --> 00:05:44.300 If you didn't use plan mode, the AI would just 00:05:44.300 --> 00:05:46.120 build it. Then you'd have to untangle hundreds 00:05:46.120 --> 00:05:49.639 of lines of useless code. The time spent reviewing 00:05:49.639 --> 00:05:52.259 a plan is incredibly short. It is dramatically 00:05:52.259 --> 00:05:54.699 shorter than cleaning up a confident wrong agent. 00:05:54.970 --> 00:05:57.509 You want to watch the plan for a few specific 00:05:57.509 --> 00:06:00.569 things. Is it actually solving the right problem? 00:06:00.709 --> 00:06:02.810 Is it touching files that should clearly stay 00:06:02.810 --> 00:06:06.029 completely untouched? Is it making an assumption 00:06:06.029 --> 00:06:08.709 that violates your core architecture? When you 00:06:08.709 --> 00:06:11.269 spot those issues, you push back inside plan 00:06:11.269 --> 00:06:13.730 mode. You add the missing context and correct 00:06:13.730 --> 00:06:16.050 the bad assumption directly. Then you simply 00:06:16.050 --> 00:06:18.910 ask the AI for a revised plan. This requires 00:06:18.910 --> 00:06:22.009 a shift in how we actually view the tool. We 00:06:22.009 --> 00:06:25.110 have to treat the AI like a fast, capable junior 00:06:25.110 --> 00:06:28.129 developer. It is incredibly smart, but entirely 00:06:28.129 --> 00:06:30.730 new to your company's conventions. Right. If 00:06:30.730 --> 00:06:33.350 you tell a junior developer to write a function 00:06:33.350 --> 00:06:37.290 blindly... You get raw code that might completely 00:06:37.290 --> 00:06:40.569 ignore your security standards. Exactly. But 00:06:40.569 --> 00:06:42.569 if you give them constraints and trade -offs, 00:06:42.750 --> 00:06:45.550 the dynamic changes. You ask for different approaches, 00:06:45.810 --> 00:06:48.410 and you make them reason first. You see their 00:06:48.410 --> 00:06:50.850 thinking process, and you catch logical flaws 00:06:50.850 --> 00:06:53.610 early. You should give the AI complex problems 00:06:53.610 --> 00:06:57.149 to think about. Ask it to propose three architectural 00:06:57.149 --> 00:06:59.970 approaches with pros and cons. You read the approaches, 00:07:00.069 --> 00:07:03.410 pick one, and then ask it to build. Two secs 00:07:03.410 --> 00:07:05.389 silence. I mean, I still wrestle with prompt 00:07:05.389 --> 00:07:08.389 drift myself, honestly. Oh, really? Yeah. I constantly 00:07:08.389 --> 00:07:10.990 want to treat AI like a magic wand instead of 00:07:10.990 --> 00:07:13.819 a junior dev. It's kind of hard to break that 00:07:13.819 --> 00:07:15.620 habit. No, we all do it when a deadline is approaching 00:07:15.620 --> 00:07:18.040 fast. But there is an ultimate safety net for 00:07:18.040 --> 00:07:21.240 this exact problem. It is called the 95 % confidence 00:07:21.240 --> 00:07:24.180 workflow. Yeah. At the start of a massive task, 00:07:24.339 --> 00:07:27.220 you add one line. You literally tell the AI to 00:07:27.220 --> 00:07:29.779 ask you clarifying questions first. It must ask 00:07:29.779 --> 00:07:32.779 questions until it is 95 % confident. Right, 00:07:32.779 --> 00:07:35.060 and it actually stops to ask about weird edge 00:07:35.060 --> 00:07:38.180 cases. It asks about missing database tables 00:07:38.180 --> 00:07:41.199 and unverified API assumptions. You answer the 00:07:41.199 --> 00:07:43.639 questions, and now your mental models are aligned. 00:07:43.939 --> 00:07:46.439 Most bad output comes from confident guessing 00:07:46.439 --> 00:07:50.120 on vague, poorly defined tasks. This workflow 00:07:50.120 --> 00:07:52.920 gives the AI explicit permission to slow down. 00:07:53.199 --> 00:07:55.220 You align once, you build once, and it usually 00:07:55.220 --> 00:07:58.850 works perfectly. Beat. But does spending time 00:07:58.850 --> 00:08:01.290 answering the AI's questions up front slow down 00:08:01.290 --> 00:08:03.529 the actual building process? It actually speeds 00:08:03.529 --> 00:08:06.250 up the total timeline significantly. It cuts 00:08:06.250 --> 00:08:08.410 three or four painful rebuild cycles down to 00:08:08.410 --> 00:08:10.670 just one. Right. A few minutes planning saves 00:08:10.670 --> 00:08:13.290 hours of painful bug fixing. Exactly. It's an 00:08:13.290 --> 00:08:15.569 incredibly high return investment. So the AI 00:08:15.569 --> 00:08:18.060 planned the feature. and it wrote the code. But 00:08:18.060 --> 00:08:20.319 we certainly cannot just blindly trust it. We 00:08:20.319 --> 00:08:23.120 need the AI to rigorously verify its own work. 00:08:23.259 --> 00:08:25.379 You have to add self -checking steps to every 00:08:25.379 --> 00:08:27.779 single workflow. Do not bolt verification on 00:08:27.779 --> 00:08:29.920 at the very end as an afterthought. Bake the 00:08:29.920 --> 00:08:32.019 check step directly into the AI's initial plan, 00:08:32.279 --> 00:08:34.299 tell it to build a payment form, then immediately 00:08:34.299 --> 00:08:37.259 check it. Tell it to add the API route, then 00:08:37.259 --> 00:08:40.179 rigorously test it. You can use powerful visual 00:08:40.179 --> 00:08:43.179 tools for this verification process now. The 00:08:43.179 --> 00:08:45.940 AI can take a screenshot of a locally running 00:08:45.940 --> 00:08:48.720 page. It looks at the image to find layout and 00:08:48.720 --> 00:08:51.840 UI spacing issues. But the Chrome DevTools integration 00:08:51.840 --> 00:08:54.419 is where it gets absolutely crazy. The AI can 00:08:54.419 --> 00:08:56.139 literally open the page and click through it. 00:08:56.360 --> 00:08:58.519 It can fill out forms and submit them like a 00:08:58.519 --> 00:09:01.259 human user. Under the hood, it's actually interacting 00:09:01.259 --> 00:09:04.179 with the document object model. It watches the 00:09:04.179 --> 00:09:06.960 browser console for JavaScript errors as it clicks. 00:09:07.139 --> 00:09:09.500 Right, and it monitors the network tab to ensure 00:09:09.500 --> 00:09:12.480 the API payloads are correct. This moves the 00:09:12.480 --> 00:09:16.200 check from surface level visual matching to structural 00:09:16.200 --> 00:09:19.080 verification. It changes the question from does 00:09:19.080 --> 00:09:22.299 it look right to does it actually work. Once 00:09:22.299 --> 00:09:24.940 you verify the code works, you want to systematize 00:09:24.940 --> 00:09:27.379 things. You need to start building reusable custom 00:09:27.379 --> 00:09:29.740 skills because once you write the same complex 00:09:29.740 --> 00:09:33.039 instructions twice, you should stop. You turn 00:09:33.039 --> 00:09:35.259 those instructions into a permanent reusable 00:09:35.259 --> 00:09:37.840 skill. Skills live in a dedicated hidden folder 00:09:37.840 --> 00:09:40.519 as small markdown files. Each file represents 00:09:40.519 --> 00:09:43.379 a highly specific repeatable workflow for your 00:09:43.379 --> 00:09:46.139 project. You might have a skill file just for 00:09:46.139 --> 00:09:48.759 standard code reviews. You might have one that 00:09:48.759 --> 00:09:51.559 scans the code base for massive technical debt. 00:09:51.879 --> 00:09:54.259 You write the workflow once and you can call 00:09:54.259 --> 00:09:57.299 it anytime. Building custom skills is like stacking 00:09:57.299 --> 00:10:00.529 Lego blocks of data. You build it once and reuse 00:10:00.529 --> 00:10:02.870 it forever. This is where the tool stops feeling 00:10:02.870 --> 00:10:05.769 like a simple chat box. Your repeated manual 00:10:05.769 --> 00:10:09.429 work becomes named, versioned, improvable engineering 00:10:09.429 --> 00:10:12.129 assets. And you commit these skill files directly 00:10:12.129 --> 00:10:14.490 into your Git repository. So when a new developer 00:10:14.490 --> 00:10:17.789 joins, they clone the repository. They immediately 00:10:17.789 --> 00:10:20.929 inherit all of your AI workflows on day one. 00:10:21.269 --> 00:10:23.490 What actually shifts when you transition from 00:10:23.490 --> 00:10:26.190 chatting with an AI to building an actual system? 00:10:26.320 --> 00:10:29.000 It changes how your entire team operates fundamentally. 00:10:29.419 --> 00:10:32.399 Named version skills turn raw chats into improvable 00:10:32.399 --> 00:10:34.539 team assets. Commit the skills file and your 00:10:34.539 --> 00:10:37.299 whole team instantly levels up. Sponsor. Okay, 00:10:37.460 --> 00:10:39.539 so standard tools sometimes hit their absolute 00:10:39.539 --> 00:10:42.559 limits. What happens when you face massive multi 00:10:42.559 --> 00:10:44.879 -part problems at scale? You have to scale your 00:10:44.879 --> 00:10:47.100 workflows horizontally across multiple models. 00:10:47.620 --> 00:10:50.039 You introduce sub -agents for handling parallel, 00:10:50.259 --> 00:10:53.529 highly complex tasks. a subagent, a secondary 00:10:53.529 --> 00:10:56.649 AI session handling a specific task. Your main 00:10:56.649 --> 00:10:59.129 session stays on the incredibly powerful OPUS 00:10:59.129 --> 00:11:02.210 model. But it spawns smaller subagents to do 00:11:02.210 --> 00:11:04.429 the tedious busy work. You can spawn several 00:11:04.429 --> 00:11:07.429 of these subagents all at once dynamically. One 00:11:07.429 --> 00:11:10.529 agent reads through 500 pages of complex Stripe 00:11:10.529 --> 00:11:13.789 API documentation. Another agent scans your entire 00:11:13.789 --> 00:11:16.649 code base for similar architectural routing patterns. 00:11:17.250 --> 00:11:19.629 A third agent starts writing the rough first 00:11:19.629 --> 00:11:21.909 draft of the code. They work completely in parallel 00:11:21.909 --> 00:11:24.009 and then report back to the main agent. They 00:11:24.009 --> 00:11:26.210 provide short, dense summaries of their findings 00:11:26.210 --> 00:11:28.830 to the Opus model. Your main session stays completely 00:11:28.830 --> 00:11:31.590 clean and incredibly light on tokens. You save 00:11:31.590 --> 00:11:33.470 the heavy Opus model for the hardest reasoning 00:11:33.470 --> 00:11:36.539 tasks. You use the cheaper faster Haiku model 00:11:36.539 --> 00:11:39.019 for the reading agents. It is incredibly efficient 00:11:39.019 --> 00:11:42.019 from a cost and time perspective. Whoa! I mean, 00:11:42.120 --> 00:11:44.240 imagine spinning up parallel agents to research 00:11:44.240 --> 00:11:46.000 and test while you just sit back and think. It 00:11:46.000 --> 00:11:48.360 is wild. If we connect this to the bigger picture, 00:11:48.620 --> 00:11:50.779 it's crazy. You are essentially managing a digital 00:11:50.779 --> 00:11:54.340 development team. But there is a very real, very 00:11:54.340 --> 00:11:57.279 dangerous problem here. Parallel sessions will 00:11:57.279 --> 00:12:00.100 absolutely overwrite each other's files if left 00:12:00.100 --> 00:12:02.500 unchecked. Oh, definitely. Think of it like two 00:12:02.500 --> 00:12:05.059 chefs trying to bake different cakes in the exact 00:12:05.059 --> 00:12:07.500 same mixing bowl. If you have two sessions in 00:12:07.500 --> 00:12:10.620 the same folder, they fight. One agent edits 00:12:10.620 --> 00:12:13.220 a core file and the other instantly overwrites 00:12:13.220 --> 00:12:15.419 it. You end up debugging a massive mess that 00:12:15.419 --> 00:12:17.919 nobody actually wrote. You need Git work trees 00:12:17.919 --> 00:12:20.840 to manage this chaos effectively. A Git work 00:12:20.840 --> 00:12:23.139 tree links a directory to a specific code branch. 00:12:23.360 --> 00:12:25.700 Normally you switch branches inside a single 00:12:25.700 --> 00:12:28.299 project folder, but WorkTrees give each parallel 00:12:28.299 --> 00:12:31.100 session its own isolated directory on your hard 00:12:31.100 --> 00:12:33.679 drive. They are in the same repository, but in 00:12:33.679 --> 00:12:35.940 completely separate physical spaces. You can 00:12:35.940 --> 00:12:38.179 run one session building a new feature entirely. 00:12:38.299 --> 00:12:40.320 And you run another session on a stubborn bug 00:12:40.320 --> 00:12:42.580 fix in another directory? They all run at once, 00:12:42.799 --> 00:12:45.600 with absolutely no file conflicts. The AI agents 00:12:45.600 --> 00:12:47.940 are completely blind to each other's experimental 00:12:47.940 --> 00:12:50.840 changes. When a task is fully verified and done, 00:12:51.179 --> 00:12:54.440 you just merge the branch back. For a solo builder, 00:12:55.200 --> 00:12:57.679 this is truly revolutionary software engineering. 00:12:57.960 --> 00:12:59.460 It's kind of like cloning yourself three times 00:12:59.460 --> 00:13:04.019 over. It really is. But how do you definitively 00:13:04.019 --> 00:13:07.279 prevent these multiple AI agents from destroying 00:13:07.279 --> 00:13:09.480 each other's code? You have to isolate their 00:13:09.480 --> 00:13:12.799 environments completely from the start. Get work 00:13:12.799 --> 00:13:14.840 trees, keep them in separate spaces until you're 00:13:14.840 --> 00:13:17.820 ready to merge. Git work trees keep every agent 00:13:17.820 --> 00:13:20.500 safely inside its own sandbox. Right. They can 00:13:20.500 --> 00:13:22.919 break things in isolation without ruining production. 00:13:23.139 --> 00:13:25.679 We have scaled wide, so now let's scale deep. 00:13:25.960 --> 00:13:29.539 How do we handle impossibly hard bugs and long 00:13:29.539 --> 00:13:32.179 -running, tedious tasks? You start using hooks 00:13:32.179 --> 00:13:35.019 and loops for deep continuous automation. Once 00:13:35.019 --> 00:13:36.519 you have parallel sessions running, you have 00:13:36.519 --> 00:13:38.799 to stop babysitting the terminal. Hooks trigger 00:13:38.799 --> 00:13:41.019 a notification when a specific event finally 00:13:41.019 --> 00:13:43.440 happens. You can get a desktop ping when a massive 00:13:43.440 --> 00:13:46.360 test suite finishes. Then there is the loop command, 00:13:46.519 --> 00:13:48.860 which is basically an infinite worker. It lets 00:13:48.860 --> 00:13:51.379 a session rerun a prompt on a continuous schedule. 00:13:51.559 --> 00:13:53.259 You can have it check your server deployment 00:13:53.259 --> 00:13:55.580 status automatically every five minutes. The 00:13:55.580 --> 00:13:57.980 best part is the session actually keeps its memory 00:13:57.980 --> 00:14:01.460 intact. It maintains context across those continuous 00:14:01.460 --> 00:14:03.960 loops for up to three days. It remembers what 00:14:03.960 --> 00:14:06.899 failed 10 minutes ago and adapts its next check. 00:14:07.259 --> 00:14:10.080 But this raises an important question about resource 00:14:10.080 --> 00:14:14.379 allocation. What happens when standard fast reasoning 00:14:14.379 --> 00:14:17.320 just isn't enough to solve the bug? Here's where 00:14:17.320 --> 00:14:19.320 it gets really interesting. We bring in the heavy 00:14:19.320 --> 00:14:22.700 hitter. It is a feature called UltraThink. UltraThink 00:14:22.700 --> 00:14:26.340 tells the AI to use its absolute maximum thinking 00:14:26.340 --> 00:14:30.799 budget. It uses up to 32 ,000 tokens just for 00:14:30.799 --> 00:14:34.090 deep internal reasoning. The AI essentially argues 00:14:34.090 --> 00:14:36.490 with itself before typing a single word of code. 00:14:36.730 --> 00:14:39.289 Under the hood, it's exploring a path, realizing 00:14:39.289 --> 00:14:42.090 it's wrong, and backtracking. It is the fundamental 00:14:42.090 --> 00:14:44.690 difference between a shallow answer and a profound 00:14:44.690 --> 00:14:47.529 architecture choice. You use it for deep debugging 00:14:47.529 --> 00:14:49.610 on problems you've already failed to solve. You 00:14:49.610 --> 00:14:52.649 use it for massive, risky refactors where one 00:14:52.649 --> 00:14:55.309 wrong call breaks the entire application. But 00:14:55.309 --> 00:14:57.490 why shouldn't we just use UltraThink for every 00:14:57.490 --> 00:15:00.000 single prompt to get perfect code? Because it 00:15:00.000 --> 00:15:03.159 is incredibly slow and highly expensive to run, 00:15:03.600 --> 00:15:06.899 routine work simply does not need a massive reasoning 00:15:06.899 --> 00:15:09.820 budget to succeed. Save the heavy ultra -think 00:15:09.820 --> 00:15:12.220 budget only for the hardest architectural problems. 00:15:12.340 --> 00:15:15.379 Yeah, if you are just centering a div, you don't 00:15:15.379 --> 00:15:17.539 need a supercomputer pondering the universe. 00:15:17.580 --> 00:15:21.000 Exactly. Beat. But seriously, we suggest picking 00:15:21.000 --> 00:15:23.059 just three of these habits to start with today. 00:15:23.230 --> 00:15:27.509 Try the init command to build a tight ClaudeE 00:15:27.509 --> 00:15:31.129 .md file. Use plan mode on absolutely every new 00:15:31.129 --> 00:15:33.769 task you tackle. And bake a self -check step 00:15:33.769 --> 00:15:36.190 into every to -do list you write. So what does 00:15:36.190 --> 00:15:38.509 this all mean for us? Let's synthesize the main 00:15:38.509 --> 00:15:41.610 theme of this entire playbook. Modern AI heavily 00:15:41.610 --> 00:15:44.230 rewards the person who actively designs the workflow. 00:15:44.309 --> 00:15:46.649 It does not reward the person writing the cleverest 00:15:46.649 --> 00:15:48.649 single prompt anymore. The structural system 00:15:48.649 --> 00:15:50.909 you build matters exponentially more than the 00:15:50.909 --> 00:15:53.590 initial command you type. Two sec silence. Think 00:15:53.590 --> 00:15:56.230 about this for a moment. An AI can plan its own 00:15:56.230 --> 00:15:58.669 execution completely from scratch. It can visually 00:15:58.669 --> 00:16:01.309 check its own UI with developer tools. It can 00:16:01.309 --> 00:16:03.909 loop its own monitoring workflows autonomously 00:16:03.909 --> 00:16:08.019 for days. Beat. What does the future role of 00:16:08.019 --> 00:16:10.259 a human developer actually look like? Are we 00:16:10.259 --> 00:16:12.480 moving away from writing code line by line? Are 00:16:12.480 --> 00:16:14.720 we simply orchestrating a team of digital minds 00:16:14.720 --> 00:16:17.639 to build our visions? That is a profound question 00:16:17.639 --> 00:16:19.720 to walk away with today. Thank you for joining 00:16:19.720 --> 00:16:22.000 us on this deep dive. We highly encourage you 00:16:22.000 --> 00:16:24.240 to test out the init command on your very next 00:16:24.240 --> 00:16:25.820 project, OTRO music.