WEBVTT 00:00:00.000 --> 00:00:33.340 If you've been building with Cloud Code, then at some point, you must have seen screenshots or videos just like these on LinkedIn or x. Someone flexing that they have five, ten, 50, hundreds of Cloud Code terminal sessions running at the exact same time. But here's what they don't show you. When you zoom in on those terminals, you'll see that a bunch of them are asking very basic questions that can be answered in under thirty seconds. And what about the ones that are apparently doing the real work? Well, many of those sessions have agents colliding with each other, stepping on each other's toes, and most importantly, 00:00:33.500 --> 00:00:48.585 building features that are so brittle that they'll break the moment that they're touched. Now the fantasy of running hundreds of terminals is beautiful, but if you don't understand when it makes sense to run something in parallel versus when it creates chaos, then you're gonna be lighting money on fire and just calling it productivity. 00:00:48.665 --> 00:02:02.105 So in this video, I'm gonna walk you through three different scenarios where running tasks in parallel in Cloud Code makes sense. And the one question that you need to ask before you start up your next extra session. So I won't just walk through theory. I'll actually show you the terminals that I've set up before this video to give you a good mental model and a visual model of when it makes sense to use the three different scenarios that I'll show you. And one thing I want to emphasize is just because I'm showing you these three doesn't mean that it's only these three methods that you can employ. There are many ways that you can make this your own, but these are three mental models that to me, especially if I was just starting out, would make things a lot less noisy, a lot less hype based, and a lot more focused on the task at hand. So once again, the fantasy we wanted to spell is that adding eight terminals, 800 terminals will make you eight to 800 times faster. Because even in the world of development, just because you add double the developers doesn't mean that you half the time of development itself. Every single build or every single set of tasks has some nuance as to one, whether or not it's even eligible to run-in parallel, let alone when what order it should execute if it is eligible. So the three scenarios are the following, and we'll go through each one in-depth and, again, show you an example hands on in the terminal. So scenario one is a true parallel, 00:02:02.265 --> 00:02:04.665 and this really applies to nontechnical 00:02:04.665 --> 00:02:18.810 tasks. Meaning, you're not vibe coding some front end. You have a series of tasks that all are independent, that don't need to depend on another, that you can truly run-in parallel. So you can realize that fantasy of having five, ten, even 15 terminals 00:02:18.810 --> 00:02:43.560 and nothing bad will happen. You will be more productive assuming one, you know what you're trying to do. Two, you know exactly what intermediary steps you need to accomplish to get there. And three, you have the proper prompts in place for all of those tasks where you don't need to babysit them. Now scenario two is usually where I work, where things are phased, where you have some form of foundation, where once that foundation is laid, you have auxiliary tasks that you can execute, 00:02:43.800 --> 00:02:49.960 some of which can be actually independent. Meaning, you can focus one terminal on tasks that need some more dependencies 00:02:49.960 --> 00:03:08.985 and others that can run independently and mutually exclusive from the rest of the build. And when it comes to scenario three, this is also pretty practical where maybe you have a plan file. We call it a plan MD file where you have things that are in phases, and they are in phases because each phase depends on the existence of whatever the output is of the phase prior. 00:03:09.065 --> 00:03:21.950 And this is where it makes sense to execute one terminal after the other, and you're taking advantage of the fact that you're not clogging one terminal or two terminals with tons of context with different libraries and structures that overlap. 00:03:22.185 --> 00:03:29.305 So So let's take scenario one, which is the easiest to wrap your head around and again realizes this fantasy of using multiple terminals. 00:03:29.545 --> 00:03:31.545 So this is called true parallel. 00:03:31.865 --> 00:03:48.140 In this case, let's say you have a overall task of I need to launch my AI course. Let's assume you are not a YouTuber yourself, meaning you need some form of distribution. So you might create all of these tasks. One of these tasks could be research competitors. Another one could be draft emails, find influencers, 00:03:48.815 --> 00:03:51.455 create lead magnets, find podcasts, 00:03:51.455 --> 00:04:12.270 draft tweets or posts on x, research PR angles, and create a landing page copy. Now outside of the landing page copy itself, which could be could be dependent on the outputs of some of the others, most of these can be run-in parallel to accomplish the overall goal. So you could theoretically execute task number one here, which is find 10 competitors, 00:04:12.430 --> 00:04:17.470 which wouldn't step on the toes of task number two, which is email copy email copywriting, 00:04:17.745 --> 00:04:23.905 and task number three, finding 20 influencers to help distribute an AI course could be all independent. 00:04:24.065 --> 00:04:43.690 Now could there be nuances where it might be helpful for task three to be aware of task one? It could be. It depends on the situation, which is why I want you to be a lot more critical when you think about running things in parallel because you lose nuance. You can lose context, especially if you're more of a beginner and you don't know how to do things like create GitHub issues or create very sophisticated plans 00:04:43.690 --> 00:04:56.255 or run agents and sub agents that help pass context between different parallel sessions where you have the important part that you need to keep advancing everything forward with the full context that each of these sessions also require. 00:04:56.575 --> 00:05:11.030 So again, instead of yapping about it, here's one example of a terminal, not with a 100 sessions, not with six, but four. It's easier on the eyes and easier on my soul as it show it to you. You can have the first one say research the top 10 AI course competitors, 00:05:11.190 --> 00:05:18.230 list their pricing, unique angles, and target audience, and then output to, let's say, research and call it competitors dot markdown file. 00:05:18.735 --> 00:05:26.255 And then number two could be draft a five email welcome sequence for new subscribers to my AI newsletter. Maybe that's one way you wanna get distribution. 00:05:26.415 --> 00:05:28.575 Save to welcomes.md. 00:05:28.655 --> 00:05:39.450 And then same idea here. Find 20 tech influencers on YouTube with a 100 to a 100 k subscribers who review online courses. And the last one could be write landing page copy with the headline, 00:05:39.610 --> 00:06:27.005 sub headline, three bullet points, SEO optimized, whatever you want, and then go from there. So you can see this is practical, to the point, and bite sized. So to me, is not a red flag. This is totally doable and especially if you're trying to really realize the benefits of using a Claude code versus a chat GBT or Claudia on the front end, this is an amazing gateway drug to allow you to do that. Once you complete phase one and you have the foundation of the application or the task that you're building, then you're eligible to go to phase two where you can then spin up all of these parallel sessions. And this part makes a lot more sense if you have an idea of what features are the most likely to be truly independent. Now let's say that you're looking at this and you're nontechnical and you have no clue or instinct of whether or not feature a b c or d are actually independent. 00:06:27.325 --> 00:06:37.950 One cheat code that you could do is once you build the foundation, you can physically ask Claude code, look at the rest of our plan here and tell me what you think can be built independently 00:06:37.950 --> 00:06:47.905 in a way where if it had no context of the other tasks that I could run it in a separate session and it could have no understanding of what's happening in parallel throughout. This is not foolproof, 00:06:47.905 --> 00:07:12.315 especially if you wanna keep developing an idea that's not fully developed in your head yet. But if you have a full understanding end to end of what you're trying to build, Claude code could give you not only the tools and the hint of what could run-in parallel, but you could ask it to run a meta prompt for you to tell you what to tell this new session to build in parallel in a way that will not step on the toes of the other agents. So this is admittedly a bit more convoluted, 00:07:12.315 --> 00:07:22.075 but it's an instinct that you can build over time with the help of Cloud Code. And in the phase parallel approach, you might get to phase three, phase four, phase five, where there could be intermingling, 00:07:22.155 --> 00:07:33.590 some dependencies, But maybe for phase two, you can run everything in parallel. So if you were putting this on a whiteboard, here's a sample mental model, and then I'll show you an actual sample. So let's say you have a database schema, 00:07:33.830 --> 00:07:40.205 and everything revolves around that database existing. So the ability to create a profile, the ability to pay, 00:07:40.365 --> 00:07:45.085 all of that revolves around being able to log that somewhere. So this has to be first. 00:07:45.485 --> 00:08:09.895 So if you want to create an authentication system, well, you need the database. If you need a user dashboard, well, you would have had to find a way to log them in, right, and then store it in the database itself. If you want an admin panel, then you need one and two, both of these together because you need authentication and the database. So mapping this out, and again, you don't have to act like you're some coder that you're not if you're nontechnical. 00:08:09.975 --> 00:08:26.570 You can ask AI to help you better understand the order of operations. And once you do that, one, you'll have a much richer plan. Two, you will grow yourself over time to think in design thinking, which in my opinion is the most important skill in the next twelve months. It's not gonna be coding. 00:08:26.730 --> 00:08:34.855 Understanding architecture and coding gives you an unfair advantage if you supercharge it. But if you can understand design principles, system architecture, 00:08:34.855 --> 00:08:54.230 understanding the prerequisites to going from a to b, you'll go pretty far. So if we take these exact dependencies, you can go and map them like this, where maybe the database schema and auth system take the majority of the phase one. And then phase two is where you do things like the user dashboard, the admin panel, the file upload, payment notifications. 00:08:54.230 --> 00:09:03.825 Although there could be some intermingling where you need the user dashboard to be set up for payment to be executed. Really depends on the scope of the app, the customer journey, etcetera. 00:09:03.985 --> 00:09:26.630 But then you get to phase three, which is analytics. And how can you have the analytics about what's happening without all the building blocks in between? So that's the way I'd push you to think when you are building things and you take this phased approach. And just to finish that thought, this is what the multiple terminals might look like for this project. So number one would be set up database schema for client portal, create table for users, projects, files, and invoices. 00:09:26.870 --> 00:09:36.395 Ideally, you'd wanna tell it where you wanna host this database. Do you want it to be SQL lite on your actual computer? Do you want it to be super based? Do you want it to be convex? Do you want it to be on AWS? 00:09:36.715 --> 00:09:51.380 You have to specify that as well. This would be more so of a starter prompt, and it's your job to fill in the blanks. So if you are adamant on running things in parallel, you know that each one has enough granularity that it can go and fully complete that subtask, 00:09:51.460 --> 00:09:52.580 not half baked. 00:09:52.820 --> 00:10:12.095 The second one, like I said, is build the authentication system with login, sign up, and password reset. Use database schema from here. So you can see dependency right there. Build the user dashboard showing the project list and status, auth and database already set up. So in this case, can tell this session that both of these have completed 00:10:12.310 --> 00:10:38.025 and it's ready to build on top of the foundation that's already been put together. And last but not least, you could say build the admin panel for client management, auth, and database already set up. Now phase three, I call the really race where it's literally a baton that's being passed from one session to the next. And the real value add here is you're self aware that there are different phases. And as each phase completes, you kind of mark the end of that session. So even if you compact the conversation, 00:10:38.505 --> 00:10:41.705 it's on the same context that it was throughout the entire conversation. 00:10:42.400 --> 00:10:48.960 One mistake that I see quite a bit is people will dedicate one session towards building two or three quarters of the whole app, 00:10:49.360 --> 00:11:01.385 and they auto compact multiple times not realizing that every single time you auto compact, you don't really know what Claude code has prioritized or not prioritized to include in that next session. 00:11:01.545 --> 00:11:20.250 So you keep running the next session with a disadvantage, and in a way you're confusing it because maybe there's bits and parts of the nuance that it needs to do what it needs to do. So this helps you have this phased approach where as each session completes, that is the end of that session. So each session is mutually exclusive at least in context. 00:11:20.645 --> 00:11:24.245 So even if the auto compact is not relaying all the information, 00:11:24.565 --> 00:11:31.445 overall, it has the eighty twenty it needs to keep going. Now this also naturally solves the issue of the context window where, 00:11:31.605 --> 00:11:35.990 hopefully, we'll get to a point where we have half a million, a 5,000,000 00:11:35.990 --> 00:11:52.565 context window. But for now, if you have a very large and bloated CloudMD file, if you have this tendency to lazily prompt at some point and then lead Cloud code down a wild goose chase to read and reread the same files that might not even be relevant to your request, 00:11:52.805 --> 00:12:01.125 this will fill up really quickly. So this is one more technique that might help alleviate this burden. And the core idea here is you have some form of PlanMD, 00:12:01.125 --> 00:12:05.250 and I love doing PlanMDs for all kinds of projects where TLDR, 00:12:05.410 --> 00:12:07.650 you have Claude not just go into plan mode, 00:12:07.810 --> 00:12:12.850 but document its entire plan, number one. And then number two, create check boxes 00:12:13.010 --> 00:12:22.525 across every task for that phase of that plan, and then you tell it, especially to tell it to remember in Claude MD, which is the brain command center of Claude. 00:12:22.845 --> 00:12:24.765 As we go through different phases, 00:12:25.005 --> 00:12:29.405 check off everything you've completed because this gives you multiple layers of insurance. 00:12:29.645 --> 00:13:04.660 Let's say you dedicated six terminals to six phases, and what happened is you underestimated how big phase one was gonna be compared to phase two, and you kind of actually need two terminal sessions full end to end to execute phase two. Having the plan m d would allow Cloudco to document the 80% that finished, and then you can resume and baton pass the rest of the plan to the next session. So then you can get into a groove, especially if you have your vibe coding playlist on where you go through terminal a, you run local host to see what the app looks like or whatever the service is on your computer, 00:13:04.900 --> 00:13:14.500 then you close it or you keep it open, then you have terminal b and so on. And one key extra tip here is I add one extra session, so one bonus session. 00:13:15.015 --> 00:13:26.535 This bonus session is actually where I completed the plan and created the plan m d, and I'll keep that one open despite executing the different phases in other windows. And I'll tell you the reason why. 00:13:26.855 --> 00:13:37.180 Because as you think you're completing phase one, two, three, and four, you can always check-in with this virgin eyes context window in session that's only obsessed with the plan and say, 00:13:37.500 --> 00:14:18.935 can you take a peek at phase three? We just completed it elsewhere. Can you just check the code base and tell me, have we finished everything that we need to do? And sometimes it might be able to take a look at that code from terminal number four or five and say we actually didn't complete this and this. It missed that. So now you can start to be proactive and on the offense instead of on the defense. I'm always hiding behind a plan. So the core benefits is that you don't lose momentum, you keep each phase with a 100% fresh context, you don't have Claude forgetting every couple times what you said a few hours ago, especially if you're addicted to doing compacting of conversations, and then you're one step closer to finishing things a lot faster and a lot more elegantly. 00:14:19.175 --> 00:14:47.815 So in practice, this could look like this where you have a plan and everything here revolves around said plan. So if we take a look at the file, it's just meant to be an example. Typically, in all of my plan MDs, I'll have some form of overview. This overview should explain the inspiration behind the app, where you're trying to go, what problem you're trying to solve, big picture. And it's actually very helpful to feed that big picture because when you go into blank stateless sessions, what the word stateless means is as you go to each session, 00:14:48.135 --> 00:14:55.575 outside of the artifacts that you create and the CloudMD that you maintain for memory and any other memory stuff that you have that's auxiliary, 00:14:55.735 --> 00:15:36.420 it's hard to almost contextualize the Cloud code what the big picture is. If you can keep some reference of the big picture in this plan MD, it'll be that much more helpful. And this is where you have all the different phases with the associated tasks, and you can see we have the check boxes right here. So the instruction you'd give to store in CloudMD every single time you accomplish something is you would check this off, and this will allow you to always resume where you left off and not have to worry about documenting the journey. And when it comes to the prompts themselves, you could have something that says read plan dot m d, execute phase one, database and auth, check off tasks when done, and add any architecture decisions to the decision log. 00:15:36.580 --> 00:15:52.435 So one more thing you could do is create another markdown file that walks through decisions that happen as a result of you doing x y z in phase one. So there's this quote around everyone has a plan until they get punched in the face. Well, if you're nontechnical, especially, 00:15:52.915 --> 00:16:35.730 you can easily get punched in the face if you don't actually fully bake through what you're trying to build and what you need to build it. So the decisions log could act as one more artifact that can inform the next subsequent sessions on what decisions you made that kind of strayed away from the original plan. And again, this just keeps injecting helpful context into the next session in a way that keeps things flowing and adds more nuance to Claude Coates thinking so it doesn't go down these cookie cutter ADHD narrow tunneled routes. And that's pretty much it. So hopefully this gives more color and a reference point as to when it might make sense to use and not to use parallel sessions and some of the best ways to use them. And again, what I showed you here is not comprehensive of every single permutation. 00:16:36.135 --> 00:17:33.464 There are thousands of ways to solve the same problem especially when you use Cloud Code. And whether or not you use agents or sub agents or hooks or all kinds of things that you could do in Cloud Code, this is just meant to give you the foundation to execute your vision in whatever phases you choose. And if you want all the artifacts and the prompts that I showed you in this video along with a mini guide that I put together to help you wrap your head around a few different scenarios, I'll make that available to you in the second link in the description below. If you enjoy the way I break things down and try to build minus the hype, then check out the first link in the description below for my early AI adopters community. We're continually releasing exclusive builds where I walk through a to zed, how I design the project, how I think through the project, and most importantly, all the principles in between, and we're coming out with some brand new foundational content as well since many things have changed. And for the rest of you watching, if you could leave a like and a comment on the video, I'd super appreciate it. Helps the video, helps the channel, and I'll see you in the next one.