General knowledge highlights how multitasking should be avoided as much as possible because it removes you from focus. However, with the rise of coding agents, parallel work has become a requirement to be efficient. Considering coding agents can run for a longer period of time, you don’t want to spend time waiting on them to finish. Instead, you want to fire off an agent, and while that agent is working, you want to start another task.
However, starting off tasks in parallel isn’t straightforward. There are numerous considerations you need to make, such as
- How do you run multiple coding agents in the same repository?
- How do you still minimize context switching as much as possible?
- How do you keep an overview of all of your agents that are running?
I’ll cover all of these points in today’s article with specifics on how I deal with these problems and the solution I apply.
Why run agents in parallel
As with a lot of the other articles I’ve written, the main reason for the techniques I describe in the article is saving time and being more efficient as an engineer. If you want to get the most out of coding agents and the incredible LLM development we’ve seen in the last few years, you need to parallelize your work.
To understand why, let’s imagine the opposite example. Let’s imagine only working sequentially, like you typically did when programming before LLMs became available. Sequential programming with coding agents would look something like:
- Find the task you want to do
- Describe it to an agent and make a plan
- Start the agent and let it run. Wait until it finishes or asks you for something
- Test implementation and iterate
How long each of these tasks is will vary a lot. Sometimes describing the task to an agent and creating a plan takes the most amount of time, but in my experience, the third step is often a time-consuming step, especially for larger implementations such as implementing a new feature or solving a complex bug.
Now, to become more efficient, what we want to do is to eliminate bottlenecks. The third step is a bottleneck we can easily minimize or eliminate. Steps one and two are very difficult to be more efficient at. You need to do this sequentially and spend time on them. Step four is definitely something you can make more efficient, as I’ve described in other articles, such as my article on Making Claude Better at One-Shotting Implementations. I’ll thus focus on step 3 in this article and how to make it more efficient.
How to run agents in parallel
The simple solution to making step 3 more efficient is to run agents in parallel. This sounds simple in theory, but it’s actually harder to do effectively in practice. The reason for this is that running tasks in parallel presents a number of challenges.
One challenge you have to deal with is agents writing code over each other. You don’t want agents competing for editing a specific file or testing their own implementation. So this is one problem you have to deal with. Another problem you have to deal with is the fact that you have to do context switching. So when you run tasks in parallel, you naturally have to do context switching between the different tasks. One aspect of context switching is that you have to first describe one task and how to solve it, then describe another task and how to solve it. Another aspect of context switching is when the agent asks for feedback, such as asking you questions about an implementation or asking you to test an implementation. So, minimizing context switching is another aspect that I’ll describe in the latter sections.
Running multiple agents in the same repository using worktrees
The first topic I’ll cover is how to run multiple agents in the same repository. The simple answer to how to do this is to use worktrees.
You can simply instruct your agent to use a worktree, which is a git feature that essentially copies your entire repository. So different agents can work in completely different repositories. After an agent finishes its implementation, it can be merged into the main branch of the main repository, and in this way, you can have multiple agents working in the same repository without conflicts.
However, sometimes there could be simpler ways to achieve the worktree setup. From my personal experience, I had issues when using Claude Code and asking it to check out a worktree. Claude would often forget to actually check out a new worktree and then start work in the main repository. Then, when multiple agents did the same thing, I started having conflicts. Luckily, Claude Code implemented a –worktree command that you can use when spinning up cloud code, such as below
claude --worktreeIf you use this command within a GitHub repository, Claude will automatically check out to a new worktree given the existing repository and will store all the worktrees under a hidden Claude folder. This is incredibly useful for two main reasons:
- You guarantee that you’re always using a worktree and that your agents will not interfere with each other.
- The worktrees are stored in a hidden Claude folder and not in your main folder. This significantly reduces the amount of noise in your folder structure, making it easier to navigate your folder structure manually if you need to do that.
If you’re using another coding agent, you can figure out how they’ve set up worktrees, as worktrees are becoming more and more of an expected feature for any coding agent program, such as an IDE like Cursor or a CLI like Claude Code.
Minimize context switching
Aspect number two that you need to think about when running coding agents in parallel is that you need to minimize context switching. I mentioned earlier how this comes mainly in two aspects. One, when starting after tasks, and two, when interacting with the agent during the task, such as when the agent asks you questions, or it finishes its implementation and asks you to test it.
There’s no simple solution to just eliminate contact switching, as parallel work inherently implies contact switching. However, there are a few things I keep in mind to minimize my contact switching.
The first thing I keep in mind is to always finish my current task before moving to another task. This seems very obvious when I describe it; however, I want to provide a specific example. You can find the example described in the text below, but I’ll also show the image to give you an easier understanding of the concept right below.
Let’s say you have two tasks, A and B, that you need to do. Task A requires a five-minute interaction from the user, while task B requires a two-minute interaction by the user, and after that interaction, the agent will run for ten minutes to complete the task. Also, you already started task A, and your mental context is currently on task A.
In this situation, it is very tempting to switch from task A to task B, do the two-minute setup on task B so the agent can run while you finish task A. However, I urge you to avoid this as much as possible and rather try to finish the work you’re currently doing and then move on to the next task in line, even though this might not seem like the optimal approach at first glance.
The reason for this is that you can, of course, see how many minutes it takes to complete each task. Task A takes 5 minutes, task B takes 2 minutes of interaction and then 10 minutes to run. However, what you don’t see is the hidden cost of context switching, and I’d argue that switching from task A to B and then switching back to task A will cost you more time than simply completing task A and then completing task B.
The second way I minimize contact switching is to minimize distractions on my computer. There are numerous ways to do this, but in general, I urge you to disable all notifications. I, for example, disabled the Slack notifications on my computer and also the number appearing on the Slack application that informs you if you have a message waiting for you. I find this very distracting and removes my focus and context from the work that I’m currently doing.
Furthermore, I try to keep one tab in my terminal setup per repository I’m working on. And if I’m working on multiple tasks within a single repository, I split the tab. I’ll discuss my terminal setup in more detail in the next section.
Keep an overview of all of your agents
When you run multiple agents, it’s incredibly important to keep an overview of all your agents. However, this does not necessarily come naturally, and you need to make active choices to make it as easy as possible to gain an overview.
This is where my terminal setup comes in clutch. When I have 5 to 10 agents running in parallel, it can easily be very confusing which agent is doing what and what you need to interact with.
For my terminal setup, I use Warp. I think Warp is a good AI terminal that has good autocomplete and that I can easily interact with to use Claude Code effectively. I use one tab in Warp per repository I’m working in. This could be a coding repository, for example, containing the frontend or application, but it could also be a sales repository where I’ll do all of the sales work.
Then, if I run multiple agents within one repository, which I often do, I simply split the tabs using CMD + D on Mac. So I get multiple split subtabs for each of my main tabs. This helps me keep only a single main tab for each repository, while also running multiple agents within the repository.
Furthermore, I like to rename my tabs within Warp to the repository name so that it’s easy to navigate to the correct tab. And use CMD 1/2/3 and so on to quickly navigate between the different tabs. And I have notifications from Warp whenever an agent needs interaction.
I would also like to note that there are many other setups you can use for your coding agents. First of all, you can use a different terminal, which will likely work quite well also, though my preference stays on warm. Another good alternative I know of is to use the Claude application or an application called Conductor, which makes it easy to give an overview of your different repositories and coding agents that you are running.
All in all, however, your setup comes down to what your preference is. If you find a setup that works well for you, I highly recommend using that setup and simply sticking with it.
Conclusion
In this article, I’ve discussed how to efficiently parallelize your programming tasks. The main reason you should do this is to simply be more efficient as an engineer. If you run tasks in parallel, you’ll be far more effective than a similar engineer who runs tasks sequentially. However, running tasks in parallel isn’t straightforward, and you need to use specific techniques to keep an overview of all your agents, minimize context switching, and ensure your agents aren’t colliding with each other. I believe the concept I’ve described in this article is the future of work with AI. Humans will become orchestrators of AI agents, and you need to be able to efficiently parallelize your work and fire off agents to complete specific tasks while you only interact with the agents on demand.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack
