[HN Gopher] Show HN: FleetCode - Open-source UI for running mult...
___________________________________________________________________
Show HN: FleetCode - Open-source UI for running multiple coding
agents
Hi HN! I've recently been finding productivity in running parallel
CLI coding agents(after not believing in them initially). After
having to do a ton of git stashing and branch fumbling, I decided I
needed to something to more ergonomically run these agents in their
own dedicated spaces. I tried a lot of the existing products but
they either were too convoluted or flat out didn't work. Some of
them also seem to roll their own chat UI which I don't think is the
right approach, I wanted to something to lightly wrap my terminal
sessions. So I built FleetCode! It uses git worktrees and let's
you run multiple agents at once. It's made my multi agent coding
workflow much easier. It's free and open source, would love some
feedback!
Author : asdev
Score : 44 points
Date : 2025-10-08 18:00 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vorticalbox wrote:
| I normally just use multiple terminal tabs, but I never knew
| about worktrees; that's super useful.
| asdev wrote:
| yeah I was doing the same and it was working okay, but was hard
| to work in a truly parallel fashion due to agents making
| conflicting changes
| vorticalbox wrote:
| I tend to not do this often but I will certainly check out
| the project.
| denysvitali wrote:
| Why don't you join forces with https://happy.engineering/?
| asdev wrote:
| Looks cool! I don't personally have the need to code from
| anywhere besides my laptop though
| Galanwe wrote:
| Woah that's super cool, like that they describe clearly how the
| relay works and how to spawn yours.
| denysvitali wrote:
| Not sure if you're trolling:
| https://happy.engineering/docs/how-it-works/
| Galanwe wrote:
| I'm not trolling at all, I genuinely liked that it's not
| some pay-to-use, SaaS, startup or whatever, but an actual
| simple and functional tool, free, open source, documented.
| fabmilo wrote:
| nice, didn't knew this tool either
| skinnymuch wrote:
| I think it works thru a MCP to use it on your mobile device or
| am I mistaken?
| iamkoch wrote:
| Looks good! I'll give it a shot.
| asdev wrote:
| thanks! all feedback appreciated!
| bjacobso wrote:
| Take a look at https://conductor.build/ - they really pioneered
| this whole direction of using git worktrees. Cursor will soon
| look like their app, Opencode will soon look like their app, etc.
| asdev wrote:
| I tried that, I couldn't get it to authenticate properly since
| I need to run some commands before running claude code. I also
| don't like that they rolled an entire UI when the terminal UI
| is good enough, it's just the parallelization of workflows that
| needed automation. Git worktrees were launched in 2015
| bjacobso wrote:
| Sounds good
| asdev wrote:
| oh, and also closed source
| atonse wrote:
| I think if Atlassian could really build something like Vibe-
| Kanban right into JIRA, it would be absolutely incredible.
|
| Then we wouldn't need our Kanban board AND a separate board for
| just that.
|
| Or I guess if these tools integrated into JIRA and suggested
| tickets, that could be nice.
| asdev wrote:
| You should check out their MCP server:
| https://support.atlassian.com/atlassian-rovo-mcp-
| server/docs...
| ilteris wrote:
| Is this based on a single provider? Could you explain how it
| differentiates itself from competing solutions? Perhaps an end-
| to-end workflow walkthrough or a short video would be helpful to
| understand the process before attempting to implement it. Thank
| you for open-sourcing the code.
| asdev wrote:
| Not based on a single provider, I need to add more providers
| but basically supporting a provider is as simple as adding the
| relevant shell command for the CLI agent(claude for CC, codex
| for OpenAI etc). I'll try making a video at some point.
| jbentley1 wrote:
| I've built something very similar but am further along
| (https://github.com/stravu/crystal). I understand the desire to
| do your own thing, but if you are interested in joining forces
| and contributing I would love to have you. I think we were
| thinking along very similar lines.
| tecoholic wrote:
| I like that it's a UI.
|
| Dagger has a nice solution for this in this space called
| Container Use - https://container-use.com/introduction
|
| It does git worktree based parallelisation as well.
|
| Edit: Ah! I see you mentioned several tools. Sorry I saw the repo
| and immediately thought of container use as I have been planning
| to give it a go this week. Did you happen to try it too? And
| where did it breakdown?
| asdev wrote:
| I'll take a look. I think containers are overkill for my type
| of workflow. I'm working on a project where dependencies don't
| change often so I'm not worried about a CLI agent installing
| something on my machine and breaking things.
| osener wrote:
| This is cool, except I don't want to run multiple copies of my
| dev stack.
|
| GitButler does this cool thing where you can work on multiple
| branches at the same time, applied to the same working directory.
| For example you can work on the css while an agent works on the
| admin panel on a separate branch. It would be cool to have this
| with a tool like FleetCode.
| atonse wrote:
| I couldn't figure out this part of GitButler. I downloaded it
| and tried it (since I respect Scott Chacon and remember
| learning so much about Git from his well-written git guides).
|
| But it was just a bit too much cognitive dissonance for me to
| try it.
|
| It seems like the next big thing is parallel coding... I've
| tried GitButler, Spectator, Vibe-Kanban, and Conductor in the
| past week. And there is now FleetCode.
|
| I liked Spectator's idea (use a separate docker container for
| each) but it didn't quite work right. So back to worktrees
| which seem to work just fine.
|
| At some point, we will probably consolidate on 2-3 dominant
| tools in this space.
|
| I wonder if even work trees will be needed if we can do a
| "create a copy-on-write version of my code folder" which would
| result in nearly zero-cost copies of the repo.
| osener wrote:
| Somehow the GitButler workflow works great for me and it is
| the first VC software that made me drop Magit after a decade
| of daily use.
|
| I do not use it collaboratively. I use it to continuously
| ship smaller things while working on bigger pieces and I
| constantly move independent changes around to different
| "lanes" to ship frequently as parts of my work mature.
|
| With Magit I used staging area and amended commits
| continuously. With GitButler I "assign" files or chunks by
| dragging them into lanes as I am happy with the changes, and
| when I have a logical unit I commit it. Having this multiple
| staging areas has been a great workflow improvement as well.
| asdev wrote:
| can you elaborate why you don't want to run multiple copies of
| your dev stack? is it because you want to run your app from one
| place but be able to test multiple changes, vs having to
| install deps and start it from multiple folders?
| osener wrote:
| Former. Otherwise I would need to have multiple database
| instances running, each with its own data and migrations to
| keep in sync. Plus I would need to re-do local env vars to
| hook all of this up for each worktree etc. And I often want
| to know how these branches play together, with GitButler I
| can bring these branches in and out with a single "apply to
| workspace" click.
| asdev wrote:
| thanks for clarifying. I'll take a look into supporting
| this
| dgunay wrote:
| For anyone who either doesn't want a GUI-based workflow or wants
| a lot of custom behavior, I would encourage you to roll your own
| tool, either by yourself or with an agent. I did this at work and
| the tool became very usable in short order, building on itself in
| a virtuous cycle with built-in handling for the quirks of our
| engineering org and my own preferences. The codebase I ended up
| with was quite ugly, but the problem space of doing this for
| local dev is small enough to be manageable.
___________________________________________________________________
(page generated 2025-10-08 23:00 UTC)