_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Show HN: Emdash â Open-source agentic development environment
MustafaYenler wrote 1 hour 30 min ago:
Love the fact that I can seamlessly switch between Codex for heavy
backend stuff and Claude code for everything else.
Soon Gemini for Frontend.
twocommits wrote 2 hours 48 min ago:
Yawn. "Agentic bla bla" seems to be the current new "Here's my
*-lang.org" thing...
yagizdegirmenci wrote 4 hours 31 min ago:
Congrats on the launch!
How does it compare to [0]Superset?
[0]:
HTML [1]: https://superset.sh
mjrbds wrote 4 hours 56 min ago:
I've been using this. Super useful, much better to avoid flipping
between agents
arnestrickmann wrote 2 hours 27 min ago:
Great to hear!
ferfumarma wrote 5 hours 22 min ago:
Why mit license?
If gpl is a blocker for users then offer them a paid license with the
exceptions they want. But MIT allows a commercial entity to ingest your
code, close source it, and commercialize it .
GPL-3 (with the option of custom commercial licenses) seems strictly
superior to MIT in this respect. Can you help me understand why this
choice is so popular?
touristtam wrote 5 hours 50 min ago:
I've tried to load tasks that were refined locally, but that turned
into a bunch of shell scripts to access the local DB. Will you support
that until you provide a way to do the planning phase in the UI?
---
Also I've loaded 78 tasks and the UI is crawling to a halt
bhekanik wrote 5 hours 56 min ago:
The worktree isolation is clever, but I'm curious about the security
model when you're running multiple agents in parallel with shell
access.
In my experience running CLI-based agents, the biggest risk isn't the
agent "going rogue" in the sci-fi sense â it's context window drift
during long sessions. Agent compacts its history, loses track of which
worktree it's in, and starts editing files in the wrong branch. Or
worse, running tests against the wrong database.
Git worktrees help with file isolation, but they share the same .git
directory and can still interfere with each other during concurrent
operations (rebases, reflog contention). Have you run into this with 5+
parallel agents?
The native CLI approach is smart for staying current with provider
features, but it does mean you're trusting each provider's sandboxing.
Some are better than others. Claude Code's allowlists are reasonably
paranoid; others less so.
Nice to see someone building tooling for this workflow rather than
trying to replace the terminal entirely.
philipwhiuk wrote 6 hours 2 min ago:
How do you prevent the agents 'going rogue' through compactification or
similar?
What security context do they run in?
fiehtle wrote 9 hours 58 min ago:
one step closer to talking to an army of agents while doomscrolling x
jofzar wrote 11 hours 22 min ago:
Came to say killer name.
Bishonen88 wrote 12 hours 20 min ago:
Custom AI tools like these have an uphill battle to fight. Automaker[0]
from webdevcody is an example of that. He, together with some other
folks created an open source Agentic Coding tool (for the lack of a
better term), which gained popularity on github. He was
advertising/showcasing it on streams etc. A few weeks in, he posted a
video[1] where he speaks about why he's not using it himself anymore
and went back to Claude Code, which over time receives
tools/skills/mcps/whatnot and is in the terminal which we're all
familiar with.
I made similar experience. Downloaded all sorts of tools, IDE's for the
new era of development. Other than claude code in cli and occasional
uses of codex (because have free tokens), nothing else stuck. I can
just split my terminal effortlessly how many times I want, write/speak
to the terminal with any custom request etc. And once someone comes up
with a clever idea on top of what claude has today, I reckon they'll
add it one way or another within the next weeks.
bayesian curve meme fits here rather well:
- claude code for everything, custom IDE's/tools, claude code for
everything.
[0] [1]
HTML [1]: https://github.com/AutoMaker-Org/automaker
HTML [2]: https://www.youtube.com/watch?v=3H_t78QcueA&t=382s
kzahel wrote 13 hours 32 min ago:
Will you add remote / a mobile control plane? I love your approach of
using CLI. [1] has a similar approach but it's mainly about access via
mobile. [I'm frequently away from my desk]
Ah, actually after looking at your approach, I see you don't use any
agent SDK or --json outputs. You just embed a terminal window. That
makes mobile interfaces a non-starter. I can see why you are only
focusing on desktop, it makes integrating with more providers easier.
HTML [1]: https://yepanywhere.com/
siscia wrote 14 hours 33 min ago:
I just made an app that read GitHub issues. If they have a specific
tag, the agent in the background creates a plan.
If they have another tag, the agent in the server creates a PR
considering the whole issue conversation as context (with the idea that
you used the plan above - but technically you don't have to.)
If you comment in the PR the agent start again loading your comment as
context and trying to address it.
Everything is already in git and GitHub, so it automatically pick up
your CI.
It seems simpler, but I am sure I missed something.
akrauss wrote 14 hours 34 min ago:
Does emdash also help making the setup secure by isolating the agent
from my local environment? This is more than just git worktrees.
Or do you consider this orthogonal to what emdash attempts to do?
freakynit wrote 16 hours 59 min ago:
Can I use emdash to build another emdash?
jorl17 wrote 17 hours 0 min ago:
Hi! Congratulations on building something new!
I'm going to look into it soon, but since you might be hanging around
here, I'll ask: do I have a quick way of telling the system how to
actually creating a worktree efficiently?
Here's my problem: I want to do manual testing for several things,
especially frontend related ones. However, every worktree needs its own
ports, and specific particularities (e.g. so docker volumes don't
collide). `git config --worktree` is supposed to help with this (and
I'll be looking at it pretty soon), but it seems very primitive.
Is there a way for me to tell Emdash: "Hey, when you create a new
worktree, you need to run this script"?
Thanks in advance and, once again, congrats on building something new,
clearly in the direction we are going.
onecommit wrote 16 hours 20 min ago:
Yes! By default, every new task runs in its own worktree. In the
.emdash.json config (or in the UI on your project page), you can
specify setup, run, and teardown scripts -- pnpm install, pnpm run
dev, etc.
We also inject convenience env vars into every task. For example,
$EMDASH_PORT gives each task a unique port, so you can do
PORT=$EMDASH_PORT pnpm run dev and never collide on dev servers.
More here [1] -- does that help?
HTML [1]: https://docs.emdash.sh/project-config
jorl17 wrote 16 hours 0 min ago:
THANK YOU!!
This seems like just what I was looking for â amazing!!
I hope I have the time to test-run it over the coming days.
If this really ups my ante, I'll get the whole team using it at our
studio. Looks promising!
arnestrickmann wrote 15 hours 56 min ago:
Sounds amazing!
Let us know if there are any issues or what we can do better!
nerder92 wrote 18 hours 26 min ago:
We are experimenting with this kind of development style and from my
experience so far this shift a lot of the complexity of building into
the story writing and manual testing phases.
As I will need to fully handover the task and let the agent(s)
essentially one-shot the implementation I need to be way for specific
and clear in giving it context and goals, otherwise Iâm afraid it
will start build code purely by accumulation creating a pile of
unmanageable garbage.
Also changes which requires new UI components tend to require more
manual adjustments and detailed testing on the UX and general level of
polishing of the experience our users expect at this stage.
Iâm starting to develop a feeling of tasks that can be done this way
and I think those more or less represent 20 to 30% of the tasks in a
normal sprint. The other 70% will have diminishing returns if not
actually a negative return as I will need to familiarise with the code
before being able to instruct AI to improve/fix it.
From your experience building this, whatâs your take on:
1. How do your product helps in reducing the project
management/requirements gathering for each individual tasks to be
completed with a sufficient level of accuracy?
2. Your strong point seems to be in parallelisation, but considering my
previous analysis I donât see how this is a real pain for a small
teams. Is this intended to be more of a tool for scale up with a stable
product mostly in maintenance/enhancement mode?
3. Are you imagining a way for this tool to implement some kind of
automated way of actually e2e test the code of each task?
onecommit wrote 17 hours 43 min ago:
Thanks! What tools have you been experimenting with?
Agreed. That this evolution pushes much of the work into describing
desired outcomes and giving sufficient context.
To your questions:
Emdash helps reduce the setup cost of each environment by allowing
you to open an isolated git worktree, copying over env variables and
other desired context. And then preserving your conversation per
task. That said, you still need to write clear goals and point it in
the right direction.
I think it's less about team scale and more about individual
throughput. My working mode is that I'm actively working on one or
two tasks, switching between them as one runs. Then I have a long
list of open tasks in the sidebar that are more explorative, quick
reviews, issue creation etc. So for me it's not about one-shotting
tasks, but instead about navigating between them easily as they're
progressing
Automated e2e testing is tricky, particularly for rendering. I think
roborev ( [1] ) is moving in the right direction. Generating bug
reports synchronously per commit and not just once you create a PR. I
also think what [2] shipped today with computer-use agents testing
interfaces is very interesting.
HTML [1]: https://github.com/roborev-dev/roborev
HTML [2]: https://cursor.com
dpweb wrote 18 hours 57 min ago:
Gorgeous UI! Will try it out.
ck_one wrote 18 hours 57 min ago:
Wild how quickly developer workflows change. I went from cursor ->
claude code CLI -> emdash (mix of claude code and codex now)
ttoinou wrote 19 hours 18 min ago:
Will you support Gitlab Issues ?
onecommit wrote 18 hours 58 min ago:
We could! Do you use them?
ttoinou wrote 12 hours 24 min ago:
Yes !
thatxliner wrote 19 hours 50 min ago:
Isnât there vibe kanban?
rockostrich wrote 19 hours 31 min ago:
This is essentially just setting up an MCP connection to your kanban
provider and instructing the agent to plan out an epic. I did this
this morning for some data modeling our team needed to do. For the
most part it generated a good set of tickets, but there were some
hallucinations due to ambiguity. Reviewing the already written out
tickets was much better than writing them out myself.
But the standard that will hopefully take over in most mature shops
is spec driven development where instead of a team reviewing code,
they review a spec which is used to generate tasks and subsequently
code to satisfy the spec. Then 2 kanban boards exist. One for writing
and submitting specs and another for the agents themselves to
implement the approved specs.
chris_money202 wrote 19 hours 57 min ago:
Great name
Obertr wrote 20 hours 5 min ago:
Love the tool! where do i send feedback?
arnestrickmann wrote 19 hours 54 min ago:
Thank you!
We have a Discord server [1] - but also there is a feedback modal in
app that you can use!
HTML [1]: https://discord.com/invite/f2fv7YxuR2
solomatov wrote 20 hours 27 min ago:
Could you compare it to other similar software? E.g. Codex App,
Conductor, and others? Why your app?
onecommit wrote 19 hours 51 min ago:
We connect to remote servers via SSH, are provider-agnostic, and
open-source. e.g. in Codex you can only run OpenAI models and not
Gemini, Amp, you name it. Give it a spin :)
ahmetd wrote 21 hours 28 min ago:
very cool!
martinald wrote 21 hours 51 min ago:
Please codesign your Windows installer exes :)
onecommit wrote 21 hours 47 min ago:
On it! Released windows out of beta yesterday. signed version
sometime this week
martinald wrote 21 hours 36 min ago:
Thanks. Btw, doesn't work at all for me. I installed, tried to
connect to my WSL2 instance on localhost via SSH, which worked.
Selected a folder and got Claude Code is not installed (it is very
much installed :)).
Then tried running the Linux version on WSL2 (not ideal because the
wayland server on WSL2 is slow) - doesn't work. This 404s: [1]
Grabbed the version before and got "PTY unavailable: ... was
compiled against a different Node.js version using
NODE_MODULE_VERSION 127, this version requires NODE_MODULE_VERSION
123".
Hope you can fix the bugs. I love Conductor on my Mac, but I need
something for my WSL2 machine. Ideally Windows which can SSH into
WSL2 (for UI speed) or runs on Linux itself. This is very close to
what I need if you fix the bugs :).
HTML [1]: https://github.com/generalaction/emdash/releases/download/...
onecommit wrote 20 hours 16 min ago:
Thank you for flagging! We had a CI bug in v0.4.16 that caused
the compilation error that we patched in the latest release
(v0.4.17). I created a ticket for the provider detection on
remote servers. On it!
ttoinou wrote 22 hours 23 min ago:
So, what's your business model ? Is this an YC product, or a tool you
developed while working on a YC product ?
onecommit wrote 22 hours 13 min ago:
We're figuring our business model out. There're two avenues that we
principally think about (1) bundled coding agent subscription and
(2)enterprise version with auth, team management, sharing of agent
interactions. Admittedly, it's early and this can change. What won't
change is that this UI layer for running multiple coding agents is
and will be open-source. Emdash itself is funded by YC. Initially
developed as a tool while working on another product, but we weren't
funded then.
ttoinou wrote 22 hours 8 min ago:
(2) sounds like a great idea if you can ensure private company data
never reaches your servers, with features like remote controlling
agents from a central place
onecommit wrote 22 hours 5 min ago:
Thank you, and yes!
bketelsen wrote 22 hours 28 min ago:
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.
arnestrickmann wrote 21 hours 14 min ago:
Hey! We pushed a fix for this. Let us know how it goes!
bketelsen wrote 18 hours 42 min ago:
super quick turn around. Left a GH issue, need to bump internal
package version to match deb version:
HTML [1]: https://github.com/generalaction/emdash/issues/1091
onecommit wrote 22 hours 12 min ago:
looking into this! Thanks for flagging
mccoyb wrote 23 hours 9 min ago:
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.
onecommit wrote 22 hours 59 min ago:
Interesting thoughts - thank you! And directionally agree - given
that agents are becoming ever better, they'll take more and more of
the orchestration on themselves. Still, we believe that developers
need an interface to interact with these agents; see their status and
review / test their work. Emdash is our approach for building this
interface of the future - the ADE :)
blumomo wrote 22 hours 24 min ago:
> Still, we believe that developers need an interface to interact
with these agents;
CLIs like claude code equally improve over time. tmux helps running
remote sessions like there were local.
Why should we invest long time into your âADEâ, really?
> see their status and review / test their work
Wonât that be addressed eventually by the CLIs themselves?
Maybe youâre betting on being purchased by one of the agentic
coding providers given your tool has long term value on its own?
sothatsit wrote 18 hours 46 min ago:
People use UIs for git despite it working so well in the
terminal... Many people I knew at uni doing computer science
wouldnât even know what tmux is. I would bet that the demand
for these types of UIs is going to be a lot bigger than the
demand for CLI tools like Claude Code. People already rave about
cowork and the new codex UI. This falls into the same category.
leondri17 wrote 23 hours 14 min ago:
LFG!
straydusk wrote 23 hours 16 min ago:
Pretty sick. How do you compare yourself with Conductor?
onecommit wrote 23 hours 10 min ago:
Conductor is definitely in the same space. Main points of
differentiation that I am aware of are that we allow you to connect
to remote servers via SSH, natively embed many more coding agents
(21) with their full functionality, and are open-source.
haimau wrote 23 hours 33 min ago:
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]
HTML [1]: https://github.com/generalaction/emdash/releases/
timsuchanek wrote 23 hours 43 min ago:
Let's go! Love that this is a solid OSS alternative to what's already
out there!
redrove wrote 23 hours 48 min ago:
Is this another VSCode fork? I canât tell from the readme.
onecommit wrote 23 hours 39 min ago:
Not in its purest sense! We're using the monaco editor for file
editor and diffs, but other than that no VScode included. The file
editor is really a secondary view inside of Emdash. The focus is on
the chat with the coding agent. We'll make this more clear in the
readme. Thanks for the feedback!
kzahel wrote 11 hours 45 min ago:
Judging from the installer sizes it's electron, not tauri?
ahmadyan wrote 23 hours 52 min ago:
Congrats on the launch
thesiti92 wrote 1 day ago:
i'll have to give it a shot, the market needs an open source cursor
right now
onecommit wrote 23 hours 57 min ago:
great! send all feedback our way :folded_hands:
selridge wrote 1 day ago:
Looks cool! Thank you for sharing.
FiloVenturini wrote 1 day ago:
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?
onecommit wrote 1 day ago:
We've considered it! The way we're seeing it, this is something that
the CLIs themselves are getting good at natively, such as Claude
Code. We generally consider ourselves to be at a higher abstraction /
task level, where the individual CLIs are responsible themselves for
breaking down and distributing a larger task across subagents.
das-bikash-dev wrote 1 day ago:
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?
onecommit wrote 1 day ago:
Thanks for your questions! You can separate the agents in Emdash by
running them on separate git worktrees so they can do concurrent
modifications without interfering. We don't support custom agent
wrappers currently, interesting. Have you written your own? What is
your use case for them over native CLIs?
esafak wrote 1 day ago:
> Each agent runs as a task in its own git worktree
If you're talking about shared services, that's another matter.
DIR <- back to front page