§ 01 · The Hook
The bait, then the rug-pull.
Everyone has seen the screenshot: 50 Claude Code terminals running at once, the poster implying they are 50x more productive. Mark Kashef opens by naming the flex directly then spending 17 minutes proving why it usually just means 50x more chaos.
What the video promised.
stated at 00:48 "I am gonna walk you through three different scenarios where running tasks in parallel in Claude Code makes sense. And the one question that you need to ask before you start up your next extra session." delivered at 16:16
Where the time goes.
00:00 – 00:48
01 · The parallel terminal fantasy
Opens with the LinkedIn/X flex of hundreds of terminals, then reveals the reality: agents colliding, brittle features, money on fire.
00:48 – 02:02
02 · Why more terminals does not mean more speed
Software dev analogy: doubling devs does not halve time. Introduces the One Question.
02:02 – 03:29
03 · Overview: The 3 Scenarios
Whiteboard slide shows all three scenarios side by side with the one-question decision rule.
03:29 – 05:00
04 · Scenario 1: True Parallel
Non-technical, fully independent tasks. All fire simultaneously. Time = longest task.
05:00 – 06:27
05 · True Parallel terminal demo
Live 4-terminal demo: competitors research, email sequence, influencer list, landing page copy all running at once.
06:27 – 09:15
06 · Scenario 2: Phased Parallel
Technical tasks with dependencies. Build DB schema + auth first (sequential), then parallelize Phase 2 features. ~2x faster.
09:15 – 10:40
07 · Phased Parallel dependency analysis
Whiteboard shows Claude verdict: tasks 1-2 must be sequential, tasks 3-7 can parallelize after 1-2 done.
10:40 – 12:00
08 · The execution flow diagram
Phase 1 (35 min sequential) then Phase 2 (30 min parallel) then Phase 3. Total 95 min vs 180 min all-sequential.
10:20 – 12:20
09 · Scenario 3: The Relay Race
Multiple terminals open but NOT parallel. Each handles one phase then closes. PLAN.md is the baton.
11:20 – 12:42
10 · Auto-compact danger
Each auto-compact = unknown context loss. One giant session compounds the debt.
12:01 – 14:19
11 · PLAN.md as the brain
Structure: overview, phased checklist, decision log. Terminals start by reading PLAN.md to bridge stateless sessions.
13:13 – 14:38
12 · The bonus session trick
One extra terminal kept open throughout all phases as virgin-eyes plan auditor.
14:19 – 16:16
13 · Relay Race terminal demo
Full PLAN.md with overview, phases, checkboxes. Prompt shown: read plan.md, execute phase 1, check off tasks.
16:16 – 17:34
14 · Wrap-up and resources
Brief recap, Gumroad resource plug, Skool community CTA.
Visual structure at a glance.
Named ideas worth stealing.
01:50
concept
The One Question
Before any extra terminal: Does Task B need Task A output? NO = True Parallel. DEPENDS = Phased Parallel. LONG SESSION = Relay Race.
Steal for decision gate before every Claude Code multi-agent session
03:29
model
Scenario 1: True Parallel
- All tasks independent
- Non-technical tasks preferred
- Time equals longest task
- No babysitting required
Fire all terminals simultaneously when zero cross-dependencies exist.
Steal for content launch tasks, research sprints, any batch of independent deliverables
06:27
model
Scenario 2: Phased Parallel
- Phase 1: sequential foundation (DB schema, auth)
- Phase 2: parallel features once foundation exists
- Phase 3: final assembly
Sequential foundation unlocks parallel feature work. ~2x faster than all-sequential.
Steal for any technical build with a shared data layer
10:20
model
Scenario 3: The Relay Race
- Phase 1 terminal closes when done
- PLAN.md is the baton
- Terminal B reads codebase + PLAN.md
- Fresh 100% context per phase
Multiple terminals used sequentially not in parallel. PLAN.md carries state. Solves auto-compact context loss.
Steal for long multi-day builds where context debt is the main risk
12:01
list
PLAN.md Structure
- Overview (inspiration, problem, big picture)
- Phases with checkboxes per task
- Decision log (architecture choices that strayed from plan)
Document that bridges stateless Claude Code sessions. Every terminal starts by reading it.
Steal for every project over 2 hours of build time
13:13
concept
The Bonus Session
One extra terminal kept open across all phases, dedicated to the plan only. Used as virgin-eyes QA to catch missed tasks before the next phase starts.
Steal for catching missed tasks before starting the next phase
Lines you could clip.
00:48
"You are gonna be lighting money on fire and just calling it productivity."
10:49
"Every single time you auto compact, you do not really know what Claude Code has prioritized or not prioritized to include in that next session."
13:18
"Terminal B does not know what Terminal A did. But Terminal B reads the codebase and the PLAN.md — it has everything."
08:26
"Design thinking is the most important skill in the next twelve months. It is not gonna be coding."
14:18
"I am always hiding behind a plan."
How they spent the runtime.
Hook length48s
Info densityhigh
Filler8%
Things they pointed at.
How they asked for the click.
16:16
product
"If you want all the artifacts and the prompts that I showed you in this video along with a mini guide I will make that available to you in the second link in the description below."
Soft dual-CTA: paid Gumroad resource first, then community. No urgency, no pop-ups, framed as bonus depth.
Word for word.
HOOK opening / re-engagementCTA the pitch metaphor analogy
00:00HOOKIf 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:33HOOKbuilding 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 . 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,
02:02and this really applies to nontechnical 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 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,
02:43some of which can be actually independent. Meaning, you can focus one terminal on tasks that need some more dependencies 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.
03:09And 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. 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.
03:29So this is called true parallel. 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, create lead magnets, find podcasts,
03:51draft 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,
04:12which wouldn't step on the toes of task number two, which is email copy email copywriting, and task number three, finding 20 influencers to help distribute an AI course could be all independent. 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
04:43or 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. 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,
05:11list their pricing, unique angles, and target audience, and then output to, let's say, research and call it competitors dot markdown file. 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. Save to welcomes.md. 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,
05:39sub 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.
06:27One 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 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,
06:47especially 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,
07:12but 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, 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,
07:33and everything revolves around that database existing. So the ability to create a profile, the ability to pay, all of that revolves around being able to log that somewhere. So this has to be first. 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.
08:09You 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. Understanding architecture and coding gives you an unfair advantage if you supercharge it. But if you can understand design principles, system architecture,
08:34understanding 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.
08:54Although 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. 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.
09:26Ideally, 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? 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,
09:51not half baked. 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
10:12and 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,
10:38it's on the same context that it was throughout the entire conversation. One mistake that I see quite a bit is people will dedicate one session towards building two or three quarters of the whole app, 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.
11:01So 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.
11:20So even if the auto compact is not relaying all the information, overall, it has the eighty twenty it needs to keep going. Now this also naturally solves the issue of the context window where, hopefully, we'll get to a point where we have half a million, a 5,000,000 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,
11:52this 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, and I love doing PlanMDs for all kinds of projects where TLDR, you have Claude not just go into plan mode, but document its entire plan, number one. And then number two, create check boxes
12:13across 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. As we go through different phases, check off everything you've completed because this gives you multiple layers of insurance. 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,
13:04then 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. 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.
13:26Because 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, 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.
14:19So 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,
14:48outside 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, 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.
15:36CTASo 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, 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.
16:36CTAThere 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.
— full transcript
§ 05 · For Joe
Steal the decision tree.
Claude Code parallel sessions playbook
The One Question — does Task B need Task A output? — is the entire framework in a single gate.
- Use True Parallel only for content or research sprints where every task is genuinely independent.
- For technical builds, lay the foundation (DB + auth) in one sequential terminal before parallelizing anything.
- Write PLAN.md first, update checkboxes throughout, reference it in every new terminal opening prompt.
- Keep one bonus terminal open as a plan guardian for virgin-eyes phase reviews.
- Never let one session run through multiple auto-compacts on the same feature area — treat each phase as its own context budget.
- Ask Claude Code itself what can be parallelized: look at the rest of our plan and tell me what can be built independently in a separate session.
§ 05 · For You
How to use multiple AI agents without creating chaos.
For builders using Claude Code
Before opening a second terminal, ask one question: does this task need anything the other task will produce?
- If no: fire both simultaneously — you finish in the time of the longest task.
- If yes: finish the dependency first, then parallelize what remains.
- If you are in a long build: close the terminal when a phase is done, open a fresh one, point it at your PLAN.md.
- PLAN.md is the memory layer that turns stateless Claude sessions into a continuous build — keep it updated with checkboxes and architecture decisions.
- Auto-compact quietly degrades context quality. One fresh terminal per phase is the fix.
