I've lost faith in their editor and GPUI - you were the one, Zed! They are full-steam AI on things like this. I expected this article to be about a general alternative to git, but it is about LLM-focused coding in a way that doesn't make sense to me, as it slices a line between human-written and LLM-written code which does not exist in a meaningful way.
Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted. Amusingly, the risk of this is increased when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
It begs questions like: "If coding has changed so that we should use an LLM-focused source control tool, why can't the LLM fix a severe bug in our software that has a closed-form solution?"
I _think_ they fixed the file sync issue; I haven’t had desynced files in a few weeks.
Still a bad bug that lingered entirely too long.
> when a file is changed asynchronously, which for me, most happens due to a pull or LLM edits!
If you’re using Pi (I am), that’s partially because Pi doesn’t have “real” ACP and violates the spec as a result. File read/writes are supposed to happen via ACP RPC calls from the agent to the client, so Zed would see them and know to refresh. Pi wasn’t built for ACP so it embeds its own read/write tools and ignores the ACP ones, and Zed never gets the “refresh this file” signal it expects.
> Their primary product, the Zed editor, is unusable for me and others due to it mismanaging file syncs on disk - when external edits happen, the editor retains stale state unless you close and re-open the specific file (Not even an editor reopen syncs it). There is a significant risk of your changes being silently overwritten or conflicted.
But isn’t Zed written in Rust?
Yikes. I had to stop using JetBrains software for similar reason (their autosave effectively conflicted with external git usage). This is inexcusable to me but to each their own.
Don't they have an auto-save setting that you can turn off?
Yes, but I think it still behaved weirdly with external changes. It's been a few years now, maybe it discarded any unsaved changes and just re-read the version from disk, or maybe it auto closed any editors for files that didn't exist after a branch change. Awkward behavior like that. VSCode and Sublime Text are much better in this regard.
Do you have a link to an issue, so I can know if I should be worried about this?
Here: https://github.com/zed-industries/zed/issues/38109
Similarly, I had to stop using Zed because the main thread would beachball for > 30s when trying to work in large repos on macOS. This behavior was clearly reported to them in a GitHub issue that they also closed without fixing (because they believed a partial fix was sufficient, and have ignored subsequent comments to the contrary): https://github.com/zed-industries/zed/issues/55746
Ah, yeah, I get this issue too but I've been so conditioned to close and reopen files that I've stopped thinking it was an issue. Appreciate the link.
> Closing this as I expect many of the remaining problems described in this issues comments to be fixed by #51208. > > Once that PR makes it to stable (expected March 25th 2026), please create new issues if you are still experiencing problems.
Did you open a new issue?
No, but I posted on the existing one. Sounds worth trying.
edit: Done
Woah. I’ve been meaning to check out zed but that’s a huge problem. I’ve fixed this problem before in rust, there’s just a library you can use to update file trees with a combination of batching fs notifications and a periodic rescan. Wtf guys! Maybe I’ll submit a PR… oh wait! I mean delta. :(
What is that library name? Sounds helpful.
What do you use instead?
Jetbrains (PyCharm and RustRover) for projects; Sublime for one-off files.
The last time I checked out Jetbrains' IDEs, they felt heavy as hell to use. Has that changed?
Yeah, JetBrains IDEs are Java-based, so rather heavyweight. Then again, VS Code (and Cursor) have a browser engine running in the background, so not really better in my book. Sublime and Zed are more efficient of course. OTOH, JetBrains IDEs might be memory intensive, but don't actually feel sluggish on my 5 year old Core i7 laptop with 16 GB RAM.
Visual studio (at least its "core") is written in C++, yet is very heavy weight, so it's not the programming language at play here.
No. Still heavy as hell. (AKA uses loads of ram and CPU, slow, sometimes unresponsive). It is the price we pay - the tradeoff is IMO the unmatched editing and introspection/refactoring capabilities. I'm surprised there hasn't been a real competitor in this space.
I've been running a latest-1 version of a few of their products on silicon Macs since M1 w/ 8GB RAM without issue. I use minimal plugins and work on medium-sized codebases and their IDEs are some of the most reliable software I use.