Something I never see mention is that all agents / CLI tools seem to modify local files. Which makes editing current files, working with the git, asking to only modify some parts of the files etc. cumbersome, as the agent is constantly reading and writing to files that we are also accessing. This is usually solved by using git worktree but this solution requires 1 new folder name and branch for each new agent, and each folder will have its own unique name and others issues.
While it can be super powerful, I wish there was a quicker "in memory" agent solution where each agent keeps in its own RAM the list of files modifications ("patch") it recommends to apply to solve current issue. Then we could apply that patch depending on what we're doing, if we have others patches to apply before etc.
Also even if agents can work in parallel, sometimes we only have 1 of them in front of us and if we already know what's the next thing we're gonna ask, we'll still wait for the previous task to be completed before sending the new prompt. I'm not sure how to improve this async problem, I guess I could launch multiple agents in parallel but I wouldn't get sharing of the chat history between the different agents, and when I work I usually work on related issues that depend on each others, thus I do need some kind of global or shared context between agents analyzing codebases and creating patches.
Anyone has ideas over how to improve those AI coding agents workflows ? Maybe latest versions of GitButler https://gitbutler.com/ but I'm not sure, and it does use git worktree behind the hood
In my coding agent, nocodo (1), I am thinking about using copy on write filesystems for cheaper multi-agent operations. But to be honest git worktree may be good enough for most use cases. nocodo checks existing worktree in the local repo and I will add creation and merge support too.
We chose not to use separate git worktrees under the hood for this functionality. Let me try to break down why, maybe there's an opportunity for me to learn more here.
In my head I separate between use cases of 1) "different tasks" and 2) "best of n, same task".
The app that we built already had the ability to separate changes into branches while in the worktree (on disk) it renders the integration of the branches. Our canonical use case back in the days was "A developer works on a feature branch and wishes to commit & publish a bugfix from separate branch". When we learned that people were using this for running multiple parallel agents we added some additional tooling for it.
So in practice what happens when you have multiple agents coding in parallel with GitButler is that the system captures information after an agent completes an edit (via the agent hooks) and uses that to 1) stage the particular edit to a branch dedicated to the agent and 2) perform a commit into that branch (GB can have multiple staging areas, one per applied branch).
The system will not allow multiple agents to edit the same file at the same time (via a locking mechanism in the pre-edit hook), but agents do see each others changes.
In the context of the "different tasks for different agents" use case, we have found that them seeing edits by others to have a positive effect on the outcomes. The first one that comes to mind is - no merge conflicts. But beyond merge conflicts, we have found that there is a lower likelihood of reaching a state where code diverges semantically.
In my own usage, I have found it helpful when I am hands on programming on something and wish to have an agent do some auxiliary task, for us to share a workspace (so that I can nudge it one way or another).
Is there something I am missing here? Of course for best-of-n of the same task this doesn't exactly make sense, but with regards to different tasks, what are some additional reasons to require full isolation? (as different worktrees would provide)
I would love something similar that lets me plug in actual Claude Code/Codex with their original agent loop, prompting etc, and just handles the multiplexing, worktrees, isolation, etc automatically (it looks like this tool doesn’t support that). Because I think a lot of the power of eg CC comes from the engineering they’ve done to the tool rather than the underlying model.
I have build my own tool for this https://github.com/tobias-walle/agency
It uses tmux to run the agents and offers some convenience commands that, e.g. lets you merge the changes back into its original branch. I added some simple idle and change detection, so you can see which agent needs your attention.
As all agents are just simple cli commands it is very easy to extend the config with your tool of choice.
I started building it out that way but found it very challenging to create parity between the models. E.g. they have different tools, system prompts, interruption semantics, cost tracking etc. The spirit of the product is decoupling the LLM from the UI, so we went with a custom loop / tools that can perform decently across all models.
The issue I run into is with integration tests that rely on docker. If two agents try to run tests at the same time it doesn't work. I need to manually do air traffic control on the agents use of higher level tests suites.
Struggling with the same thing right now. I'm trying to make it work by generating unique ports for each instance so they don't conflict. Not quite 100% successful yet.
Very similar features, Catnip is Claude Code specific and does everything in a Docker container so you can more safely run in YOLO mode and the Git worktrees don't make a mess on your host filesystem or checkout. Also is mobile responsive which is cute.
I made a TUI to do something similar. It’s taking a backseat during parental leave, but it’s a fun project to see n number of agents iterating on the same problem and to see how they differ.
14 comments
[ 61.9 ms ] story [ 501 ms ] threadWhile it can be super powerful, I wish there was a quicker "in memory" agent solution where each agent keeps in its own RAM the list of files modifications ("patch") it recommends to apply to solve current issue. Then we could apply that patch depending on what we're doing, if we have others patches to apply before etc.
Also even if agents can work in parallel, sometimes we only have 1 of them in front of us and if we already know what's the next thing we're gonna ask, we'll still wait for the previous task to be completed before sending the new prompt. I'm not sure how to improve this async problem, I guess I could launch multiple agents in parallel but I wouldn't get sharing of the chat history between the different agents, and when I work I usually work on related issues that depend on each others, thus I do need some kind of global or shared context between agents analyzing codebases and creating patches.
Anyone has ideas over how to improve those AI coding agents workflows ? Maybe latest versions of GitButler https://gitbutler.com/ but I'm not sure, and it does use git worktree behind the hood
1. https://github.com/brainless/nocodo
We chose not to use separate git worktrees under the hood for this functionality. Let me try to break down why, maybe there's an opportunity for me to learn more here.
In my head I separate between use cases of 1) "different tasks" and 2) "best of n, same task".
The app that we built already had the ability to separate changes into branches while in the worktree (on disk) it renders the integration of the branches. Our canonical use case back in the days was "A developer works on a feature branch and wishes to commit & publish a bugfix from separate branch". When we learned that people were using this for running multiple parallel agents we added some additional tooling for it.
So in practice what happens when you have multiple agents coding in parallel with GitButler is that the system captures information after an agent completes an edit (via the agent hooks) and uses that to 1) stage the particular edit to a branch dedicated to the agent and 2) perform a commit into that branch (GB can have multiple staging areas, one per applied branch).
The system will not allow multiple agents to edit the same file at the same time (via a locking mechanism in the pre-edit hook), but agents do see each others changes.
In the context of the "different tasks for different agents" use case, we have found that them seeing edits by others to have a positive effect on the outcomes. The first one that comes to mind is - no merge conflicts. But beyond merge conflicts, we have found that there is a lower likelihood of reaching a state where code diverges semantically.
In my own usage, I have found it helpful when I am hands on programming on something and wish to have an agent do some auxiliary task, for us to share a workspace (so that I can nudge it one way or another).
Is there something I am missing here? Of course for best-of-n of the same task this doesn't exactly make sense, but with regards to different tasks, what are some additional reasons to require full isolation? (as different worktrees would provide)
I would love something similar that lets me plug in actual Claude Code/Codex with their original agent loop, prompting etc, and just handles the multiplexing, worktrees, isolation, etc automatically (it looks like this tool doesn’t support that). Because I think a lot of the power of eg CC comes from the engineering they’ve done to the tool rather than the underlying model.
How are people doing this at the moment?
I started building it out that way but found it very challenging to create parity between the models. E.g. they have different tools, system prompts, interruption semantics, cost tracking etc. The spirit of the product is decoupling the LLM from the UI, so we went with a custom loop / tools that can perform decently across all models.
I have not yet tried either one, but here is the other project for those who want to compare and contrast them:
https://github.com/manaflow-ai/cmux
Very similar features, Catnip is Claude Code specific and does everything in a Docker container so you can more safely run in YOLO mode and the Git worktrees don't make a mess on your host filesystem or checkout. Also is mobile responsive which is cute.
https://github.com/paradise-runner/kaleidoscope