if agents continue to get better with RL, what is future proof about this environment or UI?
I think we all know that managing 5-10 agents ... is not pretty. Are we really landing good PRs with 100% cognitive focus from 5-10 agents? Chances are, I'm making mistakes (and I assume other humans are too)? Why not 1 agent managing 5-10 agents for you? And so on?
Most of the development loop is in bash ... so as long as agents get better at using bash (amongst other things), what happens to this in 6 months?
I don't think this is operating at a higher-level of abstraction if agents themselves can coordinate agents across worktrees, etc.
show comments
haimau
Been driving my agents (CC, currently testing Pi) for a couple of weeks via Emdash. Finally, got a productive worktree setup working. There were still rough edges when I started, but the team has shipping fast [0] and is vaporizing concerns on the fly. Building on top of the native CLI seems to be the right strategy as well.
So, what's your business model ? Is this an YC product, or a tool you developed while working on a YC product ?
show comments
snowhale
the worktree pre-warming detail is interesting -- keeping a reserve pool and letting new tasks claim one instantly is the same pattern as connection pool pre-warming in databases. the underlying bottleneck is probably git having to traverse pack files and update the index when you run 'git worktree add'. one thing worth trying if you haven't: sparse checkout on the worktrees can cut that initialization time further, especially in large monorepos where most files are irrelevant to a given agent task.
show comments
bketelsen
this looks great, but can't test, the .deb package is broken with an issue about NODE_MODULE_VERSION mismatches. There seems to be a PR waiting for approval. Will keep an eye on it.
show comments
martinald
Please codesign your Windows installer exes :)
show comments
ahmetd
very cool!
FiloVenturini
Have you considered adding any kind of agent coordination layer, e.g. letting one “orchestrator” agent spawn and direct sub-agents on specific subtasks, rather than having the developer manually assign each task? Or is the explicit human-in-the-loop assignment a deliberate design choice to keep control and avoid runaway costs?
show comments
das-bikash-dev
How does Emdash handle state management when running multiple agents on the same codebase? Particularly interested in how you prevent conflicts when agents are making concurrent modifications to dependencies or config files. Also, does it support custom agent wrappers, or do you require the native CLI?
show comments
timsuchanek
Let's go! Love that this is a solid OSS alternative to what's already out there!
straydusk
Pretty sick. How do you compare yourself with Conductor?
show comments
thesiti92
i'll have to give it a shot, the market needs an open source cursor right now
show comments
selridge
Looks cool! Thank you for sharing.
ahmadyan
Congrats on the launch
leondri17
LFG!
redrove
Is this another VSCode fork? I can’t tell from the readme.
Here's my question:
if agents continue to get better with RL, what is future proof about this environment or UI?
I think we all know that managing 5-10 agents ... is not pretty. Are we really landing good PRs with 100% cognitive focus from 5-10 agents? Chances are, I'm making mistakes (and I assume other humans are too)? Why not 1 agent managing 5-10 agents for you? And so on?
Most of the development loop is in bash ... so as long as agents get better at using bash (amongst other things), what happens to this in 6 months?
I don't think this is operating at a higher-level of abstraction if agents themselves can coordinate agents across worktrees, etc.
Been driving my agents (CC, currently testing Pi) for a couple of weeks via Emdash. Finally, got a productive worktree setup working. There were still rough edges when I started, but the team has shipping fast [0] and is vaporizing concerns on the fly. Building on top of the native CLI seems to be the right strategy as well.
[0] https://github.com/generalaction/emdash/releases/
So, what's your business model ? Is this an YC product, or a tool you developed while working on a YC product ?
the worktree pre-warming detail is interesting -- keeping a reserve pool and letting new tasks claim one instantly is the same pattern as connection pool pre-warming in databases. the underlying bottleneck is probably git having to traverse pack files and update the index when you run 'git worktree add'. one thing worth trying if you haven't: sparse checkout on the worktrees can cut that initialization time further, especially in large monorepos where most files are irrelevant to a given agent task.
this looks great, but can't test, the .deb package is broken with an issue about NODE_MODULE_VERSION mismatches. There seems to be a PR waiting for approval. Will keep an eye on it.
Please codesign your Windows installer exes :)
very cool!
Have you considered adding any kind of agent coordination layer, e.g. letting one “orchestrator” agent spawn and direct sub-agents on specific subtasks, rather than having the developer manually assign each task? Or is the explicit human-in-the-loop assignment a deliberate design choice to keep control and avoid runaway costs?
How does Emdash handle state management when running multiple agents on the same codebase? Particularly interested in how you prevent conflicts when agents are making concurrent modifications to dependencies or config files. Also, does it support custom agent wrappers, or do you require the native CLI?
Let's go! Love that this is a solid OSS alternative to what's already out there!
Pretty sick. How do you compare yourself with Conductor?
i'll have to give it a shot, the market needs an open source cursor right now
Looks cool! Thank you for sharing.
Congrats on the launch
LFG!
Is this another VSCode fork? I can’t tell from the readme.