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.
Pair programming is a great way to do knowledge sharing and collaborate on tricky problems. Now, I don't really want a multiplayer editor, but I'll highly contest that coding is solely a solo activity.
Sometimes I feel like people online hate all their coworkers. Thankfully, such people have not been highly represented amonst those I've worked with.
It's not hating coworkers. It's more that state of flow is not compatible with collaboration with other people. Getting to pair programming flow is basically like the neural "Drift" in Pacific Rim: it just doesn't work with two random people, or with shifting moods, energy levels or priorities.
There aren't that many good ways to mentor or share experience in a team without pairing though. Sometimes it's just better to sit down with someone and directly collab, and let the person with less experience do the driving so they get the muscle memory. This is an easy transfer of skill and knowledge and it works well because it's hands on.
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.
I don’t get in flow but I do feel like it’s similarly productive though. Right where I would lull in energy or lack the motivation to think through something difficult I can unload some of that on the other person and feel like as a pair we are keeping each other accountable. Can be productive this way even without the same flow state.
That actually makes the "Drift" analogy perfect, because you have to be "Drift compatible", you can't just grab two people off the street and throw them in a Jäger together and have it work.
It's less hating coworkers and more enjoying the perfect logic that comes from interacting with a cpu versus the fuzzy nature of human moods etc. It's likely why a lot of people (myself included) got into coding.
I read "coding" as literally the act of being in the text editor and writing the code, not the encapsulating job of defining requirements, desigining a solution, etc. which is definitely not a solo activity.
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.
Yea that never made sense to me. I think and solve problems as I code, and having someone yapping while I'm trying to do that is a great way to disrupt my thinking process.
You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees
In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.
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.
- 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.
> 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.
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 done VSCode pair programming as well. But since roughly half a year ago, it has been permanently broken. It'll work for a few minutes, then loses sync, and then it's unusable. This seems to happen between many computers (not just mine) and many updates of VSC.
Are we the only ones with this issue? Pair programming is unusable to us with VSC because of this.
Even if you're not both typing at once, being able to trade off quickly without having to manually pass the ownership back and forth has had value for me in the past.
Zed agent was so bad at using Ollama local models that I created my own agent to use instead. I think creating an agent is the hello-world of agentic coding, everyone is doing one.
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.
You can try shikigami dev IDE, and let me know what do you think - if you have some time. It's my side project and gains more and more popularity as an alternative to VCBaked or paid products. Thanks!
Ever try editing like, a Google Doc, while multiple people are in it? It's not fun. I can't imagine how that would go when people could be changing functions I'm referencing, etc. Isn't this was version control is for?
Works well if you're communicating while you're making changes in code.
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).
> Ever try editing like, a Google Doc, while multiple people are in it? It's not fun
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
Honest question: with multiple contributors or just a single individual editor? I’m building a word processor and never personally considered multi-player useful.
Multiple. Just writing down some stuff and comments at the same time you're writing the content is very powerful. For group projects it was the fastest way we found to get to a working plan as soon as possible and get to work on assigned parts of the doc. It's also nice seeing other people working at the same time as yourself
I've seen it done: group project where due to delays everyone needed to blitz through writing the report, four people hammering out stuff in a shared google doc. It works pretty damn well. You probably want to be in the same room or on a voice call with the others, though.
Don't tell me what's fun or not! Some people might not like the experience, but why yuck someone's yum? Editing a Google doc at the same time as someone else when you're both in the flow and you know what you're doing and you know the person or persons really well, is sublime. Like a shared game of Factorio.
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.
Pair programming requires a lot from you and your relationship with your pair programming partner.
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.
If you look at one of the studio sessions between Drake and 40 (look up "100gigs" on youtube), there's this flow between the two, almost like an implicit language that they invented together, that lets them collaborate at an insane speed.
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.
For me it's less about trust and more about practicality. If you are coordinating live in person while collaborating that is a bit different than trying to edit a doc multiple people are in, all remotely. When I had said it's not fun that's the case I had in mind.
Linus actually mostly deals only with trusted subsystem leads. They may choose to deal with less trusted contributors, but I wouldn't say the Linux kernel development process is low trust. Many of those folks have worked together for decades.
Funnily enough, my first impression for this project was to use it for non-code and planning first.
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 remember the fad. I was around for the Extreme Programming era. But, I've never worked anywhere that pair programming was the norm, nor have I known any developers that wanted to pair program, in the general case.
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.
I love pairing. It always results it better outcomes than not pairing and I've been saddened by the slow decay of the term to now refer to like "talk to me a bit until I'm unstuck" instead of "both work together and get it done"
I worked at Pivotal Labs, it was an amazing experience to be in an environment where everyone was onboard with a very well defined methodology. Certainly not for everyone, but everyone who was there had the same mentality. A bit like you'd expect from a cult or the military.
I consulted on an internal project where the leads literally made one dev control the keyboard and another dev control the mouse! It was the most ridiculous thing I ever saw. I fought for those poor kids, the leads were eventually fired or quit.
Yeah, YC also has their own "multiplayer agent", qm (https://github.com/yc-software/qm), though it doesn't seem to be focused on code, which makes a little more sense.
Early in 2026, Vibe Kanban tried to do a multiplayer kanban board to code on a project collaboratively where each individual task is still managed by one developer and their agent.
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.
Vibe Kanban was fun when it was only about one humans PMing many agents. But then it IIRC went in some weird directions. Haven't thought about it since, does it still exist?
I don’t think the emphasis here is on real time multiplayer, but instead on async multiplayer. The way it’s described is about an evolving code base over time. Everyone sees the conversations, comments and decisions that lead to the code in screen. Individuals directly interact with the code via agents. Other devs see all those deltas and can add to the discussion.
Looking at it from the perspective of StarCraft, doing a Blood Bath 1v1 against a bot its pretty straightforward. Adding another player to make it 2v1 has the potential to make it a lot easier, but there are moments where the bot could take out one of the players or at least pressure them enough to tax resources. Obviously, this all depends on the skill level of all the players/bots and their strategies.
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...
You just reminded me that 90s StarCraft did have a mode where 2 players would command a single “team”. Basically a single “player” with multiple cursors. It was rad! Haven’t seen the concept duplicated.
I would focus on the economy and my brother would do the military and fight the bots.
My assumption is that people who want multi-user code editors are the same people who are forced to work in a place that requires heavy pair programming.
I could see it being useful if you're helping someone debug something, but chances are it's easier just to screenshare.
I think the value come from monitoring agents work by multiple team. like architect, developers and security team together, so you dont need to have the back and forth.
I don't understand the fixation the industry has on multi-player development either. Zed isn't the first. It's been 10 or 15 years since I started seeing multi-player development (sometimes called peer programming in an earlier iteration) being championed in various ways. VS, Intellij, Eclipse, and vscode had plugins for it and all of them are from the 2015-2018 time. One can even say that the Google Wave demo from 2007 was one of the earliest demonstrations for this concept.
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.
Pair programming is the extroverts answer to the solitariness of software development. They love it while everyone else is hating their existence. It works for short stints to solve specific problems but anything beyond that is just gratuitous.
I feel I’ve seen the multiplayer thing being pushed ten years ago or so, guess it’s time for another round. It’s one of those things that makes for cool product videos but I’ve never met anyone who actually uses it or has expressed any desire for the feature.
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.
I wonder if a productive avenue might be "doing aspect-oriented programming in reverse": asking the LLM not to "summarize" the code per se, but rather to "clarify" it by transforming it into what a programming blog post would call a "toy example" of what the code is doing, by stripping out all the (non-semantic) error-handling, logging, metrics incrementing, etc — all the things that you might treat as their own "aspects" under AOP.
One thing worth flagging: summaries can provide context that is important, but you should always remember to thoroughly comb through the information in case there are caveats in the text that may act as a heads up, which is important.
I've found that I don't mind getting a lot of text back from an LLM, when I was the one who prompted it. I can easily enough let my eyes flit around in the text and figure out what I need to, and I expect that putting all that text in the context window will help with the rest of the conversation.
It's when that text gets copied and pasted into a blog, or a PR, etc. that it really galls.
Yeah, I have a rule in my agents MD that essentially says the code doesn't need a comment because it should be readable. And ask me in the exceptionally rare instances where it needs a summary or a comment. I am a Ruby and JavaScript developer, so I suppose that is a lot more readable than some other languages, but broadly, I've found code summaries and code comments to not be necessary if the code is very elegantly written.
I don't like the default explanations. But I prompt for small code snippets with explanations of a problem and the solution. This is in the context of extending features, fixing bugs, reviewing new code etc. I still skim the code, but it's nice to have a somewhat thoughtful overview of the key points like database schema, API spec, algorithm or abstraction. It makes it easier to skim a large diff without feeling lost. It also quite often catches some weird choices that might slip through it not carefully reasoning about the code. For me it is hard to understand code I didn't write myself so I have landed on this workflow.
The "language model" aspect shows IMO, at least for someone who grew up with the material of 90s and 2000s where we describe things more in mechanical, engineering terms. When gpt4 landed it was somehow amazing to see the output, but yeah nowadays I keep skimming through the explanation. It's like an intermediate dev who has nothing else to do but create long sentences to describe what could be simpler.
Right, the value is not so clear of having multiple people wade through lengthy LLM responses. Part of the value that a human in the loop adds is figuring out what's correct and important in the response and passing on a more polished result.
I thought Caveman was debunked in the token saving argument? In real sessions it doesn’t really save much longterm and made sessions more forgetful/take longer.
I'm a bit confused by your use of 'pithy, but at least its terse'. Don't pithy and terse mostly mean similar things? Here it seems like you're contrasting them. Not trying to be pedantic, apologies if it comes off that way.
I use AI explainers a lot in my own projects and have skills that give outputs I like. I'll even pipe the output into NotebookLM to make a video sometimes. This is actually a decent way to grok complex subsystems (YMMV).
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.
We need a new specification language for summaries. I think just a (pseudo?-)programming language’s API (modules, interfaces, method signatures), but more concise and descriptive than Java, maybe Haskell or OCaml minus quirks (…the academics were this close to an ideal syntax, maybe they should’ve gave up those languages’ LR parsers…)
Your AI summary is raw output, like uncooked mince meat.
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?
I mean... the problem with that, as with all the "you have to go back and forth with the AI" scenarios, is that by the time I finish with that I may as well have just written it myself to begin with. Would take a similar amount of time, actually have my voice in it, and not cost money for tokens.
It’s an LLM, it does what you want. If you don’t like it verbose tell it you want it to be succinct and it’ll do exactly what you ask of it. What sort of complaint is this?
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.
> On (2), I do find myself consuming agents' gigantic text responses, writing 8-bullet-point responses to guide them, then iterating that way. It's pretty exhausting. I could see inline comments providing much better ergonomics.
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)
Same pain point on (2). So I had codex build me a small macos sytem tray app that lets me comment on anything i can select on my screen with the source app and metadata plus my comments. Once commenting is done i can click a button to coppy all comment to the chat input, and voila ! But really something i hope that gets integrated into the codex app itself. The present way they made it is not super helpful.
It's a solid experience so far (have been testing the alpha). Being able to work across model providers in parallel is my preference, rather than being stuck in Codex desktop, for example.
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?
This was my experience with the editor as well. For about 2 seconds, I admired how clean it was. I then struggled to read anything at all and haven't reopened it since.
(Edit to get ahead of the comments: I'm sure I can change it. Customization is important. Almost as important as good defaults)
I tried zed for its vertical agent threads grouped by project (which Claude Code has since added) and had the same experience--even after trying a bunch of different themes. It felt like none of the dark themes had enough text contrast.
It also seemed mostly AI, which made me think, okay, I'll copy and paste this and have a model summarize it for me, but it seemed, I don't know, low effort, not interesting. I didn't even bother.
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.
When it was the policy to use AI tooling, that’s all I ever used. And it was mostly one or two prompts in most conversations to get things done. Get a first version generated by the AI and fix the issues manually.
i hate the "agent" side of cursor and the keep pushing me to change to it.
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.
For me it's probably time to learn to use vim or something similar. I'm the only one that likes coding manually, without all this AI shit? I'm faster writing code myself than trying to explain to artificial stupidity what I intend to do and correct its output. And if I write it myself the code just works, if it's written by the AI it has a ton of bugs. I don't see any value in AI generated code that is not mere code for doing experiments that you don't care about.
There is never a bad time to learn vim! Not only is it a super useful skill if you end up having to edit a file on a server (and you don't want to deal with nano), it also makes coding fun.
Hey me too. This is my morning Zen moment refactoring and cleaning some code before I go back to the agent to earn money. One of the only things that helps me to relax is to do some manual coding...
It seems reasonable that a professional-tier of software developers will have tools distinct from everyone else. No matter what the percentage looks like, experts will still be a thing that needs different things.
When cli agents and the models behind them advanced sufficiently, I basically ditched the IDEs/editors with ai built in, and went back to plain fast sublime & vim. Though I'm playing a bit with helix these days. But back to more focused tools instead of a mishmash soup of ui and interactions
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...)
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.
> Do I have to read the whole transcript just to understand what's going on?
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?"
I shared these and more in my post in the August “what are you working on?” thread. [0]
You would be amazed how good the agent can be at assembling queries against a corpus of transcripts and assembling the results.
the problem w/ this is that if people actually need their logs saved...99% is to finetune custom models on their codebase later...this is a whole pipe, u neeed to refine and prune the data into proper format for reinforcement learning i think...they will never us a mac app for this, they will use same agent and have custom scripts for this.
for programming ur context is the codebase..not the logs, the bot searching through all chat log is wasted tokens when they can read context from codebase directly, and if not then they can search diff....there are edge case maybe like oops i accidentally deleted this code its only in chat logs.....you simply tell to go find log and extract data....so you cant make a product on this sorry.
If one builds something with an agent, the process itself is largely opaque. Preserving the transcript shows the reasoning of the agent and the decision process of the builder. This way everyone's on the same page instead of re-prompting same CLAUDE.md but with different results, and/or going through similar work over and over again.
I understand the point, but shouldn't the code be documented and well structured so that the intent is clear without looking at the discussion around changes?
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.
surely you could imagine that being able to sit in on a meeting that was had when they were designing the system would be useful for you?
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.
This is just the classic rehash of are comments in code an anti-pattern.
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.
Sometimes it is useful to simply know something was brought up, but then someone had a sneezing fit and everyone lost track of the thread and the important edge case under discussion just fizzled.
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.
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.
Precision feedback for CLI-based coding agents is terrible. We built and open sourced PlanBridge (https://plan.contextbridge.ai) to fix this. It is a CLI that lets your coding agent open a local browser with a rendered plan/spec (or just the last agent message) so you can select and comment directly on the text and iterate with precision.
Thanks for pointing that out. I tried the Codex App before but didn't see that.
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.
Directly annotating parts of the convo is the feature that really unlocked Delta for me (have been testing the alpha). So much easier than trying to explain to the agent what I'm responding to in their giant text blob.
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 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?
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!
I think the point is to incorporate it in the end in to Zed. Becoming the new thread panel or something. But it's just not something that is easy to fiddle with inside a working editor that many of us rely on to make some money.
It's not a full IDE but you can see the files and docs mentioned and created in the Delta chats. I often will pop open the right tab in Delta to check that.
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
> 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?
Presumably it’s easier to iterate upon and judge solely on its own merits when it’s a standalone application. Maybe this isn’t optimized for user comfort, but for efficient product exploration (for now).
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 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.
Delta.dev is the same Rust application as Delta, just compiled to WebAssembly and rendered through WebGL. So it's already web accessible, and can naturally extend to mobile platforms as well!
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)
Sure, they're backed by a VC company that is all in on LLM hysteria so everything they backed will have to back that narrative so they can dump their wares for a profit.
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 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.
Would be nice if Zed announced anything related to what Zed actually is: a code editor.
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.
Just because they started out as a code editor doesn't mean it has to stay that way. I was looking forward to a more modern Sublime Text in Zed but I also know that nobody is going to make money off a simple code editor.
> 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.
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!
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.
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.
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.
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
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.
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 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 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.
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".
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.
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.
I can imagine this being useful, but unlike Zed, this looks like it'll come with some fairly significant lock-in. Great for the investors, but it makes me hesitant...
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?
maybe I am old. has anyone else really tired to collaboratively chat with an agent like this? in my experience, people on my team tend to work more in isolation with agents. Ive never seen them collaborate ON the chat. they do collaborate on the PR...
i've had a similar idea for a while. Creating almost a multiplayer grill-me interface so teams can collaborate on spec definitions. Will be interesting to see how this plays out.
Is anyone who’s not a control freak employer/manager actually excited about storing every single agent conversation alongside code in an easy to reference manner? It’s like attaching all office chat recordings and screencasts of your working hours to code for eternity. Just suffocating, and easily abused by nosy people.
Plus a substantial percentage of people in the industry probably never used git blame ffs.
I hate to be that guy who complains about style over substance, but man, is that font they use for body text ugly. Not just the glyphs themselves, but the spacing is way off, too.
I see Zed abandoned their principles regarding AI. Shame, I really do like the editor. Any decent alternatives that aren't VSCode or a Jetbrains product?
It looks interesting. Maybe this is an ignorant question though but doesn't claude basically force you to use all their software to use agents though? So if you were to use claude with delta you would pay insane fees because it would force API pricing? Or is this system more for local agents?
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.
Pair programming is a great way to do knowledge sharing and collaborate on tricky problems. Now, I don't really want a multiplayer editor, but I'll highly contest that coding is solely a solo activity.
Sometimes I feel like people online hate all their coworkers. Thankfully, such people have not been highly represented amonst those I've worked with.
It's not hating coworkers. It's more that state of flow is not compatible with collaboration with other people. Getting to pair programming flow is basically like the neural "Drift" in Pacific Rim: it just doesn't work with two random people, or with shifting moods, energy levels or priorities.
There aren't that many good ways to mentor or share experience in a team without pairing though. Sometimes it's just better to sit down with someone and directly collab, and let the person with less experience do the driving so they get the muscle memory. This is an easy transfer of skill and knowledge and it works well because it's hands on.
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.
You reach a different kind of flow state with two people, if you have chemistry. I think it’s a more productive flow state than the solo flow.
But, it’s not 2x. Companies are cheap, they don’t want to pay for it.
I don’t get in flow but I do feel like it’s similarly productive though. Right where I would lull in energy or lack the motivation to think through something difficult I can unload some of that on the other person and feel like as a pair we are keeping each other accountable. Can be productive this way even without the same flow state.
It does happen, but it's very very rare. I met maybe 2 people in my career I could do this with.
That actually makes the "Drift" analogy perfect, because you have to be "Drift compatible", you can't just grab two people off the street and throw them in a Jäger together and have it work.
It's less hating coworkers and more enjoying the perfect logic that comes from interacting with a cpu versus the fuzzy nature of human moods etc. It's likely why a lot of people (myself included) got into coding.
Ah, now I hate all my coworkers because I don't want to share a keyboard. Incredible insight.
If you're not sitting in a group of 5 watching one guy code, then you're not a team player.
Bro I can drive the car alone why do rally racers have two people in the car? Now I hate my coworkers because I don’t want to share a wheel? Smdh
I read "coding" as literally the act of being in the text editor and writing the code, not the encapsulating job of defining requirements, desigining a solution, etc. which is definitely not a solo activity.
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.
pair programming is when two people collaborate on engineering decisions while one of them codes.
Yea that never made sense to me. I think and solve problems as I code, and having someone yapping while I'm trying to do that is a great way to disrupt my thinking process.
You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees
Maybe it does for you, but everyone is different. It is annoying (and sad) to see both sides asserting their experiences as universal truths.
I cannot stand pair programming, but I don't begrudge that it might work for some.
In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.
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.
I am willing to bet there’s a strong correlation between people who post/comment on Internet forums and anti-social behavior.
There’s tons of reasons
- 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.
ASOCIAL people prefer solitude.
ANTISOCIAL people doesn't care about society, are harmful towards other people, break laws, etc.
If you’re trying to diagnose a personality disorder sure. If you’re just using it colloquially then no it doesn’t matter.
Of course it matters, using "antisocial" in this context is plain ignorant and wrong.
No, it’s completely correct.
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.
> 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.
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 done VSCode pair programming as well. But since roughly half a year ago, it has been permanently broken. It'll work for a few minutes, then loses sync, and then it's unusable. This seems to happen between many computers (not just mine) and many updates of VSC.
Are we the only ones with this issue? Pair programming is unusable to us with VSC because of this.
during those cases, i've just asked them to give me control over zoom and it's worked fine.
I've never desired to have two people working on the same file at the same time during a debugging/teaching session.
Even if you're not both typing at once, being able to trade off quickly without having to manually pass the ownership back and forth has had value for me in the past.
Can you elaborate? Why wouldn't you just check in your code when you're done your bit instead of working on the same commit together?
I like it because we don't have to do the this dance all the time: * Commit * Push * Say: Now it's pushed * Pull
We can just work together, talking and writing code. Works great with people you work well with and are aligned with.
Zed agent was so bad at using Ollama local models that I created my own agent to use instead. I think creating an agent is the hello-world of agentic coding, everyone is doing one.
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.
You can try shikigami dev IDE, and let me know what do you think - if you have some time. It's my side project and gains more and more popularity as an alternative to VCBaked or paid products. Thanks!
Ever try editing like, a Google Doc, while multiple people are in it? It's not fun. I can't imagine how that would go when people could be changing functions I'm referencing, etc. Isn't this was version control is for?
Works well if you're communicating while you're making changes in code.
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).
> Ever try editing like, a Google Doc, while multiple people are in it? It's not fun
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
Honest question: with multiple contributors or just a single individual editor? I’m building a word processor and never personally considered multi-player useful.
Multiple. Just writing down some stuff and comments at the same time you're writing the content is very powerful. For group projects it was the fastest way we found to get to a working plan as soon as possible and get to work on assigned parts of the doc. It's also nice seeing other people working at the same time as yourself
I've seen it done: group project where due to delays everyone needed to blitz through writing the report, four people hammering out stuff in a shared google doc. It works pretty damn well. You probably want to be in the same room or on a voice call with the others, though.
Don't tell me what's fun or not! Some people might not like the experience, but why yuck someone's yum? Editing a Google doc at the same time as someone else when you're both in the flow and you know what you're doing and you know the person or persons really well, is sublime. Like a shared game of Factorio.
> Like a shared game of Factorio.
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.
Pair programming requires a lot from you and your relationship with your pair programming partner.
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.
If you look at one of the studio sessions between Drake and 40 (look up "100gigs" on youtube), there's this flow between the two, almost like an implicit language that they invented together, that lets them collaborate at an insane speed.
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.
For me it's less about trust and more about practicality. If you are coordinating live in person while collaborating that is a bit different than trying to edit a doc multiple people are in, all remotely. When I had said it's not fun that's the case I had in mind.
Linus actually mostly deals only with trusted subsystem leads. They may choose to deal with less trusted contributors, but I wouldn't say the Linux kernel development process is low trust. Many of those folks have worked together for decades.
Funnily enough, my first impression for this project was to use it for non-code and planning first.
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.
Yeah, I think there's a lot of fans of "pair programming", including the zed people...
I remember the fad. I was around for the Extreme Programming era. But, I've never worked anywhere that pair programming was the norm, nor have I known any developers that wanted to pair program, in the general case.
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.
I love pairing. It always results it better outcomes than not pairing and I've been saddened by the slow decay of the term to now refer to like "talk to me a bit until I'm unstuck" instead of "both work together and get it done"
I happened to "pair program" for the first time in years today! My coworker asked me to come over and help him with a problem.
'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.
This sounds like ‘pair debugging’ which I’ve found to work pretty well. ‘Pair development’ isn’t something I’ve ever really found helpful, though.
I worked at Pivotal Labs, it was an amazing experience to be in an environment where everyone was onboard with a very well defined methodology. Certainly not for everyone, but everyone who was there had the same mentality. A bit like you'd expect from a cult or the military.
I consulted on an internal project where the leads literally made one dev control the keyboard and another dev control the mouse! It was the most ridiculous thing I ever saw. I fought for those poor kids, the leads were eventually fired or quit.
Multiplayer agent thingy is a VC keyword these days.
Yeah, YC also has their own "multiplayer agent", qm (https://github.com/yc-software/qm), though it doesn't seem to be focused on code, which makes a little more sense.
I think multiplayer is easier on web than doing it in the terminal
Early in 2026, Vibe Kanban tried to do a multiplayer kanban board to code on a project collaboratively where each individual task is still managed by one developer and their agent.
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.
Vibe Kanban was fun when it was only about one humans PMing many agents. But then it IIRC went in some weird directions. Haven't thought about it since, does it still exist?
I don’t think the emphasis here is on real time multiplayer, but instead on async multiplayer. The way it’s described is about an evolving code base over time. Everyone sees the conversations, comments and decisions that lead to the code in screen. Individuals directly interact with the code via agents. Other devs see all those deltas and can add to the discussion.
Looking at it from the perspective of StarCraft, doing a Blood Bath 1v1 against a bot its pretty straightforward. Adding another player to make it 2v1 has the potential to make it a lot easier, but there are moments where the bot could take out one of the players or at least pressure them enough to tax resources. Obviously, this all depends on the skill level of all the players/bots and their strategies.
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...
You just reminded me that 90s StarCraft did have a mode where 2 players would command a single “team”. Basically a single “player” with multiple cursors. It was rad! Haven’t seen the concept duplicated.
I would focus on the economy and my brother would do the military and fight the bots.
Are you sure you aren't off by 20 years and referring to "Archon Mode" introduced to Starcraft 2 in 2015?
https://news.blizzard.com/en-us/article/19940901/teaming-up-...
AoE could do this too by both selecting the same colour
My assumption is that people who want multi-user code editors are the same people who are forced to work in a place that requires heavy pair programming.
I could see it being useful if you're helping someone debug something, but chances are it's easier just to screenshare.
I liked the Zed AI agent, too. Then it casually burned through a surprising amount of money for very little progress.
Back to Claude.
I think the value come from monitoring agents work by multiple team. like architect, developers and security team together, so you dont need to have the back and forth.
I don't understand the fixation the industry has on multi-player development either. Zed isn't the first. It's been 10 or 15 years since I started seeing multi-player development (sometimes called peer programming in an earlier iteration) being championed in various ways. VS, Intellij, Eclipse, and vscode had plugins for it and all of them are from the 2015-2018 time. One can even say that the Google Wave demo from 2007 was one of the earliest demonstrations for this concept.
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.
GNU Screen has supported multiuser editing since 1993.
"You newer models are happy scraping the shit... because you've never seen a miracle"
I guess I have occasionally used screen or tmux to help someone out before, but it was a few minutes, and not a regular occurrence.
Pair programming is the extroverts answer to the solitariness of software development. They love it while everyone else is hating their existence. It works for short stints to solve specific problems but anything beyond that is just gratuitous.
Don't forget SubEthaEdit! That was the first multiplayer editor I recall.
Never found a use for this sort of thing once novelty wore off. :/
It does work. Very well. The code quality, problem solving, and knowledge transfer are all insanely better when pairing properly.
If Jeff Dean and Sanjay Ghemawat are wrong, I don't want to be right.
Maybe an approach for interactive code reviews with distributed teams.
Also see: https://subethaedit.net/
I feel I’ve seen the multiplayer thing being pushed ten years ago or so, guess it’s time for another round. It’s one of those things that makes for cool product videos but I’ve never met anyone who actually uses it or has expressed any desire for the feature.
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.
I wonder if a productive avenue might be "doing aspect-oriented programming in reverse": asking the LLM not to "summarize" the code per se, but rather to "clarify" it by transforming it into what a programming blog post would call a "toy example" of what the code is doing, by stripping out all the (non-semantic) error-handling, logging, metrics incrementing, etc — all the things that you might treat as their own "aspects" under AOP.
So..pseudo code?
AI summaries are great for learning which parts of the codebase are load bearing.
One thing worth flagging: summaries can provide context that is important, but you should always remember to thoroughly comb through the information in case there are caveats in the text that may act as a heads up, which is important.
And exactly where the seams are
And what was the smoking gun
Now I have a full picture
I've found that I don't mind getting a lot of text back from an LLM, when I was the one who prompted it. I can easily enough let my eyes flit around in the text and figure out what I need to, and I expect that putting all that text in the context window will help with the rest of the conversation.
It's when that text gets copied and pasted into a blog, or a PR, etc. that it really galls.
Yeah. Human psychology is weird.
Yeah, I have a rule in my agents MD that essentially says the code doesn't need a comment because it should be readable. And ask me in the exceptionally rare instances where it needs a summary or a comment. I am a Ruby and JavaScript developer, so I suppose that is a lot more readable than some other languages, but broadly, I've found code summaries and code comments to not be necessary if the code is very elegantly written.
I don't like the default explanations. But I prompt for small code snippets with explanations of a problem and the solution. This is in the context of extending features, fixing bugs, reviewing new code etc. I still skim the code, but it's nice to have a somewhat thoughtful overview of the key points like database schema, API spec, algorithm or abstraction. It makes it easier to skim a large diff without feeling lost. It also quite often catches some weird choices that might slip through it not carefully reasoning about the code. For me it is hard to understand code I didn't write myself so I have landed on this workflow.
The "language model" aspect shows IMO, at least for someone who grew up with the material of 90s and 2000s where we describe things more in mechanical, engineering terms. When gpt4 landed it was somehow amazing to see the output, but yeah nowadays I keep skimming through the explanation. It's like an intermediate dev who has nothing else to do but create long sentences to describe what could be simpler.
Right, the value is not so clear of having multiple people wade through lengthy LLM responses. Part of the value that a human in the loop adds is figuring out what's correct and important in the response and passing on a more polished result.
There is a reason Caveman (https://github.com/JuliusBrussee/caveman) is as popular as it is
I thought Caveman was debunked in the token saving argument? In real sessions it doesn’t really save much longterm and made sessions more forgetful/take longer.
I wish LLM summary of code was put aside the actual code, like the Jasmine documentation[0].
[0]: https://jasmine.github.io/tutorials/your_first_suite
I'm a bit confused by your use of 'pithy, but at least its terse'. Don't pithy and terse mostly mean similar things? Here it seems like you're contrasting them. Not trying to be pedantic, apologies if it comes off that way.
"Bob can be blunt but at least he's honest." Words can have positive or negative connotations for the same notion.
That's insightful! In a negative way.
I think he’s saying that’s it’s dense and _too_ full of meaning. So, while terse, it can also hide extra meaning in its density.
Gnomic, then (on my mind because I saw it used yesterday, thanks flir).
I use AI explainers a lot in my own projects and have skills that give outputs I like. I'll even pipe the output into NotebookLM to make a video sometimes. This is actually a decent way to grok complex subsystems (YMMV).
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.
Those HTML reports are almost always filled with fluff.
As someone who likes a nicely designed report document, slapping a coat of paint on slop output isn’t helpful
We need a new specification language for summaries. I think just a (pseudo?-)programming language’s API (modules, interfaces, method signatures), but more concise and descriptive than Java, maybe Haskell or OCaml minus quirks (…the academics were this close to an ideal syntax, maybe they should’ve gave up those languages’ LR parsers…)
Your AI summary is raw output, like uncooked mince meat.
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?
I mean... the problem with that, as with all the "you have to go back and forth with the AI" scenarios, is that by the time I finish with that I may as well have just written it myself to begin with. Would take a similar amount of time, actually have my voice in it, and not cost money for tokens.
I agree, I also sometimes do stuff manually when it's easier to do manually than to ask AI. Took me years before I got it though.
If all you need is a readable summary you can understand you should definitely try asking. You might get a surprise!
Worst case you lose 10 seconds of your life. Not too bad!
Ask for a walkthrough of the highlights (with '...' omissions so that the most important parts are quickly visible) instead of a verbal summary.
I use caveman to handle this. Not because to I want to spent less tokens, I want to spent less time reading.
I hate fighting with the AI to get a good summary. Reading the good summary is great. Getting to it is the challenge.
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.
What agent are you using? I have much better experiences fortunately
It’s an LLM, it does what you want. If you don’t like it verbose tell it you want it to be succinct and it’ll do exactly what you ask of it. What sort of complaint is this?
Yes this is why I ask the agent to summarize the code as a comic of a lizard explaining it to a cat.
You're absolutely right!
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!
> On (2), I do find myself consuming agents' gigantic text responses, writing 8-bullet-point responses to guide them, then iterating that way. It's pretty exhausting. I could see inline comments providing much better ergonomics.
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)
[1] https://github.com/backnotprop/plannotator
Same pain point on (2). So I had codex build me a small macos sytem tray app that lets me comment on anything i can select on my screen with the source app and metadata plus my comments. Once commenting is done i can click a button to coppy all comment to the chat input, and voila ! But really something i hope that gets integrated into the codex app itself. The present way they made it is not super helpful.
The Codex desktop app lets you highlight anything in the transcript and add it to the chat as an annotation.
You can also add comments directly in the diff view and they submit in the next message you send.
It's a solid experience so far (have been testing the alpha). Being able to work across model providers in parallel is my preference, rather than being stuck in Codex desktop, for example.
Paseo and other agent harnesses can let you work across model providers as well.
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
This was my experience with the editor as well. For about 2 seconds, I admired how clean it was. I then struggled to read anything at all and haven't reopened it since.
(Edit to get ahead of the comments: I'm sure I can change it. Customization is important. Almost as important as good defaults)
I tried zed for its vertical agent threads grouped by project (which Claude Code has since added) and had the same experience--even after trying a bunch of different themes. It felt like none of the dark themes had enough text contrast.
Maybe my eyes are just getting worse...
My experience with Zed was installing it and giving up after spending 15 minutes or so making the settings sane
It's probably just because I'm old
I wouldn't say the contrast is ultralow but it definitely could be improved
It mostly looks good on Mac!
It also seemed mostly AI, which made me think, okay, I'll copy and paste this and have a model summarize it for me, but it seemed, I don't know, low effort, not interesting. I didn't even bother.
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.
When it was the policy to use AI tooling, that’s all I ever used. And it was mostly one or two prompts in most conversations to get things done. Get a first version generated by the AI and fix the issues manually.
Yeah it just feels like the whole post is unimportant.
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?
To be fair: a year ago the editor was in the center and the AI chat was in the sidebar-- Cursor.
Here they've moved the AI chat to the center and code editor has been pushed to the side.
Zed already has a “agentic layout” for a while. It shifts the ai and threads to be more prominent and moves code + sidebar to the right
i hate the "agent" side of cursor and the keep pushing me to change to it.
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.
For me it's probably time to learn to use vim or something similar. I'm the only one that likes coding manually, without all this AI shit? I'm faster writing code myself than trying to explain to artificial stupidity what I intend to do and correct its output. And if I write it myself the code just works, if it's written by the AI it has a ton of bugs. I don't see any value in AI generated code that is not mere code for doing experiments that you don't care about.
There is never a bad time to learn vim! Not only is it a super useful skill if you end up having to edit a file on a server (and you don't want to deal with nano), it also makes coding fun.
Hey me too. This is my morning Zen moment refactoring and cleaning some code before I go back to the agent to earn money. One of the only things that helps me to relax is to do some manual coding...
You can learn Vim, Kakoune, Helix, in that order.
The obvious next step is to remove the code editor entirely.
In my own agent there's no code editor, just the chat session.
I have not missed an integrated text editor.
It seems reasonable that a professional-tier of software developers will have tools distinct from everyone else. No matter what the percentage looks like, experts will still be a thing that needs different things.
The product is not an IDE, it is exactly the agent-native experience you're saying is required for current gen models.
I guess my main point is that the additional features on top of DeltaDB don't seem terribly important to me anymore, compared to the alternatives.
When cli agents and the models behind them advanced sufficiently, I basically ditched the IDEs/editors with ai built in, and went back to plain fast sublime & vim. Though I'm playing a bit with helix these days. But back to more focused tools instead of a mishmash soup of ui and interactions
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...)
> they should be captured in your specifications / docs / ADRs, in a concise form that respects the reader's time.
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
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.
> Do I have to read the whole transcript just to understand what's going on?
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:
I shared these and more in my post in the August “what are you working on?” thread. [0]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
[0] https://news.ycombinator.com/item?id=49236853
the problem w/ this is that if people actually need their logs saved...99% is to finetune custom models on their codebase later...this is a whole pipe, u neeed to refine and prune the data into proper format for reinforcement learning i think...they will never us a mac app for this, they will use same agent and have custom scripts for this. for programming ur context is the codebase..not the logs, the bot searching through all chat log is wasted tokens when they can read context from codebase directly, and if not then they can search diff....there are edge case maybe like oops i accidentally deleted this code its only in chat logs.....you simply tell to go find log and extract data....so you cant make a product on this sorry.
If one builds something with an agent, the process itself is largely opaque. Preserving the transcript shows the reasoning of the agent and the decision process of the builder. This way everyone's on the same page instead of re-prompting same CLAUDE.md but with different results, and/or going through similar work over and over again.
I understand the point, but shouldn't the code be documented and well structured so that the intent is clear without looking at the discussion around changes?
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.
surely you could imagine that being able to sit in on a meeting that was had when they were designing the system would be useful for you?
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.
This is just the classic rehash of are comments in code an anti-pattern.
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.
Sometimes it is useful to simply know something was brought up, but then someone had a sneezing fit and everyone lost track of the thread and the important edge case under discussion just fizzled.
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.
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.
Precision feedback for CLI-based coding agents is terrible. We built and open sourced PlanBridge (https://plan.contextbridge.ai) to fix this. It is a CLI that lets your coding agent open a local browser with a rendered plan/spec (or just the last agent message) so you can select and comment directly on the text and iterate with precision.
The Codex App has inline comments on output/diffs and it has made such a difference for iterating. Like Delta I expect to see this adopted everywhere.
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.
Thanks for pointing that out. I tried the Codex App before but didn't see that.
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.
Directly annotating parts of the convo is the feature that really unlocked Delta for me (have been testing the alpha). So much easier than trying to explain to the agent what I'm responding to in their giant text blob.
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 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?
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!
I think the point is to incorporate it in the end in to Zed. Becoming the new thread panel or something. But it's just not something that is easy to fiddle with inside a working editor that many of us rely on to make some money.
It's not a full IDE but you can see the files and docs mentioned and created in the Delta chats. I often will pop open the right tab in Delta to check that.
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
Nathan is on today’s Syntax episode talking about Rust and Zed and Delta:
https://podcasts.apple.com/us/podcast/syntax-tasty-web-devel...
Also here, it's a really cool conversation https://syntax.fm/show/1029/the-workflow-of-the-future-with-...
I expected a release today because they didn't want to date the podcast episode recording date lmao
> 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?
Presumably it’s easier to iterate upon and judge solely on its own merits when it’s a standalone application. Maybe this isn’t optimized for user comfort, but for efficient product exploration (for now).
If it's not optimized for user comfort, don't say it is? Also don’t understand the presumption, what makes it easier?
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 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.
Delta.dev is the same Rust application as Delta, just compiled to WebAssembly and rendered through WebGL. So it's already web accessible, and can naturally extend to mobile platforms as well!
(i worked on this)
is it also build on gpui and does that mean gpui is getting a webgl backend?
Awesome! I'll for sure look into that.
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)
Sure, they're backed by a VC company that is all in on LLM hysteria so everything they backed will have to back that narrative so they can dump their wares for a profit.
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 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!
Would be nice for Zed to announce something that was immediately available for use.
Would be nice if Zed announced anything related to what Zed actually is: a code editor.
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.
Just because they started out as a code editor doesn't mean it has to stay that way. I was looking forward to a more modern Sublime Text in Zed but I also know that nobody is going to make money off a simple code editor.
> 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.
> 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.
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!
What makes it better than Conductor?
I have no use for this but it's actually a cool feature. Might use it on the job.
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
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.
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.
At the current pace of innovation, the 2020s might even see us catch up to where Google Wave was in 2009. Exciting times.
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
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
Because nobody's actually implemented it properly. VSCode's live share came close but was buggy and unusable.
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 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 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.
Zed in Identity crisis.
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".
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.
Doesn't appear to be opensource (and neither is DeltaDB, it seems), unlike Zed. Any plans to change that?
This is a cool party trick but I'm afraid Zed lost the plot by pivoting completely to AI. Like so many companies
Seems like "multiplayer AI" is the buzz word for next year, just starting to ramp up now.
"Collaborative Agentic Editing"
"Why you'd do that code like that?" "Dunno, that's what Cursor did" "Cool"
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.
I can imagine this being useful, but unlike Zed, this looks like it'll come with some fairly significant lock-in. Great for the investors, but it makes me hesitant...
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?
It's a code editor. Are you using it in some other way?
Related HN post.
Last week, 300+ comments
https://news.ycombinator.com/item?id=49187256
Might be time to fire up Sublime Text again.
I feel like this fails to explain the benefits over something like git worktrees, like whats the benefit?
maybe I am old. has anyone else really tired to collaboratively chat with an agent like this? in my experience, people on my team tend to work more in isolation with agents. Ive never seen them collaborate ON the chat. they do collaborate on the PR...
Instant bookmark
i've had a similar idea for a while. Creating almost a multiplayer grill-me interface so teams can collaborate on spec definitions. Will be interesting to see how this plays out.
Nice my company will instantly block this if I use it.
Multiplayer? It's a game?
wouldve been nice to see a video of what theyre talking about. words are so ambiguous in what the product is
Is anyone who’s not a control freak employer/manager actually excited about storing every single agent conversation alongside code in an easy to reference manner? It’s like attaching all office chat recordings and screencasts of your working hours to code for eternity. Just suffocating, and easily abused by nosy people.
Plus a substantial percentage of people in the industry probably never used git blame ffs.
"talking about code is how software gets written."
This is a good sound bite for our times but I'm not convinced it's not carrying a big secret.
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.
I hate to be that guy who complains about style over substance, but man, is that font they use for body text ugly. Not just the glyphs themselves, but the spacing is way off, too.
God i hate this non stop AI slopfest
I see Zed abandoned their principles regarding AI. Shame, I really do like the editor. Any decent alternatives that aren't VSCode or a Jetbrains product?
There's Gram, a fork of Zed without the AI: https://gram-editor.com/
Sublime
What principles do you feel they abandoned?
neovim
I like using my mouse
set mouse=a
neovim is ugly
Emacs then? :)
The name is terrible. Maybe this is vanity, but theres too many conflicting names. Delta airlines, delta dental, delta faucets, etc
I'm sorry, but this so-called "minimal code editor" jumped the shark a long time ago.
It looks interesting. Maybe this is an ignorant question though but doesn't claude basically force you to use all their software to use agents though? So if you were to use claude with delta you would pay insane fees because it would force API pricing? Or is this system more for local agents?
I don’t understand the point of this. Now we need 2 or more humans to micromanage LLM(s)?
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
Wait, do Canadians say "Gen Zed"????