General knowledge highlights how multitasking ought to be avoided as much as possible since it removes you from focus. Nonetheless, with the rise of coding agents, parallel work has change into a requirement to be efficient. Considering coding agents can run for an extended time frame, you don’t need to spend time waiting on them to complete. As an alternative, you would like to fire off an agent, and while that agent is working, you would like to start one other task.
Nonetheless, taking off tasks in parallel isn’t straightforward. There are many considerations you should make, reminiscent of
- How do you run multiple coding agents in the identical repository?
- How do you continue to minimize context switching as much as possible?
- How do you retain an outline of your whole agents which are running?
I’ll cover all of those points in today’s article with specifics on how I take care of these problems and the answer I apply.
Why run agents in parallel
As with a variety of the opposite articles I’ve written, the important reason for the techniques I describe within the article is saving time and being more efficient as an engineer. If you would like to get probably the most out of coding agents and the incredible LLM development we’ve seen in the previous few years, you should parallelize your work.
To know why, let’s imagine the alternative example. Let’s imagine only working sequentially, like you sometimes did when programming before LLMs became available. Sequential programming with coding agents would look something like:
- Find the duty you would like 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 those tasks is will vary quite a bit. Sometimes describing the duty to an agent and making a plan takes probably the most period of time, but in my experience, the third step is usually a time-consuming step, especially for larger implementations reminiscent of implementing a brand new feature or solving a posh bug.
Now, to change into more efficient, what we wish to do is to eliminate bottlenecks. The third step is a bottleneck we will easily minimize or eliminate. Steps one and two are very difficult to be more efficient at. That you must do that sequentially and spend time on them. Step 4 is unquestionably something you’ll be able to make more efficient, as I’ve described in other articles, reminiscent of my article on Making Claude Higher at One-Shotting Implementations. I’ll thus give attention to step 3 in this text and find out how to make it more efficient.
Easy methods to run agents in parallel
The easy solution to creating step 3 more efficient is to run agents in parallel. This sounds easy in theory, nevertheless it’s actually harder to do effectively in practice. The rationale for that is that running tasks in parallel presents quite a lot of challenges.
One challenge you’ve to take care of is agents writing code over one another. You don’t want agents competing for editing a particular file or testing their very own implementation. So that is one problem you’ve to take care of. One other problem you’ve to take care of is the incontrovertible fact that you’ve to do context switching. So if you run tasks in parallel, you naturally need to do context switching between the various tasks. One aspect of context switching is that you’ve to first describe one task and find out how to solve it, then describe one other task and find out how to solve it. One other aspect of context switching is when the agent asks for feedback, reminiscent of asking you questions on an implementation or asking you to check an implementation. So, minimizing context switching is one other aspect that I’ll describe within the latter sections.
Running multiple agents in the identical repository using worktrees
The primary topic I’ll cover is find out how to run multiple agents in the identical repository. The easy answer to find out how to do that is to make use of worktrees.
You possibly can simply instruct your agent to make use of 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 will possibly be merged into the important branch of the important repository, and in this fashion, you’ll be able to have multiple agents working in the identical repository without conflicts.
Nonetheless, sometimes there might be simpler ways to attain the worktree setup. From my personal experience, I had issues when using Claude Code and asking it to examine out a worktree. Claude would often forget to truly try a brand new worktree after which start work within the important repository. Then, when multiple agents did the identical thing, I began having conflicts. Luckily, Claude Code implemented a reminiscent of below
claude --worktreeIn case you use this command inside a GitHub repository, Claude will robotically try to a brand new worktree given the present repository and can store all of the worktrees under a hidden Claude folder. That is incredibly useful for 2 important reasons:
- You guarantee that you just’re at all times using a worktree and that your agents won’t interfere with one another.
- The worktrees are stored in a hidden Claude folder and never in your important folder. This significantly reduces the quantity of noise in your folder structure, making it easier to navigate your folder structure manually if you should do this.
In case you’re using one other coding agent, you’ll be able to determine how they’ve arrange worktrees, as worktrees have gotten an increasing number of of an expected feature for any coding agent program, reminiscent of an IDE like Cursor or a CLI like Claude Code.
Minimize context switching
Aspect number two that you should take into consideration when running coding agents in parallel is that you should minimize context switching. I discussed earlier how this comes mainly in two facets. One, when starting after tasks, and two, when interacting with the agent throughout the task, reminiscent of when the agent asks you questions, or it finishes its implementation and asks you to check it.
There’s no easy solution to simply eliminate contact switching, as parallel work inherently implies contact switching. Nonetheless, there are a number of things I bear in mind to reduce my contact switching.
The very first thing I bear in mind is to at all times finish my current task before moving to a different task. This seems very obvious once I describe it; nevertheless, I need to supply a particular example. You could find the instance described within the text below, but I’ll also show the image to provide you a neater understanding of the concept right below.
Let’s say you’ve two tasks, A and B, that you should 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 finish the duty. Also, you already began task A, and your mental context is currently on task A.
In this example, it is extremely tempting to modify from task A to task B, do the two-minute setup on task B so the agent can run when you finish task A. Nonetheless, I urge you to avoid this as much as possible and slightly try to complete the work you’re currently doing after which move on to the following task in line, despite the fact that this may not appear to be the optimal approach at first glance.
The rationale for that is that you could, in fact, see what number of minutes it takes to finish each task. Task A takes 5 minutes, task B takes 2 minutes of interaction after which 10 minutes to run. Nonetheless, what you don’t see is the hidden cost of context switching, and I’d argue that switching from task A to B after which switching back to task A will cost you more time than simply completing task A after which completing task B.
The second way I minimize contact switching is to reduce distractions on my computer. There are many ways to do that, but typically, I urge you to disable all notifications. I, for instance, disabled the Slack notifications on my computer and in addition the number appearing on the Slack application that informs you if you’ve a message waiting for you. I find this very distracting and removes my focus and context from the work that I’m currently doing.
Moreover, I attempt to keep one tab in my terminal setup per repository I’m working on. And if I’m working on multiple tasks inside a single repository, I split the tab. I’ll discuss my terminal setup in additional detail in the following section.
Keep an outline of your whole agents
If you run multiple agents, it’s incredibly essential to maintain an outline of all of your agents. Nonetheless, this doesn’t necessarily come naturally, and you should make lively decisions to make it as easy as possible to achieve an outline.
That is where my terminal setup is available in clutch. When I actually have 5 to 10 agents running in parallel, it will possibly easily be very confusing which agent is doing what and what you should interact with.
For my terminal setup, I exploit Warp. I feel Warp is an excellent AI terminal that has good autocomplete and that I can easily interact with to make use of Claude Code effectively. I exploit one tab in Warp per repository I’m working in. This might be a coding repository, for instance, containing the frontend or application, nevertheless it may be a sales repository where I’ll do all the sales work.
Then, if I run multiple agents inside one repository, which I often do, I simply split the tabs using CMD + D on Mac. So I get multiple split subtabs for every of my important tabs. This helps me keep only a single important tab for every repository, while also running multiple agents throughout the repository.
Moreover, I wish to rename my tabs inside Warp to the repository name in order that it’s easy to navigate to the proper tab. And use CMD 1/2/3 and so forth to quickly navigate between the various tabs. And I actually have notifications from Warp every time an agent needs interaction.
I’d also wish to note that there are a lot of other setups you should use to your coding agents. To begin with, you should use a unique terminal, which is able to likely work quite well also, though my preference stays on warm. One other good alternative I do know of is to make use of the Claude application or an application called Conductor, which makes it easy to provide an outline of your different repositories and coding agents that you just are running.
All in all, nevertheless, your setup comes all the way down to what your preference is. In case you discover a setup that works well for you, I highly recommend using that setup and easily sticking with it.
Conclusion
In this text, I’ve discussed find out how to efficiently parallelize your programming tasks. The important reason it is best to do that is to easily be more efficient as an engineer. In case you run tasks in parallel, you’ll be far simpler than the same engineer who runs tasks sequentially. Nonetheless, running tasks in parallel isn’t straightforward, and you should use specific techniques to maintain an outline of all of your agents, minimize context switching, and ensure your agents aren’t colliding with one another. I consider the concept I’ve described in this text is the longer term of labor with AI. Humans will change into orchestrators of AI agents, and you should give you the option to efficiently parallelize your work and fire off agents to finish specific tasks when 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
