top | item 46501758

Show HN: Agentastic.dev is Ghostty and Git worktrees = multi-agent CC/Codex IDE

11 points| ahmadyan | 1 month ago |agentastic.dev

I’ve been tinkering with what a “multi-agent IDE” should look like if your day-to-day workflow is mostly in terminal (Claude Code, OpenAI Codex, etc.). The more I played with it, the more it collapsed into three fundamentals:

* A good TUI: Terminal is the center stage, with other stuff (CodeEdit, Diff, Review) baked on the side. I don’t like piping Agent’s output through some electron wrapper, here you get to run CC/Codex/Droid/Amp/etc directly.

* Isolation: agents shouldn’t step on each other’s toes. The simplest primitive I’ve found is Git worktrees. It is not as isolated nor heavy as containers/vms, but it is the next best thing for working locally. Each agent gets its own working directory and their own snapshot of the repo. Git worktree requires CLI kung-fu, but agentastic simplifies it through some nice GUI and keyboard shortcuts for easy creation/switching/etc.

* An excellent terminal: I couldn’t get comfortable with xterm.js (Code/Cursor/Conductor/etc), and i loved Ghostty, it is fast, pretty, and feels right. So naturally the whole experience is built around Ghostty (There is also SwiftTerm as an alternative option).

Agentastic.dev is a native mac IDE, built around the workflow of “one task = one worktree = one terminal session” as the default. You spin up multiple worktrees (branches) and run different agents in parallel, each with its own clean working directory and terminal session and codeedit, then review and merge when you’re ready.

We’ve been dogfooding it to build http://agentastic.dev itself and agentastic.com (coming soon), and it’s noticeably improved our productivity. https://pasteboard.co/xg1YOsk5MIn9.png

It’s early and still rough in places. I’d love feedback from people who use worktrees heavily or run multiple coding agents:

- What would you want from a multi-agent IDE that you can’t get from a terminal + tmux?

- What’s missing / annoying in your current worktree workflow?

22 comments

order

avree|1 month ago

Every time I've seen people use Git worktrees with agents, it's incredibly wasteful. What is the use case for running parallel isolated agents? Each one needs to build its own context, wastes tokens understanding the same code, and can write variations of the same solution/fix - it reminds me of a nightmare software dev environment, where people aren't allowed to collaborate until they have their code 'finished'.

frio|1 month ago

The use case is making them work on distinct tasks in parallel — just like an organisations developers each have (traditionally) their own laptop with its own isolated environment. So that I can say to agent 1 “clean up the unit tests in the payments module” and I can say to agent 2 “implement a simple client for Mailchip so that we can migrate off Sendgrid” and the two can work independently.

Note that I don’t work like this personally — I quickly get overwhelmed by the volume of context switching — but I can absolutely see the appeal; particularly for smaller shops.

jauntywundrkind|1 month ago

AI makes coding plans that often come up with phases. It can be interesting to ask it to skip a phase, and do the next one. You can get interesting data about prospective other futures.

IMO using subagents to generate good context is a huge win. That doesn't really require a worktree. But once you have good starting places, good contexts you can feed into a LLM, there's IMO not much concern about "build it's own context" (it's already provided right here) nor "wastes tokens" (since is GoodPut / GoodTokens).

the workflow of how we feel and build contexts is the art of this all right now. this project is on point. it's going to be a boom year for Terminal Multiplexing.

ahmadyan|1 month ago

few reasons:

* Agents take a while to get the job done, so you give a prompt and you have to wait anywhere between 10mins-2hours or longer for it to finish. So it make sense to have parallel agents working on different features of the codebase. for example recently Boris, creator of Claude Code, posted about this setup where he is running 4-5 parallel agents in different tabs. https://x.com/bcherny/status/2007179833990885678 I personally have 30-40 agents running in parallel locally, and at the bottle-neck is the memory on my local machine.

* Even for the same prompt, the way i use the agent is run multiple agents with the same prompt, and review and pick the best output (Essentially pass@k for coding agents). This is specially useful for harder tasks, where I give the same prompt to both CC, Codex, Droid, and my own coding agent. Each model/scafold has its own distribution, and they work better when they are in distribution. So by sampling more, we increase the chance of success. (I know this is wasteful, but we currently live in the world of abundance cheap tokens; so put those $200 subs to good use)

So if we push this to the limit, i think we can improve the generation problem by shifting the complexity toward the verification. i.e. if you have 4-candidate solutions to your problem that all pass the the tests, how do you review and pick the best. This is where the code-review comes in.

justanothermatt|1 month ago

Context building isn't the bottleneck -- developer capacity is. Tokens are cheap and getting cheaper, but dev cognitive bandwidth is fixed and expensive.

esafak|1 month ago

You don't want to use the same context for multiple tasks because performance suffers with context size.

lostmsu|1 month ago

The codebase can be added to the context once, the computation shared between parallel agents.

manquer|1 month ago

Monorepos , or rather in large enough codebases work can tend not to overlap

jimmydoe|1 month ago

> What would you want from a multi-agent IDE

I use Orbstack to run docker compose for worktree each with a distinct domain ( previously using Colima + Cloudflared for same reason ). Not that this has to be done by IDE, but not bad if that's offered.

ahmadyan|1 month ago

ack

i run .agentastic/setup.sh script on every newly created worktrees (doc: https://www.agentastic.dev/docs/how-to/git-worktrees) and we set a few env variables in that script (e.g. current-worktree-dir, etc) so your stack should be supported https://docs.orbstack.dev/docker/

don't have shut-down yet, but i can add it as well (i.e. cleaning up the env upon deletion)

would a pair of setup.sh/shutdown.sh cover majority of your workflow? what else is needed?

mrtesthah|1 month ago

Looks fun! Does it support devcontainers and/or any form of isolation? The app's purpose seems similar to that of Branchbox.

Also the website says it runs on macOS 13+, but the app's Info.plist sets LSMinimumSystemVersion to 14.0.

ahmadyan|1 month ago

not yet, just vanilla work-tree, so file isolation. I also poorly manage env isolation through running .agentastic/setup.sh script upon work-tree creation; which can setup .env files, etc.

I wasn't aware of branchbox, i was planning to integrate firecracker in the upcoming version. However Branchbox seems like a great option too.

Which set of container features / isolation matter to you more?

isoprophlex|1 month ago

Not dissing your work but... i can barely keep up with what a single agent is doing! Just thinking about herding five of them at a time makes me mildly nervous, haha

ahmadyan|1 month ago

I hear you, and totally agree. I had the exact same problem. My goal is to simplify the process (but not too much) and reduce the mental demands of running agents, by automating at least work-tree management and code-review a bit at. So devs can focus on what matters more, higher-level planning, design and spec.

jimmydoe|1 month ago

You might just get used to it. I have been thru the transition last October and now I feel I’m a different person. Sometimes I work on three trees at same hour; sometimes a work tree sits for two weeks im not touching but later decided to jump back in.

_boffin_|1 month ago

Question: How are you currently working with your single agent?