That said, the current UX is pretty confusing.

There’s a mismatch in visual hierarchy: selecting an agent in the sidebar appears to change the entire editor’s worktree/branch, but the worktree/branch selector lives in the window titlebar, which strongly implies it controls the whole window. So it’s unclear which is the source of truth—the agent or the window.

That ambiguity shows up in the workflow too. If I want to create a new branch/worktree and then start an agent on it, I can’t do that directly. I have to:

1. create an agent 2. start a conversation (to instantiate it) 3. then switch the branch/worktree

That ordering feels backwards—I’d expect to define the context first, then start the agent.

Even basic navigation is unclear. If I switch the branch in the titlebar, does that affect the current agent, or the whole window? If I want to return to a previous worktree, is that tied to the agent or not? I still don’t have a solid mental model.

It feels like there are two competing concepts:

* agents as independent workspaces * the window as the workspace

Right now they overlap in a way that’s hard to reason about.

The feature has a lot of promise, but the current UX makes it difficult to predict what’s going to happen, which makes it hard to rely on.

Is the pricing transparent and, if so, what is it?

> Elixir when they invariably stumble across the things in erlang — libraries and the like. I'd hoped I could avoid it myself, but it's too interdependent.

This hasn't been true in my experience. I'd be curious to hear which Erlang libraries the OP has been using.

For anyone looking at alternative for threaded messages and find Slack's threads insufficient, our team loves Threads. We looked at a few others (Zulip, Twist) and landed on Threads about 2 years ago. Since then, the product has gotten better and better.

Also, haven't posted to HN much -- is this an appropriate thing to post on a thread like this?

As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.

As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.

After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.

We've also experience the great performance and reliability shared by others on this

We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.

[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...

However, when I look at your docs, it's not clear it's a different in approach from Remirror. The imports are all from bangle.dev which makes it seem like the same approach.

I would love to see a doc explaining the "API overhead" and how to use PM directly. I want to feel confident I can easily drop back down to PM if Bangle doesn't have a feature I need or implements it in a way that won't work for our use case.

Really excited to see this approach! Shared PM plugins are a great idea!