My Multi-Agent Claude Code Setup (steal my workflows!)

Running multiple Cloud Code agents at the same time is the single biggest productivity unlock in AI coding. And that's not just my opinion. It's also a direct quote from the creator Cloud Code, Boris Cherny, who calls it the top tip from the Cloud Code team. And the productivity gains are real. Building with multiple Cloud Code agents has allowed me to ship new products and build useful tools for my business in record time. Things like research agents, a live questions app for my courses, and tools for live teaching. But making the leap from using one to many Cloud Code agents requires more than just opening multiple tabs. You actually need a system. And I've made a lot of mistakes along the way to getting mine dialed in to where it is today. So in this video, I'm going to save you months of pain by showing you my complete system for building productively with multiple Cloud Code agents. I've broken it down into three phases, prepare, build, and ship. And we're going to do this with a real project. I'll take you through the whole workflow as I build three new features in an infographic maker app. So let's get into phase one of building with multiple cloud code agents, and that's prepare. I want to give you a quick overview of the app that we're going to be working on. It's an infographic creator. So it takes in a transcript from one of my YouTube videos. So I can select a transcript that is one of the YouTube videos that I've uploaded. I'm going to pick one. And then you can pick a particular style of infographic. and a topic that you want to create. And then the output of the app is going to be an infographic in the style that you've chosen about the topic that you want. So in this case, it's planning and plan mode based on the content of the transcript that you selected. This is a gallery for the app. This is the kinds of infographics that are being generated. And some of the things we're going to work on in this video is creating new styles of infographics. So you can see here, there's only a few styles. So we're going to create new. styles of infographics. And some of the other features that we're going to create are things like the ability to select multiple transcripts, as well as to upload a transcript that's not in this list and create infographics from it. So with that in mind, let's get into the system. Okay, so step one is prepare. And the goal in the preparation step is to prepare both the work that we want to do. In this case, we're going to use GitHub issues and set up cloud code correctly. so that we can easily run multiple agents in parallel. Now to organize issues, I'm going to be using GitHub issues. It's free. It comes with every GitHub repo that you create in the GitHub platform. But you can also easily use things like linear, JIRA, or other task tracking or project management tools that you or your company uses for this. But in this video, we're going to use GitHub issues. Okay, so we're now in GitHub issues. You can see. This is the name of the project, AC Infographic Maker. I start by defining the tasks that I want to work on in parallel and creating GitHub issues for them. So you can see here, I'm in the issues tab for the projects, project that we're working on. And if you're unfamiliar with issues, an issue is just any unit of work for your project. So it could be things like new features. It could be things like bug fixes. Could also be things like enhancements to existing features. Any individual thing that you want to work on. for your project, I recommend creating an issue for it. Now in general, it's good to break down large tasks into smaller chunks of work. So I always create issues to help organize my project and manage the work that needs to get done. Now for this particular project, I've already created the tasks that we're going to work on in parallel. They are issue number 26. So this is going to be adding new infographic styles as we discussed in the app overview. I've also got issue number 44, which is selecting multiple transcripts as input for an infographic. And I've also got issue number 36, which is to upload transcripts to generate infographics from. Now, you'll notice that each of these issues follow the same format and the same structure. So we've got things like description. We've got things like acceptance criteria. And this is standard across my issues. This is how I like to create GitHub issues. They all follow the same format. And as you can see here, again, description and scope. and acceptance criteria. This actually makes it a lot easier to get consistent results with cloud code and it also ensures that the feature that you want to implement is actually implemented in the way that you want it to be done. Now a pro tip to easily create issues is that I use my create issue skill which is a custom skill that I've created that helps me get that wonderful structure and custom format that I use for GitHub issues. So the way this skill works is that it takes in a doc or a feature description and it creates an issue for it according to a custom template that I've defined. And this helps me standardize things like you saw things like description, acceptance criteria, how to test the feature, etc. So I recommend creating a custom skill to automate issue creation if it's something you're going to be doing frequently. Now, another key thing when you're picking issues is to pick issues that don't touch the same external systems. We'll see this in the common mistakes section later in the video, but I pick issues that are mostly application or business logic changes. They don't require drastic changes to things like database schema or touch the same external components. We're going to see this more later in the video, but this is something to keep in mind when you're selecting the issues that you want to work on in parallel. By the way, if you're curious about planning, check out my other video, How I Start Every Cloud Code Project. for an in-depth look at the planning process. I also cover spec-driven development and systems for building projects with Cloud Code in my AI coding accelerator, both of which you can find in the video description. Now that we have the issues created, it's time to set up Cloud Code to work on the issues in parallel. Now, the easiest way to do this is just to have multiple tabs open in your terminal and have a Cloud session running in each one of those. This is what I'm going to do for this video. So I'm using a terminal called Ghosty, and what we're going to do is just create two more tabs so that we can have three free tabs in order to run our three parallel cloud code sessions that are going to build our three features at the same time that we want to achieve in this video. Now you can also use the split panes feature and have all your sessions running in one place. You might have seen this in my previous videos, so you can try that as well. But for simplicity, I'm going to pick multiple tabs because Ghosty actually notifies me when one of them needs input. Another reason to stick with multiple tabs is because this makes it easy to use the new agent view feature in order to manage all parallel agents in one place. We're going to see more about that in the build step very soon. But first, there's still one big question we haven't answered. How do we make sure that the agents don't get in each other's way? You see, if we just start multiple cloud code sessions right now, there's a chance that they will override each other's work. Just like when you have multiple people editing a Google Doc at the same time. Now, Claude A might make a change to a certain part of the app, in this case, adding an invite feature to the menu bar, and Claude B might make a change to that same part of the app. In this case, it wants to add an export report feature and show up in that menu bar. But what we don't want is when Claude A makes a change for Claude B just to overwrite that change. That defeats the whole purpose of working on multiple features at the same time and having Claude's work in parallel. So, How do we ensure that each Claude can work independently and not get in each other's way? The answer is Git Worktrees, and more specifically, giving each Claude code agent its own WorkTree to work in. So what are Git Worktrees? Git Worktrees are separate, isolated copies of your project. Each WorkTree gets its own folder on your machine, its own copy of project files. So as you can see here, every WorkTree has its own copy of, in this case, the code and docs. and its own branch in Git. Now by giving each Cloud Code agent its own work tree, it enables them to work in isolation because they can make changes as if the other Cloud agents didn't exist because they only see their branch and make changes to their copy of the files. So the next step is to create multiple work trees, one for each feature and agent, and then later on we'll learn how to merge these results back into the main branch of the app. So look out for that in the ship section later in the video. So we're back in the terminal and what I'm going to do is create a work tree for each of the features that we're going to work on. The easiest way to do this is actually using the built-in work tree creation flag when you start a new cloud code session. All you need to do in order to take advantage of the built-in work trees in cloud code is use the dash dash work tree flag when you start a new cloud code session. So in this case I'm running Cloud Code with dangerously skip permissions because I like to live on the edge. And then what I'm doing is adding the dash dash work tree flag in addition to that command. And the pro tip here is to give your work tree a name. So what I'm going to do is name each of my work trees after the issue number that it corresponds to. So in this case, I'm going to call it issue 26. And what that's going to do is create a work tree with the name issue. 26. So we're going to press enter and what we're going to see is a new cloud session that is going to be created. So what this does is starts a new cloud code session inside a work tree and it creates the work tree for you. So in this case you can see here we are in a work tree called issue 26 and that work tree is actually stored in the dot cloud folder in your project directory. So .cloud slash worktrees slash worktree name, in this case issue 26 is where we are. So we did this for one of the issues. Let's go ahead and create worktrees for every issue that we're going to work on. I'm going to create a worktree for issue number 36. And a pro tip here is that you can also just type slash w instead of dash dash worktree. So dash w is going to give you the same impact as dash dash worktree in terms of. automatically creating a work tree and in this case it's going to be issue 36 so let's create a work tree for that issue and as you can see here we now are in a cloud code session that is running inside the work tree folder in this case work tree for issue 36 and then finally let's go ahead and create our work tree for the final issue that we're going to work on in this case it's going to be issue 44 i'm going to just use the shorthand flag dash w and it's going to be issue 44. So what we have here is we've successfully created three work trees, one for each feature that we're going to be working on. And we've started a cloud code session inside that work tree, all in just a single prompt, all in just three prompts, one for each cloud code session. You can also just leave the name field blank and just use dash dash work tree or dash w and claude will give you an auto generated name as well i just want to touch on something that i mentioned earlier which is where the work trees that are created by claude code live now by default the work trees that you create using the dash work tree command or dash w command live in the dot claude folder in particular the .clawed slash worktrees directory by default. So you can see here, if you have a folder called my project, for each cloud code project, you're going to have a folder called .clawed, which is going to store various cloud code related files and settings. And then inside the .clawed folder, you're going to have your worktrees folder, that's going to be the home for all the different worktrees that you're going to create. So in this case, we have three worktrees, one for each of the features, worktrees one, two, and three. and it's in those directories. So for example, starting a Cloud Code session using the WorkTree flag is going to start your Cloud Code session in that directory. And here you can clearly see the isolation between the different folders because you have Cloud Code sessions running in each of those folders, and that's how they don't conflict with each other. In addition to having their own Git branch that gets created automatically. So now that we have our issues and we have our WorkTree set up, it's time for step two. the build step. The build step is where the action happens. It's where we give Claude the issues to work on and use agent view to monitor the progress of all our agents. Now the main part of the build step is to kick off Claude code working on each feature. So what I'm going to do is just prompt Claude code by giving it the issue to work on and all I'm going to do is just simply put Claude code in plan mode and I'm going to give it the issue to work on. In this case let's implement issue number 26. Now what's going to happen here is that Claude code is going to use the GitHub CLI in order to read that GitHub issue and get the information from there. It's easier than just typing all that out. And you can see here, I'll start by reading issue 26 to understand what needs to be implemented. So we're going to do that for each of our issues. Once again, putting Claude into plan mode first, and then asking it to implement the issue number. that corresponds to the WorkTree branch name. So in this case, it's going to be issue 36 and Claude is going to work on that. And finally, it's going to be issue number 44, which is going to be the final issue that we're going to work on. And once again, I start all these sessions in plan mode and I actually do that for a very specific reason. And that reason is that for each feature, I recommend following what I call the RPIT build loop. which stands for Research, Plan, Implement, and Test. Now, the RPIT loop is especially important when building with multiple agents because it helps you ensure that what you're building actually works and that the feature actually works as you intend it to. Now, the RPIT loop is pretty simple. You can implement it in a very lightweight way. You can go crazy and have very in-depth implementations for each of the steps. But for example, the research step could just be creating a research report on APIs or things that Claude might need to reference when building the feature. Planning could just be as simple as chatting to the agent in order to create a plan and get clear on which files and what needs to change. Or it could just be as simple as using plan mode, which is what I've done in the examples that you've just seen. And then implement is where Claude cooks and it implements the features. And then finally testing. It's super important. This is where Claude will automatically test its work to make sure that its implementation is correct and that the feature is actually built properly. This is where you can use things like acceptance criteria in order to help Claude, as well as use things like the Playwright MCP in order to auto-test the UI as an example for testing. Now, you can just let the three Claude code agents run and switch tabs every so often to monitor them. But wouldn't it be cool if we could see all our sessions in one place? and get notified when our input is needed. That's where AgentView comes in. AgentView is a new feature in Cloud Code, and it's the sort of new feature that I cover in the What's New section of my weekly newsletter on AI coding. There's a link in the description if you'd like to get that delivered to your email inbox every weekend. To use AgentView, the first step is to make the session run in the background. To do that, we're just going to type slash BG to background the session after we've created it. And what that's going to do is actually move this session from the terminal window into the background. So what we're going to do is just do that for all of the sessions that we've started. And we're going to see how to recover them in just a moment. So let me accept that plan. And we're going to background the session. Step two of using agent view is to open up a new terminal window and use the command clawed agents in order to open up the agents view. Now, what this is going to do is actually open up this agent command center that is a dashboard with all the agents that we have running and their statuses. And what's going to happen is that Claude is actually going to notify us of which agents need our attention. And we can also switch in and out of the sessions as I'm going to show you right now. So in addition to looking at the status of all the agents at a high level, What we can do is just click into each of the issues to see how the agent is doing. So in this case, I'm back in issue 44. And to go back, you can see we just hit the left key, in this case, the back button, in order to go back to the agent view. And we can click in and out of every session in order to see what the agent is doing. In this case, this agent is planning. And we can go back. And we can also see, in addition to... the sessions that are for this particular project. You can also see your sessions across all your projects. In this case, a little Easter egg is I'm redesigning the landing page for my newsletter and this is stuck on approving a plan. If I wanted to, I could go and inspect what's going on in that session. This allows you to build really productively, not just with multiple Cloud Code agents in one project, but with multiple Cloud Code agents running across multiple projects at the same time. In the agents view, you can see We have this nice separation between the agents that are working and the agents that are completed. And we can see super clearly the status of each of our agents. And as I mentioned, going between agent session is as easy as just clicking in and out of the agents. And you can see here, I'm back in an agent that's working on issue 26 and we can inspect its task list and see that, Hey, it's actually almost finished implementing the feature and it's now just running the tests. testing the UI. Now in this case, this is a good example of a case where the agent needs input. So when an agent needs input, you can see here, I've got to approve the plans for the agents working on issue 44 and issue 36. This is the beauty of agent view because it's such a cool way to manage each session at a glance versus having all the output on your screen at the same time and having clawed flashing changes. That can be a bit overwhelming. This is a really cool way to check on any session and easily switch in and out. of different sessions. Now, remember the RPIT build loop where the T stands for tests. A pro tip is always to make sure that Claude has tested the feature and verified that each feature works before proceeding. We can see here, for example, that this Claude session is using the Playwright plugin in order to run tests, build the app, and then verify the UI using Playwright. Now, remember, we included things like acceptance criteria in our task descriptions and GitHub issues. That's another way in order to make sure that Claude tests its work before it's finished. And you can also have things like instructions in your Claude.md file in order to give Claude the testing instructions that it needs in order to test the app as you see fit. So what I'm going to do is approve Claude's plans, and then I'm going to step away and let Claude work on the three features, and we'll check back in on it once it's done. So the final step that I like to do in the build process for sessions that I've completed. So for example, this feature 26, the format picker, let's just click into that, is run a skill that I've created called update docs and commit. Now what this skill is going to do is update the docs in the docs folder. In this case, I have things like the change log, I have things like an architecture.md file, other documentation for the project, and then commit this to Git. So this is just a cool way to make sure that the code and the documentation for the project stay up to date. And then in step three, when we do the ship and the merge, we're going to be able to update both the code and the docs. That's going to make it a lot easier and a lot faster and just keep your project in sync and interpretable for both humans on your team, as well as, of course, for Claude code that's going to be working on your project. So Claude has successfully implemented the three features that we asked it to. You can see these are the three agents that have successfully completed The other agents that were still working at the time are still running, but we're not going to worry about those for now. And so we've successfully implemented all three of our features. And now that our features have been built and tested, it's time for step three, which is the ship step. In the ship step, we're going to take the features that we just built in our work trees and merge them back together into the main project. So a visual illustration of this is, say we have three work trees that worked on three different features. So you have one that worked on this feature, invite team, one that worked on this feature, export report, and one that worked on a search project feature. In contrast to the situation we saw at the start of the video where it overwrote each other, what we actually want to do is take all these features and merge them so that they can live happily together and live alongside each other in the final working app. And so that step is going to involve a merge. and we're going to see a situation where in our final UI we'll have all the features that each of the three Cloud Code agents worked on living harmoniously and working properly in the final application. So let's see how this is done. Now depending on your project or team situation you have a few different options and few different methods to pick from when you want to merge the work in the different work trees together. So let's start with method one which is PR review. If you're in a large team or you're making changes to a production application, this is who I think should use this method. And the method is pretty simple. You create one PR per work tree, and then you have Claude review and merge the PR one at a time. Now, the reason why this is a good method is because it's the safest way to make changes to your app. You're creating a PR, having Claude review that PR, and then merging the PRs one at a time. So this is the safest way, but it's also probably the slowest out of the three ways. And so that's the trade-off that you're making with this. And again, you'd use this if you're working in a large team, if you're working in an enterprise, there's probably a standard method and when working on production apps. Method two is what I'm calling the feature branch method. If you're on a small team or a solar builder who wants to move a bit faster, but who still wants a safety net, I recommend using this method. This is where you ask Claude to merge all the work trees together. into a new feature branch. Now doing this makes it easy to validate the changes without risking the stable version of your app. So you can test all the new features in a dev environment, for example a Vassal preview or whatever preview environment that you have. And then once you're happy you can merge into made. This is the method that I personally use the most often and so this is what I'm going to show you in this video. In the ship step, merging the different worktrees together into a feature branch is super simple. all you got to do is create a new cloud code session in the root of your project so in this case you can see i'm no longer in a work tree i'm in my main folder called ac infographic creator and all i'm going to do is just ask claude to merge the work trees for the specific issues together and then resolve all merge conflicts so the prompt would look something like this and you say hey claude please merge the work trees for issues 44, 36, and let's make sure we got the right one correct, 44, 36, and this one is 26, and 26 together into a new feature branch for further testing on dev, further testing in a preview environment. And then the most important part of this prompt, is going to be asking Claude to please resolve any conflicts and ensure all three features work as intended in the final app. So this is the prompt that you're going to use. And the cool part about this is that you can get Claude to handle things like messy Git operations, things like merging and resolving conflicts for you. This takes advantage of the fact that Claude has full context of how the app is supposed to behave. And so it can make judgment calls or even ask for your input to ensure that all three features get incorporated into the app correctly. So this is a prompt that I am using. And again, this is the method that I use as a solo builder who's want to move fast, but also want to move a bit cautiously. Again, if you're in an enterprise, if you're working in a larger company, just create one PR for every work tree and every change that you've made. and review and then merge those PRs one at a time. And the good thing about this method is that Claude is going to take care of the complexities of things like the order in which to merge your work trees. So over here you can see Claude has says, hey I'm going to set up the merge and bring them in sequentially starting with the smallest and then it's going to do 26, 36, then 44. So Claude will pick an order and the right order in which to make these mergers in so that all three features work as intended. This is the advantage of using Claude code for these kinds of merge operations in the final step, which is the ship step. Back to the three work tree merge methods. The final method is method three, which I'm calling straight to main. So if you're a solo builder that wants to move super fast and doesn't mind YOLO mode, you can ask Claude to merge all three work trees straight into the main branch and resolve conflicts. This is both the fastest method, but it's also the riskiest because you're merging straight into main. So you can use this if you want to live in YOLO mode, but if not, I recommend using either method one or method two. Okay, so Claude is actually done merging the three work trees together. Let's take a look at what it did. Claude went ahead and merged the three work trees together, but then it also resolved multiple conflicts between the work tree branches. So for example, you can see here resolve one conflict and for issue 44 resolve nine conflicts. across various parts of the app. A cool thing to note is that it also made a follow-up fix. So for example, this was something that as a result of the merging the three things together was broken in the app and Claude went ahead and fixed that. And then probably one of the most important things to keep in mind in having Claude code handle things like merging multiple work trees together is giving it a way to verify its own work. So in this case, what I went ahead and did is gave Claude various means to test the app. So the app had tests that Claude could run, and you can see here 43 out of 43 of them passed. And then it was also able to build the application, and then Claude was able to run some end-to-end tests for the app, and both of those passed. And what I also gave Claude the ability to do is to test the app and to use browser simulation to test the app using the Playwright MCP. And in this case, Claude ran in the browser and tested all seven formats. It did multi-select, which was one of the issues that we were implementing. And it also tested transcript uploads. And I also mentioned it implemented the new infographic styles that we asked it to. So in this case, Claude did both an end-to-end test and it did an actual user simulation test in the browser. So Claude has successfully not just merged the things together, but gone ahead and done. further testing and verification to ensure that it works correctly. The important part is Claude has full knowledge of how the app is supposed to work. It knows about these three features and is able to merge them correctly so that the app works as you intend. So before we see the app in action, there's one last step in the ship section, which is WorkTree Cleanup. Now when we're done merging the changes from each Claude agent into the app, I've created a custom skill called Cleanup WorkTrees. Now what this does, is after a session where I work with multiple Cloud Code agents at the same time, it will remove the git worktrees from my .cloud slash worktrees folder and delete the branches because those branches have already been merged into a feature branch for further testing or if there have been PRs that have been created and successfully merged into the app. And remember, worktrees are copies of your code base. They're isolated copies. of your folder and so you don't want to have too many old ones lying around that's just having multiple copies of your project for no reason and so we're going to use this skill slash cleanup work trees in order to clean up the work trees that we don't need so cleanup work trees just finished and we can see what claude has gone and done here so it's removed the three work trees that we've created for this project in this case for issue 26 36 and 44 And it's also gone ahead and removed the branches that we used that were associated with those work trees. But it's kept the .clawd.worktrees folder, which is where all the work trees that Claude automatically creates are kept. And most importantly, we have the final merged branch, the preview branch, that's called preview 263644, which is a creative name that Claude came up with. And Claude also pushed some additional follow-up fixes. So again, this is where the power of Having a system for working with multiple cloud code agents, and I've created these custom skills that help me with repetitive tasks. And in this case, the skill is clean up work trees, which allows me to make sure that at the end of building with multiple cloud code agents, we clean up the work trees and we don't have a bunch of stale work trees lying around. We've successfully applied the system to work with multiple cloud code agents at the same time. in order to build three features for this infographic creator app i want to demo the final product to you so that you can get a sense that these features actually work claude did actually test and verify these features by itself but i'm just going to demo them for you so that you can see them in action remember we implemented three features the first one was the ability to upload a transcript you can see there's a new upload button that is being created this button could probably be slightly different but for an mvp this is fine So let us go ahead and select upload and I'm going to have a new transcript that I'm going to upload by the Cloud Code desktop app. A good video if you haven't checked it out. So in this case, this is uploading a transcript. And the second feature that we implemented was the ability to select multiple transcripts for a video. So in addition to the uploaded transcript, I'm going to go ahead and select this 12 months of Cloud Code lessons in 45 minutes. So this will be the two transcripts that I'm going to select. And you can see here that this feature of allowing the user to pick multiple transcripts to generate infographics from is implemented with a nice checkbox functionality. So this seems like it's implemented correctly. So we're going to select those two transcripts. And then the third feature that Claude went ahead and implemented are new infographic styles. So I have new infographic styles. In this case, we have things like whiteboard, poster. table anatomy i like whiteboard so we're going to use whiteboard for this one and we're going to go ahead and test all these three features at the same time i'm actually going to select the topic of working with multiple clawed codes at the same time with git work trees of course this video was about working with multiple cloud codes at the same time with git work trees you can see claude is going ahead and generating that image So we'll wait for Cloud to generate that image and check back in when it's done. And there you have it. We've successfully generated an infographic using the new features that the three Cloud Code agents were implementing for us. So you can see here we have successfully generated an infographic with a new style called whiteboard. And this infographic is about working with multiple cloudcodes at the same time with Git Worktrees. This is the topic of the video. So it's a cool meta thing. And we're using the new features that we had. So for example, we selected multiple transcripts, we uploaded a transcript, and we're using the new whiteboard style, which is the style in which you can see the infographic has been generated. So this is just to show you that working with multiple cloudcodes at the same time and having a system for building and following things like the RPIT build process and using Git work trees can actually yield good results and is the way that I recommend using multiple Cloud Codes at the same time. Now that we've seen the system in action, let's look at some common mistakes and how to avoid them. But before we get into that, if you like my system for building with multiple Cloud Code agents and want to apply this to your own projects and just massively level up how you or your team work with Cloud Code in general, I've just opened new cohorts of my AI coding accelerator, ship with Cloud Code and Codex. It's the fastest way to get ahead of the curve with AI coding, and you can use the link in the video description for a YouTube exclusive discount. Now here are the top five most common mistakes and things to keep in mind when using Git work trees with multiple Cloud Code agents. Number one is forgetting that Git work trees only cover what's in your Git repo, not external systems. The mistake here is thinking that when you create a Git Worktree, it's going to also create copies of things like your hosted database or your cloud object storage. Git Worktrees only apply to the files and folders inside the Worktree itself. That's your application code, your docs, and whatever else is in your direct repo that you're creating a Worktree from. Worktrees don't apply to external systems like cloud databases, like Superbase or MongoDB Atlas. object storage like Cloudflare R2 or AWS S3 or webhook dependent flows with a single webhook URL. For example, Stripe is a common use case here. So if you're using those, you need to be careful of the cloud code agents making changes on the same thing. For example, multiple agents changing your database schema. So how do you solve this? The best solution is to plan your work ahead of time so that you don't have three features which all touch the database. or are all testing the Stripe checkout workflow at the same time. Instead, maybe have one feature that touches the database and the other two are just UI or business logic ones. This is why the preparation step at the start of the video is so important because it helps us move faster by avoiding mistakes like this. To pick good issues to work on at the same time, just ask Claude. Give Claude different groups of features that you're planning to work on and ask it to spot which ones might be the best to work in parallel. or which ones might have mistakes that you'd rather avoid. Another solution is having some isolation at the layer of your resource. For example, giving Claude its own local database instead of a hosted one, or its own database branch, for example, if you're using a hosted database like Superbase or Neon. Another common issue is running out of tokens. Building with five Cloud Code agents will use up your session limits on your Cloud Code subscription five times as fast as just building with one. However, I personally find the productivity trade-off to be worth it, and I mitigate the impact by using the Clawed 20x Max plan for $200 a month, which I found has generous limits for my use cases and just in my experience. To avoid running out of tokens, you can also try using cheaper models like Sonnet 4.7 versus using Opus all the time, especially for less complex features. And of course, you can always keep on building with API-based billing, which is the default for using Clawed in an enterprise. Mistake number three is that files not tracked by Git don't get carried over when you create worktrees. These are things like your .env file or your .env.local files. To get around this, we add a .worktree include file to your project root directory. This includes the names of the files that you want automatically copied when new worktrees are created. This ensures that your local environment variables get carried over to new worktrees that you create. The fourth thing to be aware of, is that certain types of projects are better suited for use with Git Worktrees than others. For example, Worktrees work great with web, backend, or full stack apps. For example, Next.js apps work very well with Worktrees, and they make it easy to run and test apps running in Worktrees branches. But Worktrees can be tricky when building, for example, with iOS apps or native Mac apps. The reason is that iOS and Mac apps have things like unique bundle identifiers, which identifies the app that's running on your machine or on the simulator. So even if you have separate work trees for your application code, you'll still run into stuff like this when you build your project and test it to see your changes. To get around this, you'll need to ask Claude to create something like a per work tree bundle ID and a per work tree app display name so that you can preview and test your changes independently. Now, there are also a few other Xcode-specific gotchas in addition to the bundle ID example that I just showed you. So just keep those in mind and ask Claude about them if you're using work trees to build iOS or Mac apps. And fifth and finally, don't keep old work trees lying around. Make sure to clean them up. Work trees can accumulate dependencies and in general just take up space. Remember, they're copies of your project, so they take up storage and they take up space on your machine. I use a custom skill called slash cleanup work trees in order to do this, but you can just ask Claude to remove the work trees that you no longer are using. Now, parallel agents is just one of many ways in Cloud Code to have multiple agents working for you. And it's important to understand how this works and how it compares to other methods. In general, there are three popular ways to build with multiple agents in Cloud Code. We've just seen a system to build with multiple Cloud Codes with Git work trees, but there's also things like parallel sub-agents and a new feature called agent teams. So let's take a look at what these are, how they're different, and when to use which approach. Now let's compare multiple Cloud Code agents with agent teams. Now, agent teams are multiple Cloud Code instances that work together. You have a team lead which delegates tasks to teammates who can work together with each other. The key difference is in isolation and in communication. Parallel agents with work trees don't know about each other. They work in isolation with no communication between agents. In contrast, Agent teams have multi-way communication. You have a lead that assigns tasks and synthesize results and teammates which can message both the lead and each other. There's multiple ways that they can communicate and coordinate together. So when should you use multiple agents with Git Worktrees or agent teams? I think using multiple cloud codes with Git Worktrees is best for building multiple independent features in parallel. And I think you should use agent teams if you're building one complex feature that requires coordination and that touches many different components so that those agents can actually communicate and coordinate when they're working on it. One thing to note is that agent teams are experimental and anthropic ones that they also use a lot of tokens. So just keep that in mind. Otherwise, definitely give them a shot. Next up, let's look at parallel subagents and how they compare. to using multiple cloud codes with kid work trees now sub agents in contrast to separate cloud code instances are child instances spawned from a parent agent and these child instances handle a focus task and just return results so if you want to look at the differences we have one-way communication in the parallel sub agents case where sub agents report back to the parent thread And once again, no communication and isolation in the case of multiple Claude codes. Now, you can have multiple sub-agents working in parallel, but the key difference is that sub-agents and parallel agents are different levels of abstraction. So let's take a look at how that's the case. The key idea here is that agents can spawn sub-agents to help perform a specific task. So you can have multiple sub-agents spawned by a specific agent in order to perform a task in parallel. For example, performing web searches, reading files, doing the same thing for different components. Maybe it's research, maybe it's implementation. Now, the cool thing here is that you can actually use parallel agents and sub-agents together, as you can see in the diagram. For example, you can have multiple agents that are created. So in this case, we've created three agents. And each of these agents in turn spawns multiple sub-agents to help it complete the task that it's been assigned. So these features, parallel sub-agents and multiple cloud code agents are not mutually exclusive. You can use these things together, but it's good to understand which one you're using and the trade-offs that come with it. So once again, I'd recommend using multiple cloud codes with Git work trees when you're building multiple independent features in parallel. and using parallel sub-agents for things like research, investigation, and analysis, where you just need the answers back. So this is just an overview, but let me know in the comments if you want a deeper dive into more in-depth explanations of how these multi-agent workflows compare to each other and seeing things like agent teams and parallel sub-agents in action. So that's it. That's the exact three-phase system that I use to build with multiple cloud code agents. And you now have a complete system. for building with multiple agents productively. If you want help applying the system, check out my AI coding accelerator, SHIB with Cloud Code and Codex, where you'll build repeatable AI coding workflows and get hands-on help from me. You can find a link with a YouTube exclusive discount in the video description. Don't forget to like and subscribe for more AI coding videos and leave a comment with what you learned or with any questions that you have. I read every single one of them. Catch you in the next one.

