Why develop this when the core editor is almost unusable? On Linux wayland, copypaste is broken, the file manager is laggy and snippets do not trigger before the heavy hint logic is done. This is just on top of my head, the list is long
I can't use an editor where the file contents I'm being shown don't match the reality of the file. I guess this issue doesn't affect most people somehow, but in the age of CLI agents I'm not sure how more people aren't running into it.
I was really enjoying Zed for a short while before I ran into this fundamental issue.
Just installed it, works on my kde and niri setups (I logged out and switched to each), copy paste works as well. File manager laggi-ness I didn't notice I don't use it, I use it mostly to type stuff out.
I have never used snippets so unsure about that too, going from command bar seemed to work.
I think it might be bad, but could also be it's not correctly configured maybe try asking codex/claude or something to check if it can fix/fine tune the config, if that doesn't work file issues?
I do suspect it might be working for me cause I got lucky I do see an open issue[1], but given Zed is used a bunch the lack of comments does suggest maybe it's not that wide spread either way not a good look.
There are a lot of subtle bugs. I'm on macOS too, but perhaps my workflow is unusual? Every time I open it, I find small bugs. There are so many features that it's hard to maintain them, I guess.
For example, a lot of disable buttons do not actually disable stuff. They just hide it from the UI.
I started using Zed a couple weeks ago and immediately had issues with copy/paste/buffer on an M1 Mac. I tried a few suggested fixes and they didn't work.
It still doesn't actually display a window my end until I press a keyboard key or move the mouse. So very often I sit and wait for it to open, only to realize I have to press a random key for it to unhide.
I agree with you that I wish they'd just nail the editor. I've been using it for years now and I really like it, but there are a few rough parts (settings and LSPs especially) that could probably be tuned up in no time if the focus was there.
Having said that, I love the idea of correlating the agent sessions to the changes. I'm glad someone is working on it.
Their ACP integration is good (finally), at least with Codex. For when I want to be near the code, I prefer it now over TUIs or the Codex app. It feels much more immediate that way. Sticking to the basics will kill them IMO. They have been pitching themselves as agent-native for a while btw.
And the workflow they are describing in the post sounds amazing, I‘ve been wishing for that. It‘s orthogonal to CVS, no? You can still make PRs. But, crucially, you can loop people in early on, when it matters the most.
> Their ACP integration is good (finally), at least with Codex.
you must not use it much. try pasting in an image, quitting zed and restarting (ie: upgrading the app). it shows you the base64 encoded data instead of just showing the image. heck, it doesn't even show you the image when you paste it in. it just shows the filename.
Did you even read the post? The idea is to tie conversations to code. This is a more sophisticated version of something like doltdb, not a git replacement.
I had the great pleasure/misfortune of being forced to work with LaminDB, and I can tell you folks; data provenance isn't going away -- it will be used to train the very AI models snapping at our heels
This feels very useful for training agents but almost completely useless to humans? Do I really want to go back to every change I made? Whatuse would that be?
Looks like a great feature/product/functionality. I hope that Zed editor will make it work with LLMs/agents that run in the terminal, not just the Zen Agent itself. Is it even possible? I use OMP.sh agent running in Zed terminal.
This is the killer Zed feature, IMO, that they support almost any agent via extensions. I deleted Cursor but still use the agent via Zed because it’s a lot nicer experience, Zed never had popups telling me Grok is half off. I also use OpenRouter and Zed.dev with it, that’s three providers out of dozens that it supports.
Exactly. The more competitive the space is, the more important it is that products purposefully support 3rd-party providers. Now that people are increasingly switching from Anthropic/OpenAI for inference reseellers and on-prem compute, transparency and portability will be the new values, not being slightly better than the next agent or model.
Maybe I’m pessimistic, but I think this just gives micro-managers the data they need to micro-manage you. It invites people to scrutinize the process, instead of the results.
Not once have I wished to review a colleague’s conversation with an AI. I want to review finished work.
I look at this and I can only imagine layoffs being justified with “bad prompt quality”. An incident retrospective broadcasting your agent conversations to the entire company, with people speculating where you should have put the “make no mistakes”.
It’s a shame, really, because I like Zed as an editor, but I can’t bring myself to support them if this is the direction they’re choosing.
The sort of company that would do those things is going to be mandating you to use their enterprise AI plan anyway, which already lets them read all your conversations if they want to.
The way I’m seeing AI used by organizations is to produce process slop: tickets, summaries, docs, etc. rather than drive process change and optimization, or enable individuals to be more effective within the organization.
this looks like jetbrains "local changes" but globally synced. "for the agents" mights scare people who jump to think about micromanagers, but these people mostly hide or fake work. even micromanagers will eventually give you an agent to use so it won't matter what is in the change log, what matters is speed+quality. and since you can iterate from any branch you have inginite try and retry possibilities
i think a system that uses git and file system artifacts (txt/md/xml files whatever preference) is much better. eng teams need to define their artifacts, eg plan file, reqs etc whatever is needed and important to that team. the agent convo itself doesn’t add much value IMO and adds unnecessary bloat.
This local history has saved my bacon on occasion. E.g. when I went too long without committing and something silly overwrote the file I was working on. Or because I did something silly with git. Then it is nice that there is still an independent backup elsewhere with different failure modes.
Jujutsu already does this. I had agent screwing up changeset over couple hour long session and it took one shell command to split on pieces with longer pause.
The only downside is that because of Jujutsu snapshots it can't be used inside sandbox (since all jj commands are mutating)
Snapshots have an intention behind them as a chunk that the programmer thought of. It has infinite flexibility depending on the programmer/team. IMO they are a necessary feature, but the article considers it a bug. It’s an explicit and deliberate chunking of code writing process which is what you want in a chaotic “collaborative” environment. The system doesn’t get to decide but you decide when to commit.
Yes, it is open source, and I am not saying they should not do it. Chromium is also open source, but if they added too much nonsensical AI functionality, I would be upset. I am free to improve it on my own, but that does not mean I cannot express how I feel.
I have not gone to the Zed repository and created an issue telling them to stop developing DeltaDB because it takes away the maintainers’ time.
Why develop this when the core editor is almost unusable? On Linux wayland, copypaste is broken, the file manager is laggy and snippets do not trigger before the heavy hint logic is done. This is just on top of my head, the list is long
I had to stop using Zed because of this issue (which persists despite being closed): https://github.com/zed-industries/zed/issues/38109
I can't use an editor where the file contents I'm being shown don't match the reality of the file. I guess this issue doesn't affect most people somehow, but in the age of CLI agents I'm not sure how more people aren't running into it.
I was really enjoying Zed for a short while before I ran into this fundamental issue.
Just installed it, works on my kde and niri setups (I logged out and switched to each), copy paste works as well. File manager laggi-ness I didn't notice I don't use it, I use it mostly to type stuff out.
I have never used snippets so unsure about that too, going from command bar seemed to work.
I think it might be bad, but could also be it's not correctly configured maybe try asking codex/claude or something to check if it can fix/fine tune the config, if that doesn't work file issues?
I do suspect it might be working for me cause I got lucky I do see an open issue[1], but given Zed is used a bunch the lack of comments does suggest maybe it's not that wide spread either way not a good look.
[1]: https://github.com/zed-industries/zed/issues/47004
Maybe I got lucky?? Does it not auto update on linux maybe I am on an old build... Very suspicious.
I use it as a daily driver with few if any problems, but I'm on macOS. Maybe their Linux support is particularly crappy?
There are a lot of subtle bugs. I'm on macOS too, but perhaps my workflow is unusual? Every time I open it, I find small bugs. There are so many features that it's hard to maintain them, I guess.
For example, a lot of disable buttons do not actually disable stuff. They just hide it from the UI.
I started using Zed a couple weeks ago and immediately had issues with copy/paste/buffer on an M1 Mac. I tried a few suggested fixes and they didn't work.
It still doesn't actually display a window my end until I press a keyboard key or move the mouse. So very often I sit and wait for it to open, only to realize I have to press a random key for it to unhide.
Terrible Linux support.
> when the core editor is almost unusable
Shit, as someone who uses Zed everyday, I didn't realize what I am using is unusable.
Because it's not broken, the issues you're describing are far from universal. Also, fixing them won't bring any money.
Zed should focus on basics. When it focuses on basics Zed is good.
https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL.
Why a new version control system? Why not git, jj, or another existing system?
I agree with you that I wish they'd just nail the editor. I've been using it for years now and I really like it, but there are a few rough parts (settings and LSPs especially) that could probably be tuned up in no time if the focus was there.
Having said that, I love the idea of correlating the agent sessions to the changes. I'm glad someone is working on it.
Their ACP integration is good (finally), at least with Codex. For when I want to be near the code, I prefer it now over TUIs or the Codex app. It feels much more immediate that way. Sticking to the basics will kill them IMO. They have been pitching themselves as agent-native for a while btw.
And the workflow they are describing in the post sounds amazing, I‘ve been wishing for that. It‘s orthogonal to CVS, no? You can still make PRs. But, crucially, you can loop people in early on, when it matters the most.
> Their ACP integration is good (finally), at least with Codex.
you must not use it much. try pasting in an image, quitting zed and restarting (ie: upgrading the app). it shows you the base64 encoded data instead of just showing the image. heck, it doesn't even show you the image when you paste it in. it just shows the filename.
I use it constantly but haven’t felt the need to paste an image yet. I guess I‘m using pi and the Codex app more for that.
sorry, i didn't mean a quantity of time, i meant depth of usage.
Did you even read the post? The idea is to tie conversations to code. This is a more sophisticated version of something like doltdb, not a git replacement.
Previous discussion: https://news.ycombinator.com/item?id=48492533 (June 11th, 225 comments)
Is it available now? Still seems to be a waitlist?
Sounds like a side-effect of being VC-backed. Like what the ex GitHub CEO went on to build (Entire). Unnecessary.
A non-existent problem that nobody asked to solve...
You can simulate this by having a jj repo with file system watches.
I had the great pleasure/misfortune of being forced to work with LaminDB, and I can tell you folks; data provenance isn't going away -- it will be used to train the very AI models snapping at our heels
I really don't want management critiquing when I swear at Claude, thanks.
So is this basically Beads + Dolt? This isn’t to diminish it, it’d be great if this ends up being a less “vibe code-y” alternative to those.
This feels very useful for training agents but almost completely useless to humans? Do I really want to go back to every change I made? Whatuse would that be?
Looks like a great feature/product/functionality. I hope that Zed editor will make it work with LLMs/agents that run in the terminal, not just the Zen Agent itself. Is it even possible? I use OMP.sh agent running in Zed terminal.
It supports anything with ACP. So it can actually run Codex and Claude Code, not just the Zed Agent.
Looks like omp supports ACP, so all you have to do is specify a Custom Agent in Zed and it should just work.
https://omp.sh/docs/acp
https://zed.dev/docs/ai/external-agents
This is the killer Zed feature, IMO, that they support almost any agent via extensions. I deleted Cursor but still use the agent via Zed because it’s a lot nicer experience, Zed never had popups telling me Grok is half off. I also use OpenRouter and Zed.dev with it, that’s three providers out of dozens that it supports.
Exactly. The more competitive the space is, the more important it is that products purposefully support 3rd-party providers. Now that people are increasingly switching from Anthropic/OpenAI for inference reseellers and on-prem compute, transparency and portability will be the new values, not being slightly better than the next agent or model.
I use this every day — https://zed.dev/blog/terminal-threads
This makes me uncomfortable.
Maybe I’m pessimistic, but I think this just gives micro-managers the data they need to micro-manage you. It invites people to scrutinize the process, instead of the results.
Not once have I wished to review a colleague’s conversation with an AI. I want to review finished work.
I look at this and I can only imagine layoffs being justified with “bad prompt quality”. An incident retrospective broadcasting your agent conversations to the entire company, with people speculating where you should have put the “make no mistakes”.
It’s a shame, really, because I like Zed as an editor, but I can’t bring myself to support them if this is the direction they’re choosing.
The sort of company that would do those things is going to be mandating you to use their enterprise AI plan anyway, which already lets them read all your conversations if they want to.
Not only this. I'm also shuddering at the thought of how much more noise this adds which can only be filtered through LLMs.
Don’t worry, Zen (or another company in their VC backers’ portfolios) will helpfully sell you inference to filter through that noise!
Indeed, I want the information between commits for myself, so I see the utility. But I don't want people observing every keystroke.
It's also delusional to think you can find that one edit that was really useful but you forgot to commit but then deleted in another giant commit.
As anyone who's ever tried to split a days worth of work apart with `git add -p` is well aware.
It may be feasible with a million agents, but they could remember what they typed three hours ago anyhow.
The way I’m seeing AI used by organizations is to produce process slop: tickets, summaries, docs, etc. rather than drive process change and optimization, or enable individuals to be more effective within the organization.
I don't know. I've been giving Zed a chance for almost half a year now and it just doesn't seem to be going the way I would want an editor to go.
this looks like jetbrains "local changes" but globally synced. "for the agents" mights scare people who jump to think about micromanagers, but these people mostly hide or fake work. even micromanagers will eventually give you an agent to use so it won't matter what is in the change log, what matters is speed+quality. and since you can iterate from any branch you have inginite try and retry possibilities
i think a system that uses git and file system artifacts (txt/md/xml files whatever preference) is much better. eng teams need to define their artifacts, eg plan file, reqs etc whatever is needed and important to that team. the agent convo itself doesn’t add much value IMO and adds unnecessary bloat.
I have fallen in love with Zed.
This local history has saved my bacon on occasion. E.g. when I went too long without committing and something silly overwrote the file I was working on. Or because I did something silly with git. Then it is nice that there is still an independent backup elsewhere with different failure modes.
Like a branch on the server?
That would still be in git. The local history in IntelliJ works independently of any VCS.
Also I’ve had formatters botch files including changes I hadn’t committed yet. For that the local edit history is also useful.
What problem does this product solve?
Collaborative (as in simultaneous multiplayer) editing I think, which has been Zed's mission since before LLMs were a thing...
See https://zed.dev/blog/introducing-deltadb but also https://zed.dev/blog/crdts from years ago.
I start to sound like a Jujutsu fanboy but...
Jujutsu already does this. I had agent screwing up changeset over couple hour long session and it took one shell command to split on pieces with longer pause.
The only downside is that because of Jujutsu snapshots it can't be used inside sandbox (since all jj commands are mutating)
Jujutsu is great, but it does not do this. It has no knowledge of agent sessions.
Snapshots have an intention behind them as a chunk that the programmer thought of. It has infinite flexibility depending on the programmer/team. IMO they are a necessary feature, but the article considers it a bug. It’s an explicit and deliberate chunking of code writing process which is what you want in a chaotic “collaborative” environment. The system doesn’t get to decide but you decide when to commit.
Is this closed source?
Basically what IntelliJ calls local history. It is a feature that has saved my bacon. https://www.jetbrains.com/help/idea/local-history.html
Similar, but not as polished, also exists in VSCode and derivatives, named the same way. Definitely saved me a few times as well.
This saved me from accidental resets in the past. I learned it existed because the files were showing up in mdfind
Yes, I concur. Local History is wonderful; nice to see Zed getting its own version.
Ooooh, this is cool. I was unaware of this. Thanks for the link.
This is a big unsolved dev tooling problem. Glad someone competent is working on it.
Yes, but it saps away the time that could be used to improve zed.
Or it’s actively used to improve Zed faster (or more efficiently).
zed is open source, you are free to improve it on your own
Yes, it is open source, and I am not saying they should not do it. Chromium is also open source, but if they added too much nonsensical AI functionality, I would be upset. I am free to improve it on my own, but that does not mean I cannot express how I feel.
I have not gone to the Zed repository and created an issue telling them to stop developing DeltaDB because it takes away the maintainers’ time.
It should work with github inbetween commits, that i may use. Right now I'm using staging as an in bewteen in a dangerous way.