Seattle3503 3 minutes ago

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.

ttoinou 4 hours ago

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

  • _pdp_ an hour ago

    Given that all of these agents are written in javascript I have always wondered why they cannot simply use https://isomorphic-git.org/ and do everything in memory.

  • IanCal 3 hours ago

    This is a good point.

    Docker? I typically want other kinds of isolation for services and things anyway - it’s got its own file system, you could have N versions on the same branch working without conflict (at least the conflict you’d have with work trees).

    There is some more plumbing involved but…not much?

    Edit - task boards are my first thought for the comms side for agents sharing info.

    • ttoinou 3 hours ago

      Docker is very heavy and more for Linux, I'm on macOS and Windows for desktop software development and can't put my software to test inside Docker. But yeah I could have sandboxes inside macOS and inside Windows (virtualization, VMs, WSL etc.), I'd still need one main orchestrating agent + GUI to rule them all

  • Jhsto 3 hours ago

    What about using CoW file system snapshots and then mounting it on overlayfs as the lowerdir while having the agent's working directory be the upper directory? I wonder how the agent reacts to finding some files being immutable.

nojs 2 hours ago

This looks very useful.

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?

  • CuriouslyC 3 minutes ago

    Since CC is a terminal app you can spin up a container with your project, dependencies and CC already installed easily via docker, then just ssh in and run claude remotely. Tmux if desired. Save work by doing pull requests.

  • Coolin96 16 minutes ago

    I’ve been using (and loving) https://github.com/raine/workmux which brings together tmux, git worktrees, and CLI agents into an opinionated workflow.

    • jadbox a minute ago

      Oh this looks perfect. This feels like the Linux way to keep tools separated to their primary function. I don't want my MUX tool to do AI stuff, as I have other (better) tools meant for that.

  • widenrun an hour ago

    I'm using conductor.build and running both Claude Code and Codex. It's taken 95% of my workflow and I'm loving it (I'm not affiliated with them at all, genuinely enjoying it and hoping it succeed)

    • CuriouslyC 2 minutes ago

      Amazing to me all these apps duplicating well tuned Github functionality.

    • scottmf an hour ago

      Same here. Codex support is a recent addition however, and it’s not clear if MCP servers and other rules apply to Codex. Also it would be nice to be able to just have a session working on the main branch as concurrent work in worktrees can get messy