Git worktrees, agent view, and my full workflow for building with parallel Claude Code agents.

20% OFF My AI Coding Accelerator: https://maven.com/avthar/ship-with-ai?promoCode=YOUTUBE

20% OFF Technical Essentials for AI Builders Workshop: https://maven.com/avthar/tech-foundations?promoCode=YOUTUBE

Free AI Native Builders Newsletter: https://newsletter.ainativebuilder.com

Claude Code Planning System: https://youtu.be/aQvpqlSiUIQ?si=35iPAUbTNhu2JSJo

Want to learn more? Check out these other Claude Code videos:
https://youtu.be/phuBfn3pqJU?si=3KWFgDdB1VRr-Ufl
——
After making just about every mistake possible, I've dialed in a complete three-phase system (Prepare, Build, Ship) for building productively with multiple Claude Code agents. In this video, I'll walk you through it by building three new features in a real infographic maker app, live from start to finish.

🎯 What You'll Learn:
✅ Phase 1 - Prepare:
Organizing work with GitHub Issues (and a custom skill to auto-create them)
How to pick issues that won't conflict in parallel
Git worktrees explained — isolated copies so agents never overwrite each other
Creating worktrees instantly with the --worktree (-w) flag

✅ Phase 2 - Build:
The RPIT loop (Research, Plan, Implement, Test) for every feature
Using Agent View to monitor all your agents in one command center
Backgrounding sessions with /bg and getting notified when input is needed
Auto-testing with the Playwright MCP and acceptance criteria
Keeping docs in sync with an Update Docs & Commit skill

