A Hands-On Review of Conductor, an AI Parallel Runner App

An AI assistant that can work on multiple features in your codebase at once? That's the promise of Conductor. We put it to the test.

Oct 11th, 2025 7:00am by David Eastman

Featued image for: A Hands-On Review of Conductor, an AI Parallel Runner App

Image via Unsplash+.

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.

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:

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.

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:

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.

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:

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:

But my old version in GitHub hasn’t been updated yet:

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:

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:

Compare this to my more functionally complete updated version:

So I’ll ask Conductor to fix this in the Indianapolis workspace:

And I let it go to work. But if we look at the dashboard, we see something odd:

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:

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!

Let’s go back to Indianapolis, which is now “add-nav-icons.” This has also finished:

So, closing down from the previous task, I rerun from the new task (which remains Indianapolis within the terminal):

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:

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.

David has been a London-based professional software developer with Oracle Corp. and British Telecom, and a consultant helping teams work in a more agile fashion. He wrote a book on UI design and has been writing technical articles ever since....