The nice thing about
Conductor is that it has one of the simplest strap lines: “Run a bunch of Claude Codes in parallel”. But before I continue, I must point out that there is another product called
Orkes Conductor (previously: Netflix Conductor) that is pivoting to AI, but is nevertheless quite different. The world of agentic is beginning to get crowded, isn’t it? Anyway, this version of Conductor comes from
Melty Labs. It belongs to a new category of AI coding apps I’m calling “agentic parallel runner apps.”
First of all, why would we want to run separate Claude Codes? We need to know one more piece of information, made clear on the front page: “Each workspace is an isolated copy and branch of your Git repo. Conductor only copies files tracked in git.” This means we can make independent changes in each workspace, much like the way a team uses git branches to avoid clashing while implementing tasks.
If you read my posts regularly and think this feels slightly familiar, well
Verdent is doing much the same with the UI, but without the focus on isolated copies.
Conductor’s own advice is to create one workspace per feature. While you may imagine that leaving an LLM to work on one problem while you wander off and work on another issue is currently optimistic, just this Sunday I read the pro-AI commentator
Azeem Azhar’s newsletter, which stated that “Anthropic’s
Claude 4.5 Sonnet, the best-in-class coding model, can reportedly work autonomously for 30 hours on a codebase” — so maybe the parallel runner is just the direction of travel for computing work.
We’ll also see that just identifying the workspace becomes an interesting issue, but let’s start with an installation.
I went straight to the site to download Conductor, which is a Mac-only app, like Verdent. There is a Windows waitlist.
👁 Image
At the moment, Conductor only works through GitHub-compatible repos. So I also had to download GitHub CLI. While I don’t primarily use GitHub for my repos, this is not a restriction that stops me from trying things out. Anyway, I jumped onto my terminal and ran:
brew install gh
Then to authenticate:
gh auth login
This does the security dance to authenticate GitHub CLI to your account. Eventually, you will see this:
👁 Image
Note that this is a Mac-only app, plus it only works for Anthropic’s Claude Code, and it only uses GitHub-compatible repos. But as I said, Conductor represents a family of similar apps, and none of these restrictions will hold for long.
👁 Image
If you go back to my
Google Jules review, I had put my Rails app tool onto GitHub, so we may as well use that. After associating a drive folder with your git project, we get the main screen:
👁 Image
The screen arrangement looks familiar. First of all, the arbitrary unique name is used to identify my workspace — that is going to matter if I have a lot of workspaces. So, hello Sacramento. We get the query box at the bottom, the terminal to the bottom right corner, the diff area top right and the workspace list on the left.
To confirm the old version of the app still works, I ran the app in Warp and it was more or less fine, with plenty of scope for improvement.
👁 Image
Note that the git project directory is created under conductor. But hold on, this isn’t the Sacramento workspace. That is further down, as Conductor’s terminal reports:
👁 Image
OK, that’s understood. Now, let’s make a change. The one we usually make is to use Bootstrap in all the views. So the current version of my app uses Bootstrap buttons with colour at the bottom of the page to give the CRUD options:
👁 Image
But my old version in GitHub hasn’t been updated yet:
👁 Image
So, looking at the
show.html.erb view in the new version, we see how the Bootstrap classes are applied:
<div class="mt-4" >
<%= link_to "< Back to conversations", conversations_path, :class => "btn btn-outline-success" %>
<%= link_to "Change conversation's name", edit_conversation_path(@conversation), :class => "btn btn-warning" %>
<%= link_to "Destroy this conversation", @conversation, method: :delete, :class => "btn btn-danger" %>
</div>
So I’ll ask Conductor to change the relevant buttons in the old version by describing the classes to apply:
👁 Image
Obviously, if I were doing this in anger, it would make much more sense to apply this to every
show.html.erb view file! Incidentally, Conductor is using Sonnet 4.5 for this.
But of course, we don’t sit and watch the LLM work. We move on to creating another workspace and solving another issue. I go straight to workspace Indianapolis with my new issue.
Looking at my app’s sidebar, it doesn’t seem to have used a nice range of icon images:
👁 Image
Compare this to my more functionally complete updated version:
👁 Image
So I’ll ask Conductor to fix this in the Indianapolis workspace:
👁 Image
And I let it go to work.
But if we look at the dashboard, we see something odd:
👁 Image
We see that Conductor has renamed the Sacramento workspace into a name based on the task action “conversation-button-style.” While kind of logical, the obvious problem here is that the identity of this workspace task has changed — I’m not sure whether that is wise without permission. This is now the name of the new git branch the changes will be staged on.
Anyway, I can go back and check the first task, and it is done:
👁 Image
And it has done the work, though I would need to tell it to use the space in a more elegant way. But that would be another task!
👁 Image
Let’s go back to Indianapolis, which is now “add-nav-icons.” This has also finished:
👁 Image
So, closing down from the previous task, I rerun from the new task (which remains Indianapolis within the terminal):
👁 Image
Well, Travellers seems to have lost its icon, but the others have their own now. Again, this would be another fix.
Looking at the terminal, the workspace keeps its name, but the branch changes its name based on the task:
👁 Image
Conclusion
I would still have the merge mechanics to attend to (Conductor nudges us to use pull requests), but we’ve gone far enough to demonstrate that parallel running works fine in theory. There is definitely some care needed to represent the workspace name vs. task name vs. task branch, but a refined UI journey could simplify this.
Someone made the interesting point that this type of chunk work makes more sense to senior devs or tech leads whose workday is usually a series of interruptions, as opposed to the devs who need to get “in flow.”
But while the tech lead is already used to overseeing parallel work, other engineers may regard constant context switching with suspicion. I think many developers will be able to make good music with Conductor. But either way, we will see a deeper focus on the LLM parallel workflow as many well-defined tasks become an LLM’s forte.