✅ Phase 3 - Ship:
3 ways to merge worktrees: PR review, feature branch, and straight-to-main
Letting Claude handle merge conflicts and pick the right merge order
Cleaning up old worktrees with a custom /cleanupworktrees skill
A live demo of all three features working together

✅ Bonus - Avoid These Mistakes:
Why worktrees don't cover external systems (databases, storage, Stripe)
Managing token usage across multiple agents
Carrying over .env files with .worktreeinclude
Worktree gotchas for iOS/Mac apps
How parallel agents compare to Agent Teams and parallel subagents — and when to use each
——
🔔 ABOUT AI WITH AVTHAR 
Learn how to build apps with AI coding tools, even if you're new to coding. Subscribe to learn about the best AI coding tools and how to get the most out of them. I'm Avthar Sewrathan, and I'm obsessed with AI coding tools. With a decade of tech experience and background as a startup founder and AI Product Manager, I bring you practical insights on tools like ChatGPT Codex, Claude Code, Cursor, Replit, v0, and more.

FOLLOW AVTHAR:
FREE NEWSLETTER: https://newsletter.ainativebuilder.com 
LIVE COURSE: https://maven.com/avthar/ship-with-ai?promoCode=YOUTUBE
YOUTUBE: https://www.youtube.com/@avtharai
X (TWITTER): https://x.com/avthars
TIKTOK: https://www.tiktok.com/@vibecoder.com

TIMESTAMPS
0:00 The Biggest Productivity Unlock
2:09 Step 1: Prepare
5:49 Terminal Setup
6:49 Git Worktrees
12:39 Step 2: Build
15:34 Agent View
18:51 Pro Tips for Multi-Agent Building
21:01 Step 3: Merge and Ship
21:59 Worktree Merge Methods
28:45 Worktree Cleanup
30:44 Completed Features Review
33:43 5 Common Mistakes
38:46 Comparison: Parallel Agents vs Agent Teams vs Subagents
42:45 Apply This System