Delta

I think Zed is an excellent editor (fast!) with a pretty good AI agent built-in, but I have no desire to do multi-player development in my editor. Never have had any such desire. Coding is a single-player game and I can't think of a single thing that would be improved by having someone else in the same editor.

So, this seems like a lot of work on really cool tech for no useful purpose at all?

Are there people crying out for a multi-user code editor? I mean, we have to have code reviews, sure. That involves other people or other agents. But, I don't need to stand over someone's shoulder while they work. That seems like the worst thing in the world for everyone involved. I don't want an audience for my dumb looking experiments because I forgot how to do something.

Does anyone else hate reading AI summaries of code? Code can be pithy, but at least its terse compared to prose. When you add how verbose LLMs can be, I often end up reading a paragraph to explain a few lines. Or the opposite happens where the summary skips important edge cases or criteria. "You're right, X also does Y. I missed that in my initial analysis," is much too common of a phrase.

I like the idea of using LLMs to transform code into something more readable, and vice versa. I am not sure if meandering paragraphs and linear lists are the best targets.

This is intriguing. The two relevant features seem to be 1) realtime collaborative multiplayer conversations and 2) conversation-as-document - basically, letting you comment inline in an agent conversation.

For (1), the main value I'd see is in mentoring junior engineers or less technical contributors on a team. If someone puts up a PR with sloppy results, you could actually jump into the thread that produced that PR and see how the results came about, or even coach that contributor on how to do better next time. Also might make it easier to hand off work from one person to another - right now most coding agent sessions are user-local.

On (2), I frequently find myself consuming agents' gigantic text responses and tediously writing 8-bullet-point responses to guide them. It's pretty exhausting. I could see inline comments providing much better ergonomics.

All that being said, Zed has largely fallen out of the conversation for "agentic coding tools", and so this feels like their attempt at creating something like the Cursor Agents Window, Codex, or Claude Code. These two features seem compelling, and I understand they're even compatible with other coding harnesses. But I don't know if there's enough there to have a defensible product; if these features are excellent, others will clone them eventually.

Regardless, would love to give this a shot!

Off-topic:

Sorry, my brain just fried trying to read the post.

Aside from the H1 and H2 headers, nearly everything on the page is ultra-low contrast.

Darkish gray text combined with the faded gray background, along with the (nearly) undetectable highlight makes for a terrible reading experience. I'm sorry, but somebody has to say it.

Surely it can't just be my own eyes that are squinting to see the images and the small text therein? The page design as such is fairly minimal with bold blue theme; would it hurt to add a bit more contrast to the typography?

Thanks

/offtopic

I'm sure this seemed like a great idea a year ago (they first mentioned it with their Series B).

But a lot has changed in those 12 months.

Frontier models and coding agents have advanced so much that I don't really see much value in this anymore.

Not sure the DeltaDB based features really add anything significant compared to the alternatives.

I reckon the game here has to be adding a service that stores the data and runs agent sessions?

This does look legitimately exciting. A surprisingly large pain point when doing agentic work has been commenting on something in a larger plan document. I always find myself summarizing the surrounding text to contextualize a comment when all I really want to do is highlight and click "add comment".

Unrelatedly, I have been looking at Zed to centralize my agentic work at $job, where we use different API keys per project to better attribute spend and control model availability based on per-project data protection controls. All of the standard UIs I've tried for this don't really work, but the CLIs mostly do. Using ACP in Zed I was able to bridge that into the UI world and I'm quite happy with it.

I signed up for the beta and I look forward to trying it.

I don't quite get it - it reminds me of using Slack as the decision making places, sure it works for hashing out the details, but it's not great for being the decision record store. I'm not sure what is the value of preserving hundreds of lines of conversations about how code came to be if the code keeps changing? What happens in 5 years? Do I have to read the whole transcript just to understand what's going on? AI will summarize it for me?

This feels like engaging with a prog lang community for the first time, and answer to a basic question is "this has been covered before, read the IRC chat history"

It's not like Pull Requests are perfect, and with discipline they do the job well - but this looks like a step in the wrong direction.

My personal hatred of LLMs aside, an I the only one who thinks "saving the conversation" is an incredibly naive and useless approach?

The conversation may have been long and meandering, for legitimate reasons, but what matters is the decision you reached at the end and the reasons for the choice.

If your project cares about those things, they should be captured in your specifications / docs / ADRs, in a concise form that respects the reader's time.

If you don't care about why the choices were made, then why save the discussion in a fancy database at all?

I guess everyone's just too cool to actually write good docs now?

(I've had some runins with the auto-generate specs based on LLM chats tools lately, like OpenSpec and an internal equivalent, and boy do I have some choice words about them. So much verbosity for so little clarity...)

So, DeltaDB is not for Zed, but for an entirely new product? At least it won't bloat the editor...

Nevertheless another Zed post, another plea to focus on basics https://github.com/zed-industries/zed/discussions/54150 [how can developers work with agents in zed when developers cannot see files agents create] best luck to Delta but please do not neglect the text editor!

Nathan is on today’s Syntax episode talking about Rust and Zed and Delta:

https://podcasts.apple.com/us/podcast/syntax-tasty-web-devel...

> We could have added DeltaDB to Zed, and eventually we will. But the best possible experience required an entirely new kind of application

The following demo is a version of a text editor - a chat window and a diff. How would building a new limited text editor be the best possible experience? Like you've setup your Zed schemes/keybinds to your liking, why would jumping to a totally different app improve your experience?

I feel like for a little bit I was worried about Zed's ability to stay up to date in the cli coding agent-focused market, but it seems like every time they publish a new product release, it's always very compelling. I feel like they're one of the more promising companies innovating in the space of human-AI interaction, and I'm very excited to see where they go from here. I hope they launch a web-accessible or mobile-accessible app one day. I've been enjoying being able to code from Termux on my phone over SSH or using any of the browser-native orchestration systems.

As an indie dev, I'm not really in a position to judge Delta's potential for large-scale collaboration. Maybe Delta will end up being great for teams of all sizes. But I really wish they'd put more care into Zed's core editing experience. In my opinion, Zed has so many bugs and rough edges that it's hard to consider it software that deserves a 1.0 version number. Also, there's still no timeline in sight for GPUI to become a standalone project...

Interesting, I've been looking at this space with a realization that there's a big piece of UX missing to enable groups of people to collaborate with AI support.

Basically most companies and teams spend a lot of time talking to each other. It's why I like small teams. It just leaves a lot more quality time for getting stuff done. But even in a small team, you need to communicate.

So, multiplayer AI coding actually makes a lot of sense. Instead of handing off via traditional tools (issue trackers, version control), why not invite a colleague to some ongoing coding session. The AI has full context there. It could actually decide by itself to invite your colleague. So instead of throwing a PR at a colleague, you transfer the full context of the work and your colleague maybe does some fine tuning and checking before creating the PR.

Or you could pair prompt on a more difficult chunk of work. Or you could create sub threads with different people involved. It's all about having a shared context. And actually knowing what was asked or how the system was prompted is as important as what was generated. Prompting is now a big part of how software development process. So why only review the output as a team? Prompting is where the big mistakes get made. Prompting effectively is what you need to teach junior developers now. Doing it in the context of a team chat tool, makes it easier to mentor, supervise, pair, etc.

Interesting in this context is that Anthropic hired all the leadership behind Zulip (an OSS team chat tool) a few months ago. That suggests they might be working on this exact topic.

I have been testing the alpha for the last few weeks. It's very good, especially compared to tools like Conductor. Very bullish on where Zed will take Delta!

Would be nice for Zed to announce something that was immediately available for use.

Have been following this for a while, but honestly still not exactly clear to me who/what this tool is meant for

After all, we already have safe conccurent edits, etc via regular git tooling

To me it this seems a bit backwards looking. Increasingly code review is more on verifying the functional requirements, and less about reading every line an agent has written (or watching it write those lines live)

I really liked Zed for a couple of months, when AI tab code completion was the frontier. But now I don’t hand-edit files anymore, so Zed is mostly a fast file reader for me.

I understand why a team focused on an editor would do this, because they have to figure out where to fit into this new world. I guess I’m mostly looking for a product now that lets me review large amounts of code easily, add comments, and interact with many agents working on the same codebase in worktrees (or similar) at once. I’m unsure whether this would be something like that?

I assume they gonna have pull us a "arc" rag pull.

Zed is going to die 'cause they cant capitalize on it, delta is going to be sold to investors, and then zed is gonnabe closed sourced 'cause now they need it as the engine for this hot mess.

Perfect! Luckily I sticked with Vim!

Honest question, do any of you actually use this type of multiplayer feature in editors? I have worked on small, medium, large and FAANG(Google and Amazon) companies. Never have I seen anyone, even talking about coding with somebody else in the same editor.

Edit: grammar

I was hoping Zed will do a really good built-in diff editor with AI notes and comments, like https://github.com/modem-dev/hunk Perhaps this is going into this direction?

I kind of like the Hunk workflow for reviews (of both AI and human-generated code), you basically tell the agent "walk me through the diff by annotating and controlling this diff viewer". If it could control Zed diff views it would be even better.

This is a really cool idea. So much context is lost within agent conversations these days, and it requires far too much discipline to have the conversation between you and your agent in a shared place like GitHub (plus, thee conversation isn't always just a comment and response - it's... an actual conversation).

I'm very glad to see folks innovating in this space.

I feel like I have to call out Zed for still having completely broken LLM support in almost entire continent of Asia for over a year now with no official response¹ just because they can't route http requests. Bad look for their LLM workflow push.

https://github.com/zed-industries/zed/issues/29962

Zed in Identity crisis.

I see this link from zed and immediately know it must be something agentic to be on the front page of HN

HN used to be the best tech source in the world, to discuss new ideas and non main stream unconventional tech, but now everything seems like AI this AI that

Even though Zed has done a lot of good work on improving the IDE experience, the only way I see it coming on HN top page is if they showed the AI, and that's too sad

You know it’s ironic that the first featured post showing up on the bottom is one where Zed proudly proclaims to not be doing AI just for the money that’s in it, and all posts that follow it are about AI too…

Does Zed even remember it is a code editor? Or are these guys just interested in building more AI slop to add to the never-ending pile? What even is Zed supposed to be at this point?

Has anyone figured out how to get agents to reliably rewrite an entire spec to not be a list of historical findings?

Ie convert a history roll into an actual spec?

I find my agents can’t figure this out. And they always do stuff like append 2026-05-10: BIG LOAD BEARING UPDATE blah blah to the end of documentation, which ultimately confuses the thinking trace of future agents.

I would expect the same thing to happen here if the thread gets too large.

I love zed but i wish they'd focus on the IDE for those of us that still love, write and read a ton of code for serious work. Webstorm continues to be better for TS, Goland better for Go and so on; Zed lacks too much of core functionality at the moment to be the main interface of choice

At the current pace of innovation, the 2020s might even see us catch up to where Google Wave was in 2009. Exciting times.

Zed is looking more and more prone to a fork by the day. :-/

Not to say no to innovation and experimentation in the age of LLMs, but meanwhile these get shipped, community contributions to sort basic filesystem events to ensure all files are monitored get sidelined without PR reviews and approvals for weeks/months.

Huh. The idea is interesting, but I don't understand the decision of keeping it chat-like: it looks like the mix of the worst parts of Google Docs and Slack, I struggle to see how this will help people track decisions.

This can be improved though - I think that simply a separate collaborative doc and a chat linked to that doc would work way better.

I have no use for this but it's actually a cool feature. Might use it on the job.

I'll have to give it a go to fully understand the use case, but I can't see the value in keeping the work-in-progress artifacts. The sharing aspect is niche, and I could see some use depending on team workflow. I guess it's one step better than "Claude said".

Doesn't appear to be opensource (and neither is DeltaDB, it seems), unlike Zed. Any plans to change that?

This sounds a lot like Grok [4.6] CLI. It already pings multiplayer style between multiple agents, and you can even request that it split large tasks into small chunks across agents to reduce context overload and it seems to do that very well.

Seems like "multiplayer AI" is the buzz word for next year, just starting to ramp up now.

This is so reminiscent of Cider (Google's internal cloud IDE) which had the best multiplayer support that I've ever seen. It was such a joy to pair program with a colleague on a different continent.

So the Zed team essentially sidelined numerous requests for a UI extension API to make something that will only ever be used in demos.

Good thing I can just fork the editor. This is how you lose the trust and goodwill of your users.

Multiplayer? It's a game?

Would be cool to have a single-user ADE tool like that from the Zed folks - because Kepler focuses a bit too much on the ticketing integration and Paseo sometimes has issues with sub-agents.