I generally like what Zed is trying to become. However, all of these features and blog posts are frustraing when they struggle to keep basic editor features stable. Edit a file outside of the editor? It's not going to show up in the project pane or the git diff. Need to work inside a container because it's 2025 and we don't need to clutter our local machine with 100s of dependencies and env managers... well now all the AI stuff is broken. ACP sounds cool until you realize every single CLI in existence works better.
My wish is that Zed gets the core working correctly 100% of the time before moving on to expanding feature sets. For now I'm back in NeoVIM because it always works the first time....
> Need to work inside a container because it's 2025 and we don't need to clutter our local machine with 100s of dependencies and env managers...
“Can I tell you about our lord and saviour Nix?”
Kidding, but seriously though I’ve found having to work in a container to be a bit clumsy, even with good tooling around it. As you said it’s 2025, and there are other ways to have reproducible toolchains that don’t pollute the rest of your system environment Nix or otherwise.
> “Can I tell you about our lord and saviour Nix?”
The "just use Nix" people are just like the "write it in Rust" brigade.
And the things both groups promote share exactly the same problem ...
A stupidly enormous learning curve.
That's why your average person prefers to just the job done in a container vs Nix, or in Go vs Rust.
I'm sure Nix is awesome, just like I'm sure Rust is awesome. But honestly, I've got enough going on in my brain at $work and $home without having to wrangle some obscure config syntax (Nix) or obscure low-level language complexities (e.g. Rust's infamous borrow-checker).
Every time I go back and look at Rust or Nix my brain is just like .... no, thanks.
With the AI stuff, it feels like they invested a bit prematurely. When the Agentic editing demo came out (6 months, 10 months ago? It’s a blur), it felt right. Accepting and reviewing edits, live tracking ..etc., felt like pair programming. The ACP addition felt like a natural evolution .
With the continuous improvement in CLI tools and people’s experience with them, it feels like doing a live review or edit-by-edit approvals all feel like a drag. I personally have come to avoid using the IDE/Editor. I just kick up Claude code - plan mode, auto-accept edits. Once the session is done, switch to the editor and make necessary adjustments. I suspect people with Max subscription and “dangerously-skip-permissions” …etc won’t even care if an editor has AI integration or not.
The only editor integration I think is semi useful is wiring it into Diagnostics/Problems data that the editor has from extensions. Speeds up the agents flow quite a bit when it leans on that to check its work vs always executing (say) “eslint” directly.
But that can be done easily enough with an MCP extension for your editor/IDE of choice
I used to only use JetBrains for AI stuff, now I just open everything in Zed because of its Claude Code integration. Especially with the linters and other nice to haves. I am insanely close to cancelling JetBrains.
I am not getting tons of issues with Zed going out of sync all the time. I wonder if the issue is it silently having issues watching the filesystem due to open fd limits.
I've noticed that not only does it sync but it even will recognize if I rename the folder a workspace is in.
But then, I've run into a couple of strange issues that tell me there is more polish needed:
- Sometimes upon using LSP refactor, it seems like if a bunch of files get renamed, the open buffers will get screwed up somehow. Like, I'll hit save and it will write to the old filename! It's not actually a huge problem, as I can close the buffers, delete whatever excess files I accidentally create, and re-open them without error, but it is confusing as hell.
- I have indeed had issues with the file view not always updating when files are added externally, however it is not constantly. I usually just reload workspace when this happens. It is a minor frustration, but I had many minor recurring frustrations with both VS Code and Neovim before too, so I don't consider it a deal breaker.
yup, my pet peeve is there is no way to disable line wrap. the setting that exist doesn't work and there's no way to actually disable it instead of just increasing the max characters (with set hard limit in the source code).
have a big docs or log,data file where you don't care for the rest of the line ? well too bad better have a spare editor.
this feel to me like it should should be a number #1 priority. "an editor need to nail the editing part".
Huh? That doesn’t track with my experience. I spent a long time trying to find out how to enable line wrap, and Zed’s settings are more extensive than most editors.
> I know this is silly but the biggest thing that’s driving me away from it is how god awfully blurry it looks on my 1440p screen :/
Not silly at all. User experience is important. If you're going to spend as much time in a tool as most programmers do in their editors, it should look and feel nice.
I don't have this problem, but issues like this are always a huge barrier, especially when you want users from a polished code editor like VSCode. Personally, I use it because VSCodium does not support the default Python LSP on my Linux box. I like it, but there are definitely areas that seem rough around the edges. My biggest issue is the size of the font and icons. I use a 4K screen, and while the font is readable, the icons are so tiny that I can barely see them. Since it is a new system, I don't just know where they are like I would if it were VSCode.
This is also a big issue for me and has one of the largets issues for a while. [1] I wish there was font hinting to the like of windows font rendering.
My experience has been so different. Zed seems to always do the right thing for me when I concurrently edit files with other tools. Not doubting your experience or anything, but you must have a very different environment than me. Zed has been absolutely rock solid for the past year on my computer.
My favorite bug was Claude Code kept editing some template file. Zed kept auto-formatting the file, which was BREAKING the template itself. It took me like 30 minutes of watching Claude implode, and literally using "ed" to edit the line, before I realized, then I started asking Claude how to turn off the Zed formatters to which it was like AH THAT MAKES MORE SENSE, which I thought was hilarious after it tried everything from editorconfig onwards.
The thing about "basic" here is that it's subjective. It could be that these issues only happen on your machine or that the staff (or even most people) don't need what you're asking for. Of course they should try to fix them anyway, but their backlog is enormous.
I would say you're being harsh but their file tree refresh is bad(so is vs code but they have a manual button), their ai panel can't beat Claude code and their panes / window layouts are not any better or flexible than other editors. I still use it but I'm close to going back to vanilla vs code. I'm just hanging on to determine if my frustrations are from me just being used to vs code or otherwise
I agree with you. Zed has a great vision and the team clearly cares, but the foundation still feels a bit shaky. Stability in core workflows matters more than any flashy feature, especially for people who just need their editor to disappear into the background. What gives me hope is that the community feedback is loud and consistent. If the team focuses on tightening the fundamentals, Zed could still become the lightweight but powerful editor everyone hoped for. I’m rooting for them, and like you, I’m ready to give it another full try once the basics feel rock solid.
For me, I was happy using Zed until suddenly an update caused it to crash every time I opened it. It was caused by some sort of issue with graphics drivers on linux I guess.
I just checked the issue [1] and it is fixed now, but it's crazy to me that I never really thought of my text editor needing to use my graphics card for rendering.
So many of the basic features (e.g., automatic Python venv, Pyright running, etc.) have random bugs that pop up from time to time, making the basic editor unreliable.
My fear is, if they keep going in this direction (adding bloat without fixing basic functionality), they'll be a perfect fit for Microsoft acquisition, at which point I'll have to switch careers, because there isn't any other editor out there that I like.
Yeah, I have been fighting Zed to get agents to use podman on my host, but Flatpak is sandboxed and makes it almost impossible. The ideal solution would be that Zed could use podman or docker to spin up a container where agents could run free!
I have observed this too, mostly for content that is changed in a symlinked directory, but also generally. I'm on Fedora Silverblue running Zed Preview as a Flatpak. It works great in most other ways though, snappy and beautiful, but the sandboxed environment provides some additional challenges.
I agree with you 100%. If basic functionalities are not airtight, there’s no way I am going to deal with growing pains just because they want to get paid on AI fluffs. Contrast this with something like Ghostty.
How does Neovim handle outside changes then? Or is there a plugin to make it work? AFAIK it doesn't reload any bufferes when files change. IntelliJ is the only other one I know that does it transparently.
In vanilla neovim you can use autoread... this does depend on a focus event like entering and leaving the pane or switching buffers. However, for my workflow which is "go to a different terminal pane and do some things then switch back" as soon as I focus the buffer it updates.
Where as with Zed it'll just keep showing the old content and in fact closing and opening file wont even change what it shows in Zed. It's really really annoying. I have to exit zed and open it again. This means if you are working with AI agents you end up having to do this often.
What I like in zed (pretty new to me) is that I dont have to deal with vim/neovim plugings to make the basic stuff work. Zed workds out of the box(for rust).
It's not something I am excited about, but it is something I want my IDE to do well if I must engage with it. Other remote pair programming experiences are even worse and I appreciate Zed's capability in the area even if it's not what I prefer.
A lot of my IDE choices are about extensibility and flexibility more than perfection for my preferred coding approach. After all, until I only work for myself I need to be ready to accommodate the needs of others as part of my job.
I stay away from anything Hashimoto is making after my experiences with TF & HCL, or at least the bar is much higher / projects get a lot more scrutiny
This is a strong divider between types of minds. I respect your type, but know that others exist and they want these things. It's not crazy, it's just another way.
Yup, shouldn't force specific tools upon developers. Problem is that the comms products don't interop. Still beat to have just one for the entire org or likely have siloed conversations
This feels like a huge distraction from building an IDE.
A monnumentous yak shave.
I've never used or cared for multiplayer in VSCode or JetBrains. It's silly.
I've never been the pair programmer type. The only time I've needed to share an IDE is during a SEV or ridiculously complicated systems bug, and that's 1% of the time.
I _really really_ want to try this feature, but only if I can selfhost the collaboration server. If there is any way to do this, it's not obvious. Given that as I understand it, lots of project details will pass through Zed's servers, I can't imagine any enterprises would knowingly allow this without some kind of SLA with Zed.
Maybe I'm old, jaded, stubborn and paranoid, but something about a coding editor that is controlled by a company is off-putting to me. It's even more off-putting when you add Zoom, Slack and everything else into said editor.
…you’re free to use other editors? People like Zed. They like IntelliJ. They like VSCode. If you have an aesthetic preference against all professionally maintained IDEs, I think you’re in the minority.
The issue is with social features you might be forced to use it, like Slack instead of Email. I've already had cases where I've been forced to use VSCode to collaborate at work.
while technically possible with massive projects like these its not as simple to simply fork it, because of the man hours involved . its better to keep in the product stands enshitification while one uses it or just use something else.
I like Zed. I pay for pro. I like the integrated agent stuff (though my usage model has changed a bit after 5 months of use).
I'm happy that others can type in each others' space, but this post reveals a tension here. They are building a tool for building the tool, and their own team. I think that's cool, but at a 2-3 person shop heavy polyglotted across 4 OSes and 5+ programming languages, this is not what I really need.
What I'm looking for is a snappy tool (check) that lets me explore, understand, modify code at a next level (marginal). And I want it to not only be snappy by virtue of execution efficiency, but cognitive load. I want the less-is-more experience. I don't need it to do Swift, Kotlin, or Python, because there are bespoke IDEs for each of those that focus on the environments where I deploy them best. What I mostly want from Zed is the ability to see the outline panel at the same time as the directory panel, and to separate the search outline from the file structure outline. I spent too much time toggling views in Zed.
And then toggle between that and the AI agent? Zed is a workbench that lets you put two, and only two, tools on your "workbench" to either side of your text workspace. I want to put more tools on my benchtop.
Zed is lovely and I hope it becomes super successful but this kind of mass collaboration might be ok for meeting minutes... maybe. But thinking of it for coding it gives me shingles. Code by mass live committee. Yikes.
I think it's a fun and interesting idea for training junior engineers and possibly for other use cases. Suggesting alternatives to (perceived) bad practices the instant you see them could be helpful for many people, and also save a lot of future time for reviewers.
I could also see it as a potential productivity aid. Person 1 sees Person 2 is writing something and they don't want to be seen as idle, so they start working as well. This might sound oppressive but a lot of people who struggle with ADHD/procrastination/akrasia actually receive great benefit from that structure. Similar to that startup that forces you to code while screensharing with a stranger in order to push you to work, or people who code in cafes/libraries to be more productive.
As long as it's not an organization requiring it for senior engineers, I could see promise to it as an eventual common new paradigm.
You can use remote screen control with Zoom to train up juniors. More often than not, you'll want to share the whole screen so you can show them webpages and other things that do not live in an IDE
Pair programming can be really great. Or horrible. Depends entirely on the people.
This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.
it's probably subjective, but I find these collaboration features can be overused for this kind of thing.
If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.
I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.
re: pair programming, the lion's share is moving to be with agents, not humans.
I think the fundamental flaw that dooms this feature is non-developers. Do teams and orgs want more than one chat system? I suspect not. It will be very hard (impossible) to convince people who can pay back the VCs to switch zed as the basis for their chat for all employees.
> video comes through well
I cannot recall the last time resolution or latency was an issue (zoom/meet)
> Everyone can follow along in the comfort of their own editor.
With different screen resolutions, you cannot be sure everyone sees the same code. Video guarantees this
Let's lean into the chaos and see what it might give us. Imagine a production application deployed directly from a non-version-controlled directory. Anyone on the team can edit the files, at any time. Insane? Probably. The disadvantages are easy to see.
But the positives are really compelling: 1. make small, granular testable changes; 2. use feature toggles; 3. refactor intensely and concurrently; 4. always work on the latest code; 5. use in-code documentation instead of GitHub/etc workflows; 6. explore continuous, incremental, hot-swappable code deployment.
Doesn't thought of ditching all the wasted motion and ceremony around logging async work and just coding sound glorious? I'm actually not a "move fast and break things person" usually. But the idea of moving so fast that broken things will only stay broken for a tiny fraction of the time is pretty compelling. There is also an intensity that comes from real-time interactions where a team needs to reach consensus quickly.
Pair programming usually has a single "driver" on the keyboard to keep things controllable. Here, everybody is driving: "dozens of cursors are concurrently editing the same file in real-time."
I would love to see collab servers take the same path as LSPs in being standarized and integrated across various editors and IDEs. I would love to work more closely with my VSCode peers, for example. Of course some features may be outside the standard and only supported with likewise editors, e.g. voice chat perhaps, but having shared cursors and a text chat would be a good start.
This is what I'd like to see as well. These collaboration tools are really good, but I barely use them because they always assume that you and your team are using the same editor. Most of the time that's just not the case, so I've used them a handful of times but beyond that there's little opportunity.
It's probably not an issue the Zed team will experience as they're all naturally using their own editor. Hopefully it's on their radar though.
> because they always assume that you and your team are using the same editor.
Network effects are probably a strength for a company, not a drawback (which it is for the user of course). Even VSCode has some notion of network effects, such as their proprietary extension store.
And there were an Emacs minor mode and a Vim plugin too that did this too, both for the SubEthaEdit protocol and for the one of the Gobby editor (https://gobby.github.io/).
These are definitely some interesting features, though not sure I'm in any position to take advantage of them at all.
The multi-user editing is kind of cool... there's an ANSI art tool (PabloDraw) that you can run a host session so multiple artists can create text art, and I thought back when I first saw it, that it might be cool to be able for multiple editors to work on a project. I've used some of the collab stuff with VS Code, but haven't done enough to even begin to compare.
Not to mention that in a lot of workplaces, self-hosting or otherwise layers of bureaucracy stand in the way.
Readit News
My wish is that Zed gets the core working correctly 100% of the time before moving on to expanding feature sets. For now I'm back in NeoVIM because it always works the first time....
https://github.com/zed-industries/zed/issues/38109
Hopefully soon I can give it another shot at full time usage.
“Can I tell you about our lord and saviour Nix?”
Kidding, but seriously though I’ve found having to work in a container to be a bit clumsy, even with good tooling around it. As you said it’s 2025, and there are other ways to have reproducible toolchains that don’t pollute the rest of your system environment Nix or otherwise.
The "just use Nix" people are just like the "write it in Rust" brigade.
And the things both groups promote share exactly the same problem ...
A stupidly enormous learning curve.
That's why your average person prefers to just the job done in a container vs Nix, or in Go vs Rust.
I'm sure Nix is awesome, just like I'm sure Rust is awesome. But honestly, I've got enough going on in my brain at $work and $home without having to wrangle some obscure config syntax (Nix) or obscure low-level language complexities (e.g. Rust's infamous borrow-checker).
Every time I go back and look at Rust or Nix my brain is just like .... no, thanks.
With the continuous improvement in CLI tools and people’s experience with them, it feels like doing a live review or edit-by-edit approvals all feel like a drag. I personally have come to avoid using the IDE/Editor. I just kick up Claude code - plan mode, auto-accept edits. Once the session is done, switch to the editor and make necessary adjustments. I suspect people with Max subscription and “dangerously-skip-permissions” …etc won’t even care if an editor has AI integration or not.
But that can be done easily enough with an MCP extension for your editor/IDE of choice
I've noticed that not only does it sync but it even will recognize if I rename the folder a workspace is in.
But then, I've run into a couple of strange issues that tell me there is more polish needed:
- Sometimes upon using LSP refactor, it seems like if a bunch of files get renamed, the open buffers will get screwed up somehow. Like, I'll hit save and it will write to the old filename! It's not actually a huge problem, as I can close the buffers, delete whatever excess files I accidentally create, and re-open them without error, but it is confusing as hell.
- I have indeed had issues with the file view not always updating when files are added externally, however it is not constantly. I usually just reload workspace when this happens. It is a minor frustration, but I had many minor recurring frustrations with both VS Code and Neovim before too, so I don't consider it a deal breaker.
have a big docs or log,data file where you don't care for the rest of the line ? well too bad better have a spare editor.
this feel to me like it should should be a number #1 priority. "an editor need to nail the editing part".
https://github.com/zed-industries/zed/discussions/26344
on the positive side I do like that you can in-place edit the result of global search.
Not silly at all. User experience is important. If you're going to spend as much time in a tool as most programmers do in their editors, it should look and feel nice.
[1] https://github.com/zed-industries/zed/issues/7992
Personally, I never registered that as a problem, but I can see the delta in screenshots between versions.
No settings to adjust?
Also buggy git support, I selected a few things but it committed everything and made me think I lost it all.
But I love Zed when it works. Literally 5h more M4 battery life vs Cursor.
I just checked the issue [1] and it is fixed now, but it's crazy to me that I never really thought of my text editor needing to use my graphics card for rendering.
[1]: https://github.com/zed-industries/zed/issues/37448
So many of the basic features (e.g., automatic Python venv, Pyright running, etc.) have random bugs that pop up from time to time, making the basic editor unreliable.
My fear is, if they keep going in this direction (adding bloat without fixing basic functionality), they'll be a perfect fit for Microsoft acquisition, at which point I'll have to switch careers, because there isn't any other editor out there that I like.
Where as with Zed it'll just keep showing the old content and in fact closing and opening file wont even change what it shows in Zed. It's really really annoying. I have to exit zed and open it again. This means if you are working with AI agents you end up having to do this often.
Don't bring the attention economy to my cave of solitude, it's where I go to escape all that noise
A lot of my IDE choices are about extensibility and flexibility more than perfection for my preferred coding approach. After all, until I only work for myself I need to be ready to accommodate the needs of others as part of my job.
Deleted Comment
A monnumentous yak shave.
I've never used or cared for multiplayer in VSCode or JetBrains. It's silly.
I've never been the pair programmer type. The only time I've needed to share an IDE is during a SEV or ridiculously complicated systems bug, and that's 1% of the time.
This doesn't fill me with confidence.
I personally worry it's not interoperable enough.
Deleted Comment
I'm happy that others can type in each others' space, but this post reveals a tension here. They are building a tool for building the tool, and their own team. I think that's cool, but at a 2-3 person shop heavy polyglotted across 4 OSes and 5+ programming languages, this is not what I really need.
What I'm looking for is a snappy tool (check) that lets me explore, understand, modify code at a next level (marginal). And I want it to not only be snappy by virtue of execution efficiency, but cognitive load. I want the less-is-more experience. I don't need it to do Swift, Kotlin, or Python, because there are bespoke IDEs for each of those that focus on the environments where I deploy them best. What I mostly want from Zed is the ability to see the outline panel at the same time as the directory panel, and to separate the search outline from the file structure outline. I spent too much time toggling views in Zed.
You can do this now by moving one of them to the right dock (right-click the toggle-button)
I could also see it as a potential productivity aid. Person 1 sees Person 2 is writing something and they don't want to be seen as idle, so they start working as well. This might sound oppressive but a lot of people who struggle with ADHD/procrastination/akrasia actually receive great benefit from that structure. Similar to that startup that forces you to code while screensharing with a stranger in order to push you to work, or people who code in cafes/libraries to be more productive.
As long as it's not an organization requiring it for senior engineers, I could see promise to it as an eventual common new paradigm.
This would be good for code-walks too though. Instead of having to share your screen and hope the video comes through well. Everyone can follow along in the comfort of their own editor.
it's probably subjective, but I find these collaboration features can be overused for this kind of thing.
If someone is walking me through something, I just want to see what they see so I can focus entirely on what they're saying and no part of me is distracted by having to follow along or seeing other code.
I know typically these collab modes have an auto follow feature, but it's not as simple as just read only video being streamed to you, there's loads more ways it can go wrong and add noise / distraction that provides no benefit.
I think the fundamental flaw that dooms this feature is non-developers. Do teams and orgs want more than one chat system? I suspect not. It will be very hard (impossible) to convince people who can pay back the VCs to switch zed as the basis for their chat for all employees.
> video comes through well
I cannot recall the last time resolution or latency was an issue (zoom/meet)
> Everyone can follow along in the comfort of their own editor.
With different screen resolutions, you cannot be sure everyone sees the same code. Video guarantees this
Let's lean into the chaos and see what it might give us. Imagine a production application deployed directly from a non-version-controlled directory. Anyone on the team can edit the files, at any time. Insane? Probably. The disadvantages are easy to see.
But the positives are really compelling: 1. make small, granular testable changes; 2. use feature toggles; 3. refactor intensely and concurrently; 4. always work on the latest code; 5. use in-code documentation instead of GitHub/etc workflows; 6. explore continuous, incremental, hot-swappable code deployment.
Doesn't thought of ditching all the wasted motion and ceremony around logging async work and just coding sound glorious? I'm actually not a "move fast and break things person" usually. But the idea of moving so fast that broken things will only stay broken for a tiny fraction of the time is pretty compelling. There is also an intensity that comes from real-time interactions where a team needs to reach consensus quickly.
Feature Toggles: https://martinfowler.com/articles/feature-toggles.html
BEAM (Erlang, Elixir) provides hot-swappable code and lots more
It's probably not an issue the Zed team will experience as they're all naturally using their own editor. Hopefully it's on their radar though.
Network effects are probably a strength for a company, not a drawback (which it is for the user of course). Even VSCode has some notion of network effects, such as their proprietary extension store.
The multi-user editing is kind of cool... there's an ANSI art tool (PabloDraw) that you can run a host session so multiple artists can create text art, and I thought back when I first saw it, that it might be cool to be able for multiple editors to work on a project. I've used some of the collab stuff with VS Code, but haven't done enough to even begin to compare.
Not to mention that in a lot of workplaces, self-hosting or otherwise layers of bureaucracy stand in the way.