Delta
zed.dev
zed.dev
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.
My personal experience is, of course, not representative of an entire industry, but I just have a hard time imagining it being a common thing. I like working with other people and helping juniors sort out their problems, but I'd quit my job if I had to take turns writing code while someone else watched and just sitting and watching someone else writing code. Both of those things seem horrible, to me.
'course we only did it for like 5 min to get him over the hump.
I think that's the only use case. It sucks having someone hover over you otherwise.
I've definitely used the live sharing session with VS Code in the past to help coworkers debug or give them some suggestions for how to structure things (usually giving Rust pointers to people newer to the language). I haven't done it in a while though, probably because nowadays people will just ask their agent rather than me.
I've never desired to have two people working on the same file at the same time during a debugging/teaching session.
We can just work together, talking and writing code. Works great with people you work well with and are aligned with.
Are we the only ones with this issue? Pair programming is unusable to us with VSC because of this.
Which is another thing that just does not compute in my mind as a concept, much like pair programming. Probably for the same reasons. That said, it's obviously very situational and personality-dependent.
When it's working I think it's absolutely great. Together we find the best solution in the fastest time with less errors along the way. I'm also less sloppy and more focused when someone constantly sees my work and vice versa. At the end of the day you can celebrate what you've done, both feel responsible for the work and knows exactly how it works.
The problem is you need to fully trust your collaborators, and that's really hard to find in this industry. Most people never find it. I haven't.
I've seen it though. It exists. Very rare. I know two guys who used to participate in Ludum Dare over 10 years ago who would have loved something like Zed if it existed back then.
By contrast, at your 9-5 where you don't know if your coworker is gonna stab you in the back for a promotion (which I suspect is most people in the comments here) then Zed is probably not a great tool. Git would be a better fit for that. After all it was made to develop Linux, which is one of the lowest-trust collaborative environments out there.
At my work 20 people are changing the same wiki-page when we do heavy regression tests. Works like a charm (not everyone is writing at the same place in the document since we are testing different things and writing results at different sections).
Uh yeah, it works amazingly well. I've done entire uni projects with Google Docs and it went great, and was much more convenient than whatever we did before using Google Docs
It works well enough that we occasionally used it for short chat conversations inside the document we were working on.
I could see it being useful if you're helping someone debug something, but chances are it's easier just to screenshare.
I even worked on a team where one engineer loved the idea and championed doing it as early as 2013. Most of these IDE extensions didn't exist back then. He ended up picking a buddy, and they moved to the same office, hooked 2 keyboards and 2 mice into the same PC and spend literally the entire day alternating who's writing code in the same IDE.
I think the concept was supposed to be about helping developers share their skills. Every developer has an experience of looking over somebody's shoulder and having an "oh shit, I didn't realize there is a shortcut/tool/command for that" moment. And the idea with multi-player programming is to get you to see that and learn from it more. But. It. Doesn't. Work.
Never found a use for this sort of thing once novelty wore off. :/
And lol yes! if you knew the dude who wanted to try that, you would know what an “extrovert” was. He was the most extroverted engineer dude I have met to date.
"You newer models are happy scraping the shit... because you've never seen a miracle"
Also see: https://subethaedit.net/
Sometimes I feel like people online hate all their coworkers. Thankfully, such people have not been highly represented amonst those I've worked with.
- antisocial people
- larpers and students and shit who don’t even have a job where they write code but comment like they do
- people who don’t do shit for 3/4 of the day and don’t want to be accountable for that
- people who work with too many idiots
Probably lots of other reasons. Personally I think it’s fun and useful, but I wouldn’t want to do it exclusively. Maybe scheduled hours a couple times a week. LLM aided development can be very similar experience.
Also a great teaching tool.
Big part of my job currently is taking slop level Pinocchio prototypes and turning them into a real boy. I’ve decided that I’d much rather have all of the conversations these people have had with Claude when creating the project than the final code artifacts. Hopefully we get more tooling in that direction.
ANTISOCIAL people doesn't care about society, are harmful towards other people, break laws, etc.
Dictionary definition #1 from dictionary.com for “antisocial”
> unwilling or unable to associate in a normal or friendly way with other people.
Furthermore, were you or the original pedant actually confused by what I meant? I seriously doubt it.
This idea that we need to be married to other co-workers throughout each day has all the same dysfunctional attributes as a nanny state or a daycare, where employees are treated as untrustworthy and needing to be monitored at all times.
The fact that talented engineers are able to contribute meaningfully, with few errors, and with brilliant solutions, all on their own, is proof enough that coding in solitude is a completely reasonable preference, that's shared among most of the engineers I've met in my career.
There's no reason to be so dogmatic about this.
NO TOM I DONT WANT TO FUCKING MARRY YOU GOD FORBID, ME, A TRULY TALENTED ENGINEER AND GENIUS, TRY TO GET ANYTHING DONE FUCK THIS FUCKING NANNY STATE BULLSHIT as you return to clipping your toenails in the office
I wish I were this insufferable, alas.
Truthfully, I don't mind pairing on something if someone needs help and doesn't mind doing it asynchronously instead of sitting on a video call all day pointlessly when Slack will work just fine. :)
The reason I went to hyperbole with this one was because a prior startup I worked for required everyone to pair on every ticket, whether they liked it or not. I simply refused, and they were fine with it, because they liked the work I did. If I needed to collab on anything, I'd just talk to the other engineers. And guess what? We survived and did amazing work together as a team!
All of these are reviewed before commit.
The 'interrupting' while coding is the shitty part (I agree with you), not having someone working with you.
This process respects each other's time and allows each person to visit the relevant pieces without interruption. The common rebuttal to this is "Slack messages are too interrupting!" and my response is: ignore the message until you're in a good spot to address it, or if you can't spend meaningful time on it yet, just reply with an "I'll check this out later, thanks!"
The idea that we have to sit on a video call in silence while losing the ability to think and write privately is such a huge distraction. Half of my mental bandwidth is occupied with self-consciousness of being "watched", or if I have my video off, it's the idea of being present and tied down by simply being there.
As someone with ADHD, those circumstances do not mix and eliminate any possibility of being productive because it's too distracting on all fronts. Not to mention, I need intense music to really get in a flow state. You might be surprised by how many engineers feel this way because they similarly experience neurodivergent realities around this.
I cannot stand pair programming, but I don't begrudge that it might work for some.
Like, not as a rule. There are times when it would be helpful to have my trusted coworker helping to work through something. The answers aren’t all obvious and we don’t know exactly how it’s going to go. We’ll feel it out as we go. He has better instincts for some stuff and I have better ones for others. We’ll get there better and faster pairing.
But most of the time we have our own stuff to do and have our respective things well in hand. Then there’s no reason to force a pair programming situation.
AI doesn't make that very easy if you're just two people staring at an agent, but I think a lot of people who aren't already senior are going to hit a wall they can't climb when their experience limits what they are capable of doing with AI.
As with many things, usually the bad experiences with collaborative methods come from a specific implementation and those experiences become the bias.
But, it’s not 2x. Companies are cheap, they don’t want to pay for it.
But I agree with OP that when comes the time of sitting down and writing the code, it is a solo activity. I want to lock in and not see multiplayer cursors or avatars popping up around the editor. The part before and after that are for collaboration, but writing your piece of the code is (or at least I like it to be) solo.
I like my neighbors and love to spend some time being nice to them. Pair programming is the equivalent of being forced to live with a random neighbor in your home and you both still pay full rent/mortgage of your respective homes.
Instead of the two players having their own base, they are running a shared base against a single bot. This makes it challenging as now the players are forced to communicate, or one can sandbag, but overall adds a bit of complexity. Though a shared base should allow one player to manage one aspect of the game while the other player manages the other aspect; such as building units and the base, while the other player navigates or harasses the bot.
It is possible to logically work together to get a better outcome, but the tools we have currently don't support that. I find this multiplayer approach intriguing as with the right formula could unlock a nice super power. As I would imagine having twice the mental bandwidth available such that more things are noticed or caught or imagined...
I would focus on the economy and my brother would do the military and fight the bots.
https://news.blizzard.com/en-us/article/19940901/teaming-up-...
I agree, I don't think people are going to remotely pair-prog with this when it's existed in the past and most work on their own and let their pull requests do the talking.
But I say non-code and planning because I've definitely strategized with AI before and have scrapped a good chunk of it because I overlooked details that my team shared. Being able to get that on an active session with context shared across all members as it's debated sounds good and would've reduced turnaround time.
I remember the Opencode folks mention about gangprompting before and I guess this is one take of it, besides adding an Opencode bot on Slack and hoping that's competent enough for the work that needs doing. I've never tried it myself, so I'm not gonna criticize it, but I'm sure it's an idea people want to see if it's effective.
I find that to be a much more promising route than Delta's straight-up multiplayer development on the same task. (Vibe-kanban did fail but I don't think their idea was wrong, but rather the execution- they didn't differentiate enough from straightup Github and Jira boards when that was easily possible, just centralize the agents along with the board.)
Not that two people being able to look at the same agent at the same time is bad though, it's probably amazing for pair programming especially in a remote work setting. It just shouldn't be the main point of a product.
I also think that Delta's codebase replication approach is just flawed in general. Why would you build a remote server just to sync the codebase between multiple developer's laptops when you can just put said codebase on said server in the first place? No expensive sync is needed and all you need is to do remote multiplayer access at the UI level, and everyone gets to work happily on the same codebase and talk to the same agent at the same time.
Back to Claude.
I have zed installed, but honestly I still use SublimeText as my primary editor. Zed feels opinionated and hard to customise.
But good for them, surely some company will pay for their services.
I mean, even if it is a single player game, sometimes, you may want to ask for help, or others may need your help. Think of it like screen sharing. You probably don't share your screen all day long, but it is a really helpful feature when you need it.
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.
It's when that text gets copied and pasted into a blog, or a PR, etc. that it really galls.
First attempt: mountains of meta conversation and not answering the original question.
Second attempt: shorter and more concise, cuts out some of the nonsense, but terribly written.
Third attempt: goes off the rails, misunderstands what you are asking and tries pushing the work onto you.
Fourth attempt: finally something that's concise, reasonably well written, to the point and passable.
Ask for a rewriting pass! Get it to edit for word count, remove redundancies, remove run-on sentences, and change sentence structure to use active voice.
You wouldn't ship your first draft - why let AI do it?
Worst case you lose 10 seconds of your life. Not too bad!
What I don't care for is the pretty-yet-verbose HTML outputs that I see from some teams. They can be way too long and it's often the case that the engineer who made it didn't read the whole thing.
As someone who likes a nicely designed report document, slapping a coat of paint on slop output isn’t helpful
I think it's because it's basically always a high-level, rough overview of a topic that isn't quite correct. It's using 10x the words necessary to say nothing at all. It is a large, featureless wall of words that ultimately tells you absolutely nothing. It's simultaneously too verbose while also not actually saying anything useful.
Maybe my attention span has just gotten worse or something, but I don't really get the same sensation reading good quality docs that I know were human-generated so it must be something specific to how AIs form their paragraphs of noise.
Code is more precise than english language. If it wasn't everyone would just use english to write programs.
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!
For your 2 plannotator [1] has a nice way to annotate agent messages or documents and its integrated into the agent chat (codex app also adopted the pattern)
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
There seems to be this push towards more agents, more better. Me no write code, me just yell at box. But recently I've actually gone the other way. I stopped using the frontier models and just started using cursor auto.
Mostly because it's just insanely fast, like 20 times faster than the frontier stuff. And it really isn't that bad. If it screws up, it's fine, I can fix it quickly. If the frontier models screw up, I just burned two hours.
The last thing I want to do is burn $20,000 worth of tokens overnight, to realize they made a complete mess.
(Edit to get ahead of the comments: I'm sure I can change it. Customization is important. Almost as important as good defaults)
Maybe my eyes are just getting worse...
It's probably just because I'm old
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?
Here they've moved the AI chat to the center and code editor has been pushed to the side.
I have not missed an integrated text editor.
sure if what i want is lots of agents all in different projects so i can jump between them sure but when i'm working on software it is usually one thing at a time and i wan't code visibility over AI chat.
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.
The interesting bit is this type of UI doesn't fit very well in any of the existing terminal TUIs, I have only seen it enabled working well in GUIs.
I want to like the app, but I'm not sure if it actually fits well to my use case. With my current setup I need to fully quit and restart it if I want to work on a different project (to get it to use a different API key) and I cannot work in two threads belonging to different projects at the same time.
Also I generally prefer to handle sandbox the entire agent and disable its internal safeguards. Beside any doubts regarding the quality of the relevant sandbox implementations, I have just gotten my projects to work better this way.
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.
I'm working on a legacy system right now - I'd commit several felonies just to have well documented code, I don't really care about all the conversations that the original team had to decide what they eventually did.
Maybe I'm just too old and don't get it.
theres a lot of context and decision making that is useful but not documented in the code. The code tells you how the system works, not how its supposed to work.
I tend to agree that at a certain point if you need to constantly think "gee, I wish I was in the meeting when they came up with this" the code you are looking at might just suck.
In such contexts it is also often the case that being in the meeting may not have helped. As they say, garbage in, garbage out.
A similar thing happens in agentic conversations, where a model may point out something but it is not recognized as important by the operator.
A few directives later and the model is being pushed another direction.
It can be very useful to have perfect recall of moments like these.
No but you will want all of the transcripts anyway.
> AI will summarize it for me?
Not exactly. You will have some question later that you would never have entertained during your thousands of conversations about code.
You’ll ask your AI something fairly abstract but it will be deep in the context of some other idea.
And the AI will find among all your conversations those turns that are relevant to solving your problem or explaining why.
I know this is the case because I’ve built this and use it every day.
Here are some examples:
1. Resume unfinished work → "where did we leave off on that?"
2. Recover the intent/scope → "what was the actual goal of this whole effort?"
3. Verify it got done → "did we ever finish that, and which session proves it?"
4. Recall a fix → "how did we fix this the last time it broke?"
You would be amazed how good the agent can be at assembling queries against a corpus of transcripts and assembling the results.
My product is called Contextify: https://contextify.sh
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...)
And if'n they don't? What should the disrespected reader of the future do, not use the non-concise form?
> I guess everyone's just too cool to actually write good docs now?
They've always been cool like that, good docs have always been rare and precious
Sure, the reader should still use what's there.
I thought we were discussing the best ways for a team to structure its codebases and processes for comprehension, not how to survive in the face of bad techniques.
> They've always been cool like that, good docs have always been rare and precious
Yeah, that's certainly true.
I feel like it's gotten worse since the grand LLM invasion, but maybe I'm off-base.
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!
https://podcasts.apple.com/us/podcast/syntax-tasty-web-devel...
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 worked on this)
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.
This thing is fairly new in software years and has already stagnated. Bugs, glitches and rough edges all around. Almost feels like abandonware.
I first heard of Zed back when it was “the code editor that respected your choices”, you could turn off AI entirely with a single switch and all that… guess it was too much of a pipe dream to hope it would continue down that road.
This thing is now just a white-label version of Visual Code. Nothing more. Nothing less. Same software, different case.
What a shame.
> This thing is now just a white-label version of Visual Code.
That's a wild hot take, and pretty ignorant to the people working on that for years.
Hot take or not, it’s accurate. There’s little to nothing that differentiates Zed from VSCode now.
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)
It will cause the community to fail because VC dev tooling is unsustainable as the community needs will never take priority over what their VC benefactors want. So if you want the slop that helps you pump out slop they got you covered.
It sounds counter intuitive but you have to remember nearly every business of the planet operates as a centrally planned economy with either a monarch at the helm or an aristocracy. These are some of the least efficient ways to collaborate as humans, at least if history is anything to go by.
I suggest you focus on real open source solutions like neovim, emacs, or helix.
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?
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!
Edit: grammar
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.
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?
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.
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
I'm very glad to see folks innovating in this space.
This can be improved though - I think that simply a separate collaborative doc and a chat linked to that doc would work way better.
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.
Good thing I can just fork the editor. This is how you lose the trust and goodwill of your users.
This is a good sound bite for our times but I'm not convinced it's not carrying a big secret.
Last week, 300+ comments
"Why you'd do that code like that?" "Dunno, that's what Cursor did" "Cool"
Plus a substantial percentage of people in the industry probably never used git blame ffs.
What happened to using "adversarial LLM"? Too expensive for plebs? So this is the middle ground?
I think zed has lost the plot.
When will this ai slop era end? Hopefully soon because I am tired of reviewing junk PRs