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.
Rust forces you to consider things upfront, or to put it another way, a C developer does what the borrow checker does manually. Sometimes, they do it after asan/ubsan/tsan has reported the issue. Sometimes it's after a segfault. Usually it's after the user hits the bug already.
Nix similarly forced issues to be reasoned with upfront.
Yes and most people are happier with a garbage collector than using C, C++ or Rust. There are domains or projects where you have to use one of those languages, but Rust is being used and promoted far outside those niches.
I think LLMs have solved that for Nix. I recently moved my homelab from an Ansible/Debian setup to NixOS. As long as I understand at a high level what Nix is and what problems it solves, I can let the LLM deal with the configuration language.
I didn’t say “just use Nix”, I jokingly made a reference to street evangelists and the similarities they have in their approach with people who are excited about a particular technology. In fact I said “Nix or otherwise” implying there are many options when it comes to reproducible per-project environments.
joking or not, people are very tired of the evangelists (fanbois?) from these ecosystems, and this culture around them is one reason others stay away. The broader trend is developers are burnt out on tooling churn
> Complexity for the sake of complexity is not a goal everyone should be striving for.
THIS !
Go's well maintained stdlib just lets me get on with it.
With Rust meanwhile, I have to decide which of thousands of third-party Rust crates is sufficiently en-vogue and well maintained.
Most of my coding work is backend stuff that calls a lot of HTTP APIs, parses a lot of JSON and does a lot of crypto. All that is ready-to-go "out of the box" with Go stdlib and on top of that is faster to get to production in Go than in Rust.
I don't need or want Rust's complexity. As I said I have enough going on at $work...
That's a fine opinion to have. You just have to fight a separate shoggoth of a mutable-root system, which mainstream Linux vendors like Google and Valve have avoided.
It's similar to the Rust situation in that many Rust programmers are simply tired C++ programmers fed-up with using Valgrind and Cmake. Nix is the retirement-home for people who clean up package pollution and just want stability at any cost.
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.
Theres a plugin for Claude Code and you can use Claude models from Copilot in IntelliJ. Are those options worse than Zed, especially considering other comments about Zed missing basic editor stuff?
The copilot plugin with Claude models (Sonnet models) is very integrated in the IDE, and so is Jetbrains AI (even more integrated than Copilot) which I believe can also use those models. So I wonder what's the actual difference.
The plugin just opens a terminal whereas in Zed you get a more natively feeling experience. In JetBrains they do support it as one of their agents but now you have to buy into JetBrains AI credit system instead of just using your Claude subscription.
Theres two ways to use Claude Code in JetBrains and instead of helping them make their plugin better they opted to try and make money off of it. Which Zed could have done the same but instead lowered their monthly to let you use your own Claude Code subscription.
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.
Thank you for the example. That shows exactly what I was talking about, so this issue is clearly (at least somewhat) a matter of taste. To my eyes, those VSCode samples look harsh, crudely pixelated like something out of the 1990s, while the Zed samples look like normal anti-aliased text.
Ahh, thanks for the explanation. I guess I was thrown off by the screenshot attached to that bug report upthread, where someone compared zed's rendering against completely non-anti-aliased text rendered by VS Code.
No, this is a thing where the text is honest to God blurry on non-4K displays. The macOS version of Zed on a low DPI display has the worst font rendering of any application I've ever seen, and I used desktop Linux twenty years ago.
It's like they're rendering a high resolution font at low resolution using the simplest possible algorithm without lining it up with the pixel grid. It's very fuzzy. Characters have this weird sort of additive color intensity where strokes intersect that reminds me of Geometry Wars. It's broken.
They are working on it; the Windows build has decent rendering, and apparently the Linux version substantially improved recently. But they haven't gotten to macOS quite yet. I've been checking in on Zed every few weeks since it went public waiting for a fix.
It might be. I can't speak for anybody else, but it's probably the term I'd use myself if I was trying to explain it, even if it's perhaps not exactly the perfect one. The pixel edges just end up not hard enough, and the pixel corners just end up not sharp enough, and my eyes don't seem to like it. Whatever they're looking for when they're looking at text, pixelly text and printed text seem to supply it, and anti-aliased text doesn't.
(Though there must be some cutoff point past which the pixel size becomes irrelevant. I certainly don't mind reading stuff on the iPad.)
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
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.
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.
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.
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!
It’s not just a nice to have. It’s a hard requirement. If I can’t launch agents within a sandboxed container, I can’t use your product - by security policy.
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.
vim.o.autoread (default on)
When a file has been detected to have been changed outside of Vim and
it has not been changed inside of Vim, automatically read it again.
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
Zed is sticking to all Rust, it appears, so Ghostty wouldn't work. Also Ghostty has a lot more UI features itself like tabs etc so I don't think it's as easy to integrate in an editor which also has its own UI, so Alacritty being mainly TUI driven makes more sense.
I have worked quite heavily with Terraform and went through the trough of despair myself. But after a while I realized
1. It does quite a good job at what it does, given the complexity it's handling for us.
2. We have been expecting more and more from the tool.
Mitchell himself called Terraform stuck in the past in some social media platform. However, I don't see Terraform sucking up all the interest and cash in infra, making the landscape barren so nothing else can grow. So, I hope something better will pop up. Until then, Terraform is good for what it does.
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.
people can abstract and reason about issues like...
1. Until this is possible without lock-in to a specific IDE, it's going to be heavily gated by adoption and network effect.
2. What are you going to do about communication with non-devs who don't use any IDE? Do I now have multiple chat tools I need to give attention to?
3. Bringing the attention economy to our primary work tool is probably a bad idea in the long run, given the evidence we have more broadly about the impact of the attention economy
5. We are in an AI hype cycle, which comes with a lot of experiments and baggage. We're seeing both fandom and rational pushback against this experiment (and others)
The post I responded to pointed to nothing of the sort. Like many other comments here, it was focused on how the they like to work alone, pairing sucks and this endeavour is a waste.
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.
We’ve been growing and have had to scale authentication beyond what our original collab server could handle. Not many people are using collab yet, we’re prioritizing non-collaborative features (like our recent Windows release), and we’re planning on rebuilding all of this on top of DeltaDB. Fundamentally, it just fell through the cracks.
Self hosting will be a vital feature for users and enterprises though, we’re planning on revisiting it once we have a few more features settled :D
Looks great. I use some CRDTs like Loro and Automerge, are there any learnings or collaboration you're taking from them to improve DeltaDB?
Also the name, I thought it was a database with CRDTs due to the "DB" at the end of DeltaDB, but it's a version control system, I thought that was somewhat misleading, any reason why it's named so?
Is this / will this be open source? I have a direct immediate need for this and was about to break ground on greenfield implementation. Had no idea Zed was working on something similar. I would of course much rather collaborate than maintain a competing VCS.
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."
a few years ago our company used Screenhero which allowed editing with multiple cursors while screensharing.
The experience was actually quite nice for two-three people but we always had the "ok let me type now" flow. Multiple changes happening at once sounds hyper distracting.
my understanding is that this is the dynamic in modern college classrooms. everyone opens a big shared google doc for notes and they all collaboratively edit a set of notes in real-time.
or at least that's what i've heard, no idea if they actually do it.
it is nice to see a crdt backed editor tool for markdown and code though. gdocs markdown support has been lacking for years.
> or at least that's what i've heard, no idea if they actually do it.
Yeah, we used to do that back when I was in college. It's only for certain classes and most people usually kept their own notes too (or instead, why write twice). Or some classes ban laptops so you'd write on paper anyway.
Yeah, people are different, but a lot of this difference results from various constraints, such as cultural practices around collaboration or technological options. Many of these limitations probably shouldn't be locked in by our tools or norms.
When learning a new way of thinking or moving (i.e. martial arts) people often really benefit from high-bandwidth, low-latency, shared-viewport-onto-reality interactions. Watching someone's cursor move while they talk is one way to get a window into their problem-solving toolkit.
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.
> Despite attempts to make Atom—an Electron application—more responsive, it never reached the performance standards the team yearned for.
This feels like an attempt at deflecting blame. VSCode is another Electron application that ended up having better performance than Atom. There's another Electron adjacent application that has good performance, the one you're probably using right now to read this page.
Reading this static HTML page and executing several megabytes of JavaScript to read and edit short lines of text are fundamentally different tasks, even if the same program can perform both actions.
VSCode can pretend to be fast in my desktop, and I would not care because desktops today are computing monsters that rival supercomputers of the past, but Sublime Text is still much faster at any text editing task.
I’m not saying that VSCode is the snappiest editor out there but for all its flaws it’s still the most responsive editor for my use case on moderately sized CUDA/HIP projects.
What are you saying here? It is true that VS Code is less bad in terms of responsiveness in comparison to Atom. Zed, however, is written in Rust (i.e., not Electron), and I would guess it is at least an order of magnitude more responsive than VS Code across every possible scenario.
Web technologies are an unrivaled technological marvel for what they are, but it is disingenuous to imply they represent anything near the peak of what we are capable of in the context of performance.
It depends. It definitely opens faster and the general UI seems a bit faster, but open a largish file (a few MB) and VSCode will easily out-perform Zed because it doesn't have that fancy CDRT thing.
In my experience VSCode is plenty fast. Use it with no extensions and you will have zero problems with performance (though memory use isn't great). The real problems come when you have extensions, especially because it's often impossible to attribute performance issues to them because they can often do a lot of work all in the same "extension host" process.
> you will have zero problems with performance (though memory use isn't great)
Memory use is a part of performance, though, so I definitely would say VS Code has serious performance issues. It's why I no longer use it, in fact. It's inexcusable for something to eat as much RAM as VS Code does.
If you use vscode on a platform with limited resources you will see that vscode is absolutely NOT fastand zed outperforms vscose long way. Extensions or not. And electron is a pleague that needs to pass from this world
Based on this comment [0], they're building DeltaDB as a version control system which uses a CRDT, so I assume even in single player mode, the file will instantiate its own CRDT for fine grained tracking of changes.
Unlike a lot of other commenters, I found this to be an interesting approach. Text files are good. Having an integrated environment that combines files and channels and collaboration seems like a neat idea, and I could imagine building all sorts of neat stuff on it.
However, I just tried it myself and was really shocked to see other people in my sidebar after I clicked on the “collaboration” stuff. I expected to be dropped into my own collaboration environment built around my own channels, like a fresh private Slack instance, but instead I saw the built-in Zed channels and as I clicked around, it looked/sounded like I was joining voice channels. It was as if I’d accidentally joined someone else’s Discord. It was so mentally jarring that I got afraid I was on a live mic or would accidentally be live-sharing stuff with strangers.
If you've been a developer long enough, you might recall the teletype package for Atom—both built by Zed's founders.
I first experienced this in SubEthaEdit in 2013 or so, but it has been around since the early 2000s:
Appropriately working together on a truly collaborative tool, Martin Ott, Martin Pittenauer, Dominik Wagner, and Ulrich Bauer of Technische Universitat Munchen won the Best Mac OS X Student Project for Hydra 1.0.1, a Rendezvous-based text editor that enables multiple people to contribute to a shared document. (Adam and about ten other attendees at MacHack used Hydra to take notes during this year’s Hack Contest.)
It seems like the "unlock" here that makes it different this time is organization-wide sharing.
People have been doing collaborative text editing since the 60s actually! See, The Mother Of All Demos[0], referenced in our first blog post[1] :D
I'd say CRDTs are also a big change. CRDTs make live collaboration much more robust for all parties involved, and they only started to reach maturity in the mid-late 2010s
SubEthaEdit was a very inspiring software project for me. The fact that a small team could, in a few months, produce an amazing app that solved real problems and gained notoriety was amazing.
As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster. I'm also a fan of Zed and everything they're doing, but it's notable that shipping next-gen editor software takes a lot more developer effort now than it did in the 2000s.
> As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.
The Graphic Editor workspace, in fact all the Adobe programs alternatives is quite open.
I remember using Paint Shop Pro, and it was bought and killed by Corel. I would prefer to keep using Paint Shop Pro, instead of Photoshop, because it was super fast and had all the features I used and wanted.
Ask people why they can't migrate to Linux, and half or more of the answers are: Adobe.
> it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.
Yes I agree but so many things that might seem "done" (and in someways I think software/SaaS as an ecosystem is "done" compared to where we came from).
BUT - so many companies just bloat themselves and their products. I think the end of ZIRP is going to have an effect on that (more enshitification / rent seeking for sure) and I think there will be an opportunity to iterate and make copyware that doesn't take the higher development efforts.
We really need a winning electron alternative that is more resource friendly. That, IMO, will be a big game changer and I know there are lots of promising alternatives already.
I'd forgotten all about it but SubEthaEdit was such an amazing tech when we were using to collaborate internationally back in about '04. It went off my radar but I am glad to see its still available as a free app.
I don't understand why text editors became so complicated. When I ran zed, I think my gpu wasn't properly used and it ran at 5 fps. I couldn't even get the thing to boot..
Remember when people had 1024x768 and coded perfectly fine software without instant messaging pinging every few minutes? We peaked there
What I remember from those days was saving my work reflexively because the chances of the window manager or text editor crashing at any given moment were quite high. Also, emacs came in for lots of grief for being so slow. Remember “Eight Megs and Constantly Swapping?”
This is not necessarily to endorse Zed; I’m ecstatically happy with my current text editor. However, “we peaked 25-30 years ago” is just not true. Things have gotten better and they continue to do so.
I tried the collaborative features to pair program with a colleague a few months ago, but it was bad. It was very flaky in establishing a connection. In the cases we were able to establish a connection, the voice chat would not work. We tried to make it work for a couple of days, and then we gave up. Has there been lots of work in the past few months on the collaborative features?
I’ve been using “The Notioning” for the last few years to refer to the convergence of tools like slack adding notion like features, clickup adding notion and slack type features, and so on. There seems to be a stable set of features that retains teams in an org
I was very surprised to find a "forum" integrated in Zed when I first opened it. But to be honest, it is not something I ever felt the need for and overall I don't like having this in my text editor. So far it never got in my way and that's a good thing, I hope it stays that way :)
It would have been good to include a link to the collaboration docs https://zed.dev/docs/collaboration in the article. There were a lot of links in that article and a lot of assumptions that I knew how things worked. And I daily drive and like Zed, but I had so many questions.
I don't work at zed anymore but I do find it funny that anyone would think that the collaboration features of zed are "tacked on"...
We started building zed in zed using it's collaboration in early 2021. Collaboration has always been part of it's DNA. Nearly everything at zed is written in pairs over collab.
I joined a Zed hackathon at RustConf 2024 where I built the "Open in split" functionality from the file fuzzy picker. A member of the engineering team who was floating around helping folks had us exclusively work through the included collaboration features. It was a great tour of the editor, and did not feel tacked on.
I understand interacting with other engineers right in the editor but I dont get why so many collab tools need to be bolted on to what is basically a text editor. This will only fragment communications since its not just engineers that work in any company. Meaning you'll now have communication spread out in Slack and Zed making collaboration difficult, not easy.
I dont honestly dont get the allure of pair programming. My pair programs are the unit tests which I run as often as I can and limit discussions to Gitlab/Slack. I have worked ag FAANGs and large companies and never once pair programmed anything.
I honestly cannot think of a single software or process problem that requires real time collab in the editor. Having said that it is a cool feature and I quite like Zed as an editor.
I listened to the founders explain that the current process of syncing up to review or question code is very multi-step and sort of inefficient almost adversarial at a high level. A slack mention, Github discussion, screen share, etc it all ends up being kind of disorganized and painful versus just being able to edit the document collaboratively and directly, perhaps leaving some metadata tagged at certain locations (e.g, notes from a conversation about the code).
It's not like the editor prevents one from still using slack and other external tools, either. I guess I just see the value in in-editor integration to handle that stuff more smoothly, at least for those using the same editor.. I can see myself really appreciating the feature if there's a part of the codebase that consistently trips people up or is under active discussion.
My understanding was always that this is a way to monetize a text editor. How else do you monetize dev tools? Developers are used to very high quality free tools. You’re either one of the few old guards (like JetBrains, Microsoft or maybe Oracle) that can sell IDEs and other dev tools because 25 years ago open source dev tools were far from beginner friendly.
But how do you monetize a programming language, a text editor, a build system, a terminal emulator, etc in 2025? The examples are deno, bun, mojo, nextjs, zed, earthly, warp, etc. all know they can’t monetize the actual tool. You monetize services that you build around the tool. Like a cloud/workers/deployment (basically compute), or a sharing service or an AI service, etc. once you have critical mass on your platform, you can find other easy services to offer. Like if Zed has a critical mass of users, maybe the offer “in editor chat”. A small startup with just 3 devs working together can replace slack with zed. Maybe they offer an uptime check service. Why not? Maybe a file sharing service. Maybe a small wiki service, etc. all things that have million other solutions. But if you have critical mass, someone will pay for those things.
> I dont get why so many collab tools need to be bolted on to what is basically a text editor
It's because the collab tool wants to have access to the code as it changes live. It could and should be done in an editor-agnostic daemon like LSP, but then you wouldn't have editor lock in. And that's why both Zed's collab and VSCode's LiveShare are builtin.
Anyway Zed has a very interesting idea to provide links to codebase places that remain stable even after the codebase changes. This is pretty cool, because so many discussions about code quickly become outdated
> why so many collab tools need to be bolted on to what is basically a text editor. This will only fragment communications since its not just engineers that work in any company
Once they finish their collab platform they can make it standalone.
The current version in Zed seems to be isolated very good.
As long as I don't have to use, feel free to include it. It is really not essential feature for editor.
I run update and Collab requires you to sign in... which again, it is fine if you want it. I don't, so it can be dormant, icon is really tiny, doesn't take much space.
The feature of Zed that is most annoying yet essential is frequent updates. Pretty much daily when I switch to Zed window, I can expect update and restart, which messes up my window layout, so this is annoyance. Getting updates and knowing you guys are shipping good stuff is what is essential.
I think integrating terminal ai's is great move and useful. Sometimes I use it like that, often I use it in terminal (like the outside of the editor terminal) and switch to editor to review or update stuff. Same with git. I am old-fashioned.
Looks a lot like Google Wave. This is interesting for some things but I don't think coding is it, for the same reason that IntelliJ's CodeWithMe doesn't work for pair programming. And apparently one of the guys is a former Pivot, so it's a little surprising.
Pair programming is Two People One Cursor. A critical aspect of it is you're both looking at the same lines of code and working on the same problem and following each other's thought processes.
CodeWithMe (and it seems Zed) is Same Codebase, Same Day. There's no shared focus. You edit stuff, I edit stuff, maybe there's overlap. But this isn't much different from doing separate git commits.
So far the only remote pairing tool I've found that works competently is pop.com.
Pair programming so often degrades into one pilot and one person just sitting there trying to catch mistakes. When those mistakes are caught they are mentioned taking the first persons attention away and breaking flow.
In contrast how I like to work, with similar level people, is to work at the same feature in the same codebase at the same time. We either sit next to eachother, or have a remote call, where we continuously talk through what we want to achieve. Sometimes this results in one person writing ahead (code, docs, doesn’t matter) and the second sweeping behind it and cleaning it up. Two cursors, one source. IntelliJ even manages to keep authors correctly in git.
The other mechanism is where we work on different parts of the code base at the same time. Either main code and tests, or split across interfaces and implementations. Because this happens on the same machine the iterations are way faster as they are local and incremental.
This basically saves the whole dance of creating branches, pulling/pushing, the fixing typos etc.
With zed you can also share your screen in the editor which makes it a bit better, but still you can't take control of the other machine.
IMO if you only care about coding doing it in the editor is the best approach, you get zero latency and have all the context that you need (most of the times). But if you want to do more, like opening the browser for whatever reason, or teaching how to use a specific cli, etc, then taking control works better.
If you liked pop you might like gethopp.app, which is an OSS pair programming app (full disclosure I am the co-maintainer). Unfortunately because we have chosen tauri for the frontend we can only support macos and windows, but I am working on a solution for Linux too.
I never used Zed collab, but isn't there an option to follow someone's cursor rather than having your own separate cursor? Zed even has an option to follow the cursor of an AI agent ffs.
I know that VSCode's Live Share allows you to follow the cursor of someone else. However Live Share is very buggy and will disconnect at times, so it's more like a cool demo than a product.
I'd say it's medium gray on white, which is not too bad in my subjective opinion. I have seen far worse. Light gray on white was "trendy" for a while and dark gray or dark green on black has always been popular among the edgy crowd.
Looks very cool, and of course it's nice to basically have Slack inside of Zed.
But personally, what I want in a Code Editor / IDE, is to be the very best experience at writing code and working with code projects. That is what will save me time and make the coding experience better.
Collaborative features are nice but not essential since there are other tools out there. It's not likely to move a team away from Slack (though if it's self-hosted, it stands a chance).
I'm not yet at the point where I can rely solely on Zed for python coding. I mostly use Zed because I like new initiatives, especially open source ones, and it's fast and responsive. But PyCharm is still better for python development at this point, with its one black mark being endless indexing on large codebases / dependencies, and I find myself falling back to it regularly. I would argue that the priority should be to achieve parity as a _code editor / IDE_, and then we can talk about other shiny new features.
I use Zed instead of my normal text editor because it opens instantaneously. But I don't write code in it, and still use my IntelliJ + IdeaVim with Claude Code and Codex in a separate terminal in Ghostty.
But Zed is an insanely fast text editor to open text files in. Just double click and it's on the screen. Love that. Maybe over time I'll do more in it.
I do use (and am in the Backers.md of) neovim. But the GUI versions open much more slowly than Zed. Zed is near instantaneous. I do often edit text in neovim by opening a terminal window and doing things, but the experience of browsing a large log file and filtering through it is much nicer in a GUI text editor, so if I ever double-click or open a JSON file I want that to happen instantly.
I can't stand Nano. I find it impossible to use because my brain is strongly vim-bound.
I kind of love this, although I feel like I'd need to try it out to understand exactly how it feels. I'd even like to see a video if Zed could make one. It would be good to understand e.g. if the issue of "who wrote that?" actually affects things in practice, or any other weirdness or limitations.
I also kind of get why it's built into an editor! I wonder how it compares to e.g. https://www.coscreen.co.
The default method of remote work, with e.g. Slack and video meetings, I think leaves a lot of potential on the table. I wonder if a flexible collaboration system like this could actually be a lovely default method for many companies.
What I see in posts like this is that it becomes clear to me that I am not their target demographic.
I work with IDEs and low-code/no-code tools, VSCode is kind of unavoidable in some scenarios as it has become the only programmers editor that some companies bother to provide tooling support for their SDKs, and that is it.
For bettr or worse, everyone and their dog that used Eclipse forks for their SDKs, now is doing VSCode forks.
For historical UNIX purposes vi and Emacs, and then any editor will do when changing some bunch of configuration files, in case nothing else is installed.
In no project I would be able to make Zed our office, that is what stuff like Monday, Jira, Confluene, Trello, Workfront, happens to be.
Zed looks really cool and I would love to give it a try, but I am just too beholden to devcontainers. I know there are workarounds to use them with Zed but with many extra steps compared to VS Code and it's forks. I can't go back to not having a totally integrated container per repo.
Really user here:
Switched from vscode to zed for ~2 weeks entirely in a windows PC, getting back to vscode today, just not feeling good enough:
1. zed updates frequently, but I'm not feeling any update at all. I mean, no new features, not fixing stuff that I'm experiencing that's not good enough;
2. while it put heavy in AI stuff, the ACP thing and the integration of codex and claude code just not working as expected as is. Especially I'm getting really poor outcomes from the same tool in zed compared to the cli itself, which is really frustrating;
3. the terminal in windows zed is barely usable, it's slow and slugish, sometimes the texts or some symbols are not rendering properly, it's just not stable at all. I really like to use the terminal inside the ide especially when I need to start up dev server, but with zed I'm used to open an extra terminal app when I need to start up dev server;
4. I'm a frontend dev, which means the tech stack should have great support in morden editors, but the case is not quite right in zed. I got jetbrain style inline type hints for typescript files with deferred types, but it is so annoying cause it makes a line too long I may even need to scroll horizontaolly more than may screen width to see the content at the end of the line, but the line has only 40 chars. At the same time, I'm not sure how to shutdown this feature after openning the settings. And when I want to set wrap width to 80 chars, I don't know how to do this either. The settings maybe there and are easy to tweak but it is not doing great to make the user understand it and use it;
5. it constantly showing some language servers are down and I don't know why, I do not like to tweak with settings so it could not be my bad, I don't event know how to touch the language servers;
I have more to input here but I forgot some of them, overall, I just want to get back to vscode which is much easier and battle tested. I think zed have a totally different perspectives on feature sets and stuff, that's good, so people could have another choice. Hope zed could do great and I will definitely come back one day.
PS: I don't think collab worth too much effort in an IDE, you have much better tooling out there and have better intergrations.
Here is where I've settled on for Zed. I initially thought it might be a Sublime replacement for one-off files, but it seems it's geared towards projects. It's not as powerful as Jetbrains (RustRover, PyCharm etc), but is much faster. So here's how I'm using Zed:
- On my Tablet, which is too slow for Jetbrains IDEs to run smoothly
- On certain projects I have which choke Jetbrains IDEs. (Due to macro use maybe?)
I think its' a much nicer experience than VsCode, which I admittedly haven't figured out to run in a project-oriented way.
I'm also trying their GPUI library, but am in the early stages, so can't really comment on how it compares to EGUI.
Zed is the only modern IDE-like editor which is fast enough to replace (n)vim for me. I plan to use it for more and more projects, but I've had minor issues with it's Vi-mode.
I'll always remain someone plugged into vim because I need it sometimes when shelled over a terminal. Editing files over SSH can work with editor support, but is often less reliable or fast than jumping through whatever hoops I need to to get an SSH connection once and then doing everything from there.
I just have a few plugins which help. Mainly the LSP for gotodef and popovers for type info, etc. This was what finally made me transition to neovim. Also a tree viewer, Startify, and :Rg for ripgrep integration. Those are my big ones.
Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
> Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
I'm sorry... what?? I still use vim as I haven't found a reason to jump to neovim, but you're telling me external commands don't work properly? That's wild.
They "work"... but instead of switching back from the alt screen and giving you your terminal back, they open a gimped little window within vim which makes it hard to navigate, copy, and search for things in the output.
Surface tablet, so it's like a laptop. I can kick the keyboard off when I'm reading stuff, to allow room for food and drinks. And I do drawing/notes with the pen.
Another way of stating this: It's a general purpose portable computer; not specialized coding PC.
i'm now guessing the software engineering universe is becoming like the lawyer ones
1. big corporate shops / vc funded ones - many tens of programmers working on features (this is where zed collab features might be needed)
2. bespoke high productive small teams - less than 5 product programmers in a company e.g basecamp - these would be your bespoke law firms
3. the indies (injury lawyers) -> 1 - 3 programmers chunning out products at scale or eating of one product + maybe with help of A.I
for 2 & 3 - a lot of stuff being shilled is not needed. a legal pad + some notes that can be posted via a google doc is all that's needed. Jira isn't needed too
There is a lot of complaints about Zed in the comments here. I don't think that they are "hate", per se; they all definitely care about Zed and want it to succeed.
I daily drive Zed for work across several languages and I love it. I use a lot of its features, like the git interface, agentic editing, etc. I might even consider paying for Pro in the future if I want unlimited edit predictions.
However, all of these complaints are fully justified. I think Zed is a massive undertaking, only one that a VC-backed company has the capital to do. iirc, it requires 70k lines of Rust just for the cloud part [1]. I cannot fathom the amount of fundamental infrastructure they have to get the editor functional at all. That doesn't excuse all of the papercuts in Zed though.
If I were Zed I would do the following:
1. stop all work on future features, like DeltaDB etc. They all seem extremely cool but they won't meaningfully contribute to increasing Zed adoption or fixing its issues.
2. remove all agentic editing features. if Zed tries to simultaneously become the world's best agentic editor and a good general-purpose text editor, it will fail at both. Keep around ACP so users can still use other agents, but remove all of Zed's built in agent stuff.
3. fix literally every papercut. Triage every single issue and go through every PR, even if it will take half a year to do so. People won't switch to Zed until it's perfect, and the existence of this many issues means it's not perfect enough.
4. make extensions actually good. Every programming language, library, etc. has it's own ecosystem, and many such ecosystems mainly rely on VSCode extensions for advanced features. Zed needs to be extremely extensible like VSCode is; obviously its architecture makes this slightly harder, as it's nontrivial, for example, for extensions to render their own GUI, but there are a lot of low(er)-hanging fruit for extensions that need to get solved. People will only switch to Zed if they can get a similar breadth of ecosystems.
Of course, this won't happen, and given that none of these will really make them money, Zed has no incentive to focus on these, especially given the amount of time they would need to do this. But I think that if Zed can't nail the core experience, it won't get anywhere.
Technically really impressive. In practice, completely unpractical in any medium to large organization. And although I adore Zed's speed and reliability, I still don't understand why we need these features at all.
Because "maximum editor" was achieved with Visual Studio Code (which is why all these new editors look and feel like VSC), the same way "maximum toothbrush" was achieved with the electric toothbrush. But the toothbrush industry had to keep going, so now we have a $400 bluetooth connected toothbrush-as-a-service that monitors your brushing habits to optimize teeth cleanliness, with brush heads that cost more than 5 regular toothbrushes.
Zed and the current crop of AI editors (including VSC itself) are that toothbrush.
Their collab feature looks promising. But I can't move to Zed yet, because it's laggy on both my Linux laptop and workstation. They need to fix these issues first.
To me it feels like 2 different set of products, what they are showcasing here seems very similar to slack/teams.
Of course, it would be awesome to have a faster and open source slack, and if I can take notes on the same style as my editor great. So I guess, it would be nice to be able to embed zed in another product.
I think this would be appealing for a company that it's core product is code, like zed, but I do wonder if other companies even need this functionality.
Your company has a user pool, you sign a BAA or start working with a partner company that has their user pool. Instead of creating slack accounts in both you can share external slack rooms that only people that are invited in/from their respective orgs can join without having to co-mingle employee user pools.
But why would external partners want to look at your code? I guess if you're also integrating with them? But generally you just give them repo access instead. For Slack, it's different as messaging is a core feature to collaborate between different people in different companies, but looking at code is a very specific use case.
Not sure, I was only answering in regards as to what Slack shared rooms brings to the table for companies in the form of letting Project Managers/Account Managers have direct line of contact with clients.
Code wise I guess you can could be working with any agency or contractors and you could collab on PR reviews? No idea to be honest.
Very cool idea, and helps promote owning your own data, and it being highly interoperable (plain text!)
I do wonder if we need a term for shoe-horned dogfooding though. Like sure, you can do this. You could do this in Figma! Or in Notion! Or in LEETCODE if you wanted to.
At least with Zed though, its plain text. If you find another way to collab realtime on plain text, you're not bound to 1 vendor.
people live-dumping their comments into a text doc while i'm presenting with no ability to know _who_ left a comment (unless they manually prefix their name) really showcases that its the wrong tool.. https://i.imgur.com/vEttouw.png
While certainly an amicable goal, I doubt that many companies/groups would be willing to put their comms inside zed, where it feels locked outside any other ecosystem.
Because I'm apparently a billion years old, I still use Sublime Text and just text editor. If I do switch, it will be to this. However, is it as responsive? Do file changes just appear if I change them elsewhere in like terminal?
I’m always _this_ close to adopting Zed, but I just can’t get used to the project search. I’m too used to telescope now. Maybe I need to bite the bullet because I think Zed’s search is objectively better. Old dog, I suppose…
As mentioned in the post, Zed's collaboration functionality is its core USP. The entire editor was literally built around it. IIUC their moonshot is to replace the GitHub PR model with something more collaborative and granular.
I love Zed as an idea. They built some impressive tech. They're clearly a smart and capable bunch. I tried zed out for a bit, then I switched back to vscode.
Zed sounds desperate, nobody in the world would use Zed as office. Zed is a niche. Nobody wants it's multiplayer features since coding id usually asynchronous until crunch happens and nobody wants crunch All the time.
All office have their own communication tools , you can't expect all developers just to use zed l, it is missing features and the whole ecosystem which would take one more decade and non development people won't even touch it. Then the office cannot happen inside Zed for the rest of the world, except Zed team.
I have been trying to figure out how this works in concert with Git (or SCM in general). Is one of the developers in the session merely responsible for it?
I mean, you have the same "problem" when peer coding in person. Whoever is officially working on the fix will commit it. I've helped devs get around a hump for ages, you don't get "credit" for all the work you do. It's why I hate most ticketing systems (when management starts to ask why your tasks fell behind), they don't let you correctly track multiple people when they work together.
The collaboration tools built into Zed have basically existed since the product launched. It is one of the primary drivers behind the product - they wanted to build the best editor for remote code collaboration.
I think the most difficult question are going to be how do you constraint that core feature without ever wanting to add more to it?
For instance, collaboration is a huge topic. You can have coding collaboration on the file, and that would be basic and appropriate, you can then replicate slack and you'll have chat rooms, which is entering creep territory, but it's natural! Then soon the chat room will need to link with issues and you can now have TODOs linked to some kanban board and we should be able to speak while we code on the same file! And this goes on and on.
It's exceedingly rare that the organization found hard courage to specifically avoid features that looks like easy pickings for the purpose of avoiding them.
This is interesting to read and very important to me since I am building a coding agent with team collaboration in mind. I used to use Zed daily till the point that I moved away from writing code directly and instead generate all my projects only from prompts.
I think collaboration for people who eventually use the software will be more critical in the era of agentic coding. Project Management will change. We are not waiting for 2 weeks to build prototypes, it gets done in a hour. What does that mean for end users - do they prompt their changes and get access to new software? Who would double-check, would AI reviews be good enough, would AI agents collaborate along with humans in the loop?
There are so many questions not answered. If anyone is keen on having these talks, I would happy to share what I think. Here is what I am building: https://github.com/brainless/nocodo
I want to see a future where end users can prompt their needs, have collaborators in the company to help clear things up and in an hour the feature/issue is tackled and deployed.
Yes, that is correct, but this indicates change of the product direction that make me lost any trust or interest in it. Their core features were done nicely, they should have stayed and developed them, maybe introduce more file editing related functionality.
It's nice to see Zed's collaboration features discussed in their blog. The collaboration features are really what makes Zed such an interesting project and product. I was worried they'd gone full AI hype train. There's so much opportunity to improve digital collaboration tools.
I love Zed. I, mostly, love the direction they are taking the editor in.
But. There are now two times I see Zed going in the wrong direction. The AI integration was one. This feels like the wrong direction again.
I never really liked the AI integration. It felt off to me. I do love coding with Claude and I think I know why. It presents the "information I need to know" in a way my puny brain can handle it. Colored diffs. Summaries of what happened. It isn't perfect, but it has been incredibly productive for me. I never got that from Zed's AI integration; perhaps this has been improved, but I was up and running with Claude in a way that I never was with Zed.
This write-up sounds like "slack in my editor." If it is that, I hate it. Slack has destroyed company culture and communication. People, who are inherently lazy (I'm an old Perl programmer, so I can say that), have stopped thinking carefully and writing carefully, and in that void just throw the first thing in their head into a slack channel and think that is "collaboration" and "communication." It's toxic.
For example, this comment rubs me the wrong way: "Staff members hop in, volunteer to show off a cool feature or bug fix they worked on, and get real-time feedback from the rest of the team." I don't think our human brains work well with "real time feedback" UNLESS we have the information presented in a way that gives us massive clues on what's right and what's wrong. Reading a wall of text is not the way. A colorized git diff, or a video, or an entirely new way of presenting information might make real time feedback possible, but I am highly skeptical a text editor is the way or place to do that. And, I'm an emacs user and love text UIs, don't get me wrong.
Do I want to have "generalized one off rooms for things that don't fit anywhere?" I definitely don't want that. I want you AS THE AUTHOR to be really intentional about what's important and fit that into the proper channels. I need to know that information, but I don't want to know about, nor have the unspoken expectation that I SHOULD have known, about the other stuff. And, I want "managers" (if that still exists) to be carefully thinking about those channels and how the company is organized and push that structure down to people in the organization.
As Zed is the office, having one off rooms instead of in person coffee time feels very dangerous. That's the world a lot of people live in, but I don't like that office.
If this comment is the guiding light, then I'm worried: "We're building toward a future where collaboration is continuous conversation, not discrete commits—where every discussion, edit, and insight remains linked to the code as it evolves, accessible to both teammates and AI agents." I'm human, I have kids, I have other interests. A continuous conversation is impossible for me. I want discrete ideas, and right now, discrete commits and PRs are better, IMHO, than what I hear here. It's hard, but setting the expectation that to be successful I need to be paying attention to a river of information flowing by seems like a bad idea to me. I don't buy that Zed solves the problem of hiding the pieces of information that I don't need to see.
Oh hey! I have an idea. Why not use AI to summarize those conversations into discrete pieces! </joke>
I do love Zed. It is the best GUI editor out there. I know they will get it right. I just am skeptical about this direction and feel it misses the forest for the trees.
Man, Im like the total opposite in terms of preferring the Zed UI vs claude code. I really try to avoid raw claude when possible. I very rarely pull it up to do concurrent sessions when I have Zed open already working on something else. Or if I need to do something quick while in the CLI in a random directory. Otherwise, I think just the "files modified" feature is worth using Zed as the primary interface.
You make some good points, and I need to revisit Zed+AI to see where things are at. This probably proves you are a better developer than me.
But, also, after reading your comments, I'm just not sure I need an "editor" anymore. I love that I can npm install claude anywhere. Zed does not exist for ARM servers yet, but I can install claude there, and it can troubleshoot my database connections, and edit code, and grep files. Those are all the things I used an editor for, because an editor has better ergonomics than using the CLI. I'm sad to say "misspelled prompts" might have better ergonomics for me.
If I were still hardcore avoiding a GUI Id probably be in the same camp. But I moved to VSCode as my primary interface a long time ago, and Zed is just a better version of my workflow when comparing against that.
100%. I also moved to VSCode years ago. Then, I got disillusioned by the performance, and by M$ telemetry. Zed is so much better in so many ways if you have to go with a GUI for all those reasons.
I agree about the bad side of slack culture, except when compared to how things were before slack: Horrible email threads, in-person meetings, phone calls, and people walking over to your desk to ask you stupid things they could have looked up themselves.
Slack revolutionized this for me because I can turn it off anytime I want. When I want focus, I close it and it cannot reach me for some time. Then I pull it up and read all the threads while taking a poop.
Having it in zed is the same: You can just log out of collab anytime you want! You would only use it if you _want_ to use it. When you do want to use it, it's incredible. Someone can just join your channel and work on a tricky problem with you and you don't even need to screen share. It's like the best of discord and slack available at the touch of a button. It's much lighter weight than slack. Slack huddles are super annoying to me. I want it to behave more like discord, and that's what zed does!
That's a good point. Email is much worse than slack.
But I still think it is impossible to manage all the things happening in slack. And the expectation is that it was said in slack, so you should know about it! Whereas, I definitely go through and review PRs and if there is a culture and management agreement around good PRs, then I can easily understand how things work, how things have changed, etc. I never get that from slack. And, I never got it from email either, fairly.
The topic of "expectation" is really interesting and worth discussing more. I refuse to accept the expectation of slack meaning I am literally always available to message, and also that I must read and keep track of everything in there. If somebody asks me about something and I suspect it might be in slack, I might do search for it to catch up on that topic if I am inclined. But obviously so many people feel the pressure you're describing (to know about everything said in slack)--- which sounds terrible!
Ever since Apple Silicon macs came out, it's been a real struggle. Almost 6 years later and there is still nothing on the market that:
* Has the same level of performance
* With the same or better battery life
* With the same quality of screen
* With the same quality of speakers and touchpad
* Runs as quiet or as cool
as the Apple Silicon macbooks. If you add in "needs to be able to run Linux" your choices go down from maybe 1 or 2 to 0.
They all have some sort of compromise. Either the speakers, screen, keyboard, touchpad, build quality, battery life, or thermals.
I have a Surface Laptop 7 with the Snapdragon X Elite, and it's pretty close. Checks the boxes for Screen, build quality, and touchpad. Loses out on speakers and battery life, and the fans need to run a lot more than my M4 Pro MBP does. It also loses on performance, and it doesn't run Linux. Windows on Arm also still has a lot of little quirks and bugs that start to become daily annoyances.
It's incredibly frustrating. I want, essentially, my 14" M4 MacBook Pro, but in a Linux laptop, and there's no OEM out there that's fulfilling that need without compromises.
Apple keeps pulling ahead in silicon and every other laptop OEM is just being left in the dust, shrugging their shoulders, and putting out the same old 1200p 16:9 plastic garbage they have always been putting out.
I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
I feel the opposite way, that git branching and merging will become a bigger part of the job as more code is written by agents in parallel and then accepted by other agents or humans.
for now yes absolutely. but I’m already hearing rumblings that some people are having luck letting multiple agents edit the same directory simultaneously instead of putting changes through PR merge hell. It just needs coordinations tools, see https://github.com/Dicklesworthstone/mcp_agent_mail as one (possibly insane) prototype
for example it’s not out of the question that we could end up with tooling that does truly continuous testing and integration, automatically finding known-good deployments among a continuously edited multiplayer codebase
we’d have to spend a lot more energy on specifications and acceptance testing, rather than review, but I think that’s inevitable - code review can’t keep up with how fast code gets written now
Having tried a janky version of this myself with a NOTES directory, I am very bearish on this being a better workflow than just improving the ui wrapper around git worktrees and the isolation that provides.
Codex already has a fantastic review mode, and gemini / claude are building tools around pr review that work no matter how that pr was produced, so I think this interface is going to get baked in to how agents work in the near term.
Yes, but does it need all the ceremony surrounding it? If, every time I saved the file, the changes were analyzed and committed to git, and a useful commit message included, and commits squashed automatically and pushed and tested and tagged (using magic, let's say); if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?
automated commit message will tell you the "what" not the "why".
In any circle of "what makes a good commit message and why even do it" discussions, invariably the recommendation is to explain the "why" and leave out the self-evident "what".
If your stance is that commit and commit messages can be automated away then we might as well not even have them.
I don't share this view, but yeah in this world we don't need AI to do things that shouldn't be done in the first place.
You can't see any value in being able to see the "what" in a short bit of English at a glance vs having to analyze a 300+ line diff to figure out what it's doing?
increasingly, the automated systems have access to the original ticket or bug report, and maybe even the conversation while implementation is happening. They can record the “why”
I love it when I have a tool that’s “done” but the software I work on in my career is never, ever done. It’s almost like there’s two different things we call “software”. there are tools like, idk, “curl” where you can use and old version and be happy. and there are interactive organizations in the world, like, eg, Hacker News, which mutates as the community’s needs change
Software for evolving business-needs is the same for me. What's insightful is that we (I) take continuously evolving software as just that: evolving. It's a defacto virtue to continuously tinker.
Doing away with check-ins entirely is the extreme end-game of that pov. I'm in product and every day and every week yes we very much continually change the product!
But I'm growing less convinced that the natural end-state of this methodology produces obviously better results.
it doesn't work quite well for complex projects that require integration with other teams/software.
You would need to either have separate versions running at the same time or never do breaking changes or devise some other approach that makes it possible.
I think that’s a tooling problem. Maybe we do end up running a lot more versions of things in the future. If we believe that code has gotten cheaper, it should be easier to do so.
Imagine if someone clicks the deploy button when you're in the middle of typing something and then the service goes down due to a syntax error. To prevent this, we will need some sort of way to set a global lock to indicate that "I'm not done typing yet" and you can only deploy once everyone has released this lock.
Or you don't deploy unless it makes it through at least testing, and a build started while someone was editing the code would probably fail fast unless you coincidentally hit the button right when it's valid, but wrong, code.
It's truly showing that the zed team is chauvinistic by dismissing different encodings not being supported and focusing on other things. "It wurks in merica", it gut i guess
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....
https://github.com/zed-industries/zed/issues/38109
Hopefully soon I can give it another shot at full time usage.
> 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.
Rust forces you to consider things upfront, or to put it another way, a C developer does what the borrow checker does manually. Sometimes, they do it after asan/ubsan/tsan has reported the issue. Sometimes it's after a segfault. Usually it's after the user hits the bug already.
Nix similarly forced issues to be reasoned with upfront.
Yes and most people are happier with a garbage collector than using C, C++ or Rust. There are domains or projects where you have to use one of those languages, but Rust is being used and promoted far outside those niches.
I think LLMs have solved that for Nix. I recently moved my homelab from an Ansible/Debian setup to NixOS. As long as I understand at a high level what Nix is and what problems it solves, I can let the LLM deal with the configuration language.
I didn’t say “just use Nix”, I jokingly made a reference to street evangelists and the similarities they have in their approach with people who are excited about a particular technology. In fact I said “Nix or otherwise” implying there are many options when it comes to reproducible per-project environments.
joking or not, people are very tired of the evangelists (fanbois?) from these ecosystems, and this culture around them is one reason others stay away. The broader trend is developers are burnt out on tooling churn
So you rather stay comfortable doing what you were always doing, which is fine but programming is everything but that...
Complexity for the sake of complexity is not a goal everyone should be striving for.
> Complexity for the sake of complexity is not a goal everyone should be striving for.
THIS !
Go's well maintained stdlib just lets me get on with it.
With Rust meanwhile, I have to decide which of thousands of third-party Rust crates is sufficiently en-vogue and well maintained.
Most of my coding work is backend stuff that calls a lot of HTTP APIs, parses a lot of JSON and does a lot of crypto. All that is ready-to-go "out of the box" with Go stdlib and on top of that is faster to get to production in Go than in Rust.
I don't need or want Rust's complexity. As I said I have enough going on at $work...
I always feel like choosing between rust and go is like picking between node (ts/js) and python when it comes to stdlib out-of-the-box-ness!
That's a fine opinion to have. You just have to fight a separate shoggoth of a mutable-root system, which mainstream Linux vendors like Google and Valve have avoided.
It's similar to the Rust situation in that many Rust programmers are simply tired C++ programmers fed-up with using Valgrind and Cmake. Nix is the retirement-home for people who clean up package pollution and just want stability at any cost.
In the case of AI tools it is for security reasons, not just reproducible toolchains.
We need more selinux and sandbox-exec in daily dev lives. There's no reason to bring a whole new system along just to restrict some access.
Docker is just a shim on kernel isolation APIs. It’s not any different, but better packaged.
But irrelevant in this case. I dev on macOS. I’m not aware of any other options.
sandbox-exec. It's not great, but it's usable. https://igorstechnoclub.com/sandbox-exec/
> It’s not any different
It's very different. With docker on Mac you're running a VM which runs a wrapped up complete system that runs your app.
With selinux/sandbox-exec you run just your app and can skip the extra packaging needed for docker and mounts. (And get the extra performance)
Does selinux/sandbox-exec work on a Mac? Is this an apples to apples comparison?
sandbox-exec is a Mac exclusive thing.
Wow TIL
Any references to how you use selinux? I've used bwrap and firejail, but I don't feel confident that I'm not leaving holes open?
Honestly - no. To use selinux you need to commit to actually learning how it works and experimenting a bit. I don't think there's an easier way than reading both redhat (https://docs.redhat.com/en/documentation/red_hat_enterprise_...) and NSA (https://www.nsa.gov/portals/75/documents/resources/everyone/...) docs.
If you're happy with firejail, make sure you use whitelists only and you'll be 90% there with what's possible to achieve.
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
Claude hooks are great for this.
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.
Theres a plugin for Claude Code and you can use Claude models from Copilot in IntelliJ. Are those options worse than Zed, especially considering other comments about Zed missing basic editor stuff?
Claude Code in IntelliJ just opens a terminal tab. Claude Code in Zed feels integrated into the editor as if it were a natively supported model.
The copilot plugin with Claude models (Sonnet models) is very integrated in the IDE, and so is Jetbrains AI (even more integrated than Copilot) which I believe can also use those models. So I wonder what's the actual difference.
JetBrains products has Claude Code integration. Is it worse?
I still use Claude Code in cli, as a WebStorm user.
The plugin just opens a terminal whereas in Zed you get a more natively feeling experience. In JetBrains they do support it as one of their agents but now you have to buy into JetBrains AI credit system instead of just using your Claude subscription.
Theres two ways to use Claude Code in JetBrains and instead of helping them make their plugin better they opted to try and make money off of it. Which Zed could have done the same but instead lowered their monthly to let you use your own Claude Code subscription.
Thanks. The JetBrains integration sounds lousy!
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".
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.
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 :/
> 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.
Yeah same, plus I have poor eyesight so I have to zoom then to click anything
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.
[1] https://github.com/zed-industries/zed/issues/7992
That's not silly! Great UX is table stakes.
It's been that way since day one. Wild that they haven't fixed it. Edit: it was fixed in Oct 2025, version 0.207.4
I have the same problem on Linux-wayland/4K screen. I can't get it to look anywhere near "okay".
Try the latest version, it should be better
Personally, I never registered that as a problem, but I can see the delta in screenshots between versions.
Oh that’s exciting to hear, hopefully it’s better! I’ll give it a shot
So they're optimizing for 1080p or 4k?
No settings to adjust?
optimized for HiDPI screens (like those on Apple devices)
ohhh... is this that thing where people say "blurry" to describe anti-aliasing, because they actually want it to be pixelated?
Nope, it is the thing where people say "blurry" to describe "blurry".
https://github.com/zed-industries/zed/issues/7992#issuecomme...
This is how Zed looks like on my computer too. VSCode manages to render things crisply while Zed is a blurry mess.
Thank you for the example. That shows exactly what I was talking about, so this issue is clearly (at least somewhat) a matter of taste. To my eyes, those VSCode samples look harsh, crudely pixelated like something out of the 1990s, while the Zed samples look like normal anti-aliased text.
No other editor or app that I use on macOS looks like this. None. This is not just AA, I like properly AA’d text.
Ahh, thanks for the explanation. I guess I was thrown off by the screenshot attached to that bug report upthread, where someone compared zed's rendering against completely non-anti-aliased text rendered by VS Code.
No, this is a thing where the text is honest to God blurry on non-4K displays. The macOS version of Zed on a low DPI display has the worst font rendering of any application I've ever seen, and I used desktop Linux twenty years ago.
It's like they're rendering a high resolution font at low resolution using the simplest possible algorithm without lining it up with the pixel grid. It's very fuzzy. Characters have this weird sort of additive color intensity where strokes intersect that reminds me of Geometry Wars. It's broken.
They are working on it; the Windows build has decent rendering, and apparently the Linux version substantially improved recently. But they haven't gotten to macOS quite yet. I've been checking in on Zed every few weeks since it went public waiting for a fix.
It might be. I can't speak for anybody else, but it's probably the term I'd use myself if I was trying to explain it, even if it's perhaps not exactly the perfect one. The pixel edges just end up not hard enough, and the pixel corners just end up not sharp enough, and my eyes don't seem to like it. Whatever they're looking for when they're looking at text, pixelly text and printed text seem to supply it, and anti-aliased text doesn't.
(Though there must be some cutoff point past which the pixel size becomes irrelevant. I certainly don't mind reading stuff on the iPad.)
It says they're targeting Spring 2026 for their 1.0 release, so I'll treat as beta and put a calendar entry in for April 2026 to check back in on it.
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
This, 100%.
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.
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.
[1]: https://github.com/zed-industries/zed/issues/37448
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.
Oh yeah I’ve noticed both the desync and AI not working via ssh.
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.
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!
Agreed, we should support this!
It’s not just a nice to have. It’s a hard requirement. If I can’t launch agents within a sandboxed container, I can’t use your product - by security policy.
Curious about the failure to detect FS changes made outside of Zed. Are you on Linux?
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.
Very strange, this has always worked for me with Zed - both with local and remote ssh sessions.
I use `"autosave": "on_focus_change"` which may be keeping my buffer in sync with the file contents as I switch between terminal and zed.
You can configure Neovim to either auto reload or to ask you whenever a file is changed. (Can't remember which one is the default, probably to ask.)
I'm ~80% sure auto-reload is on by default, and 100% sure that it's on in a fresh LazyVim install.
vim.o.autoread (default on) When a file has been detected to have been changed outside of Vim and it has not been changed inside of Vim, automatically read it again.
Thanks, just found something about that.
Plain vim asks what to do by default. A single 'l' does a reload.
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).
You may enjoy Helix as well: https://helix-editor.com/
Agreed. I hear way too much about Zed considering the editor doesn't allow a window to be popped onto a second monitor.
On MacOS 10.15, I have 2 monitors plus the built in on a macbook pro, and I have Zed windows on all 3 of them all the time.
You have to open three Zed instances, don't you?
No, this works fine with a single Zed instance.
I stand corrected.
nope. Single zed app instance.
I really really don't want comms or multiplayer tools in my IDE.
Don't bring the attention economy to my cave of solitude, it's where I go to escape all that noise
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 removed the collaboration panel from my bottom bar and don’t have to deal with it at all. Can recommend
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
Yea you’re thinking of Ghostty, this topic is about Zed, which is not related. In fact Zed uses Alacritty for their terminal, I wish it was Ghostty!
Zed is sticking to all Rust, it appears, so Ghostty wouldn't work. Also Ghostty has a lot more UI features itself like tabs etc so I don't think it's as easy to integrate in an editor which also has its own UI, so Alacritty being mainly TUI driven makes more sense.
Mitchell has released libghostty which is the core terminal features for this type of embedding
Care to elaborate on Terraform/HCL issues?
I have worked quite heavily with Terraform and went through the trough of despair myself. But after a while I realized
1. It does quite a good job at what it does, given the complexity it's handling for us.
2. We have been expecting more and more from the tool.
Mitchell himself called Terraform stuck in the past in some social media platform. However, I don't see Terraform sucking up all the interest and cash in infra, making the landscape barren so nothing else can grow. So, I hope something better will pop up. Until then, Terraform is good for what it does.
What does Mitchell Hashimoto have to do with Zed beyond a guest blog post?
My understanding is that he is involved in the development of Zed
I find Zed's feature choices to be really poor, and then I probably made a poor association based on his talking about zed
Hashimoto writes Ghostty in the Zig programming language. There might be a mixup here between Zig and Zed.
Yeah, they're not zigging, they're zagging, er, zedding...
I know he's working on ghostty, but I've never heard anything about him working on Zed, was that what you were thinking of?
sorry and thank you, I stand corrected in several comments about my missassociation based on a blog post Hashimoto did for Zed
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.
Their multiple rounds of VC funding are predicated on their vision of collaboration so they gotta make a go at it.
So you're saying that you're not the target audience, therefore it is silly?
people can abstract and reason about issues like...
1. Until this is possible without lock-in to a specific IDE, it's going to be heavily gated by adoption and network effect.
2. What are you going to do about communication with non-devs who don't use any IDE? Do I now have multiple chat tools I need to give attention to?
3. Bringing the attention economy to our primary work tool is probably a bad idea in the long run, given the evidence we have more broadly about the impact of the attention economy
4. They are also proposing a new version control database, which makes adoption and interoperability an even harder task. https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...
5. We are in an AI hype cycle, which comes with a lot of experiments and baggage. We're seeing both fandom and rational pushback against this experiment (and others)
The post I responded to pointed to nothing of the sort. Like many other comments here, it was focused on how the they like to work alone, pairing sucks and this endeavour is a waste.
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.
It could be easier, but it is supported AFAIK: https://github.com/zed-industries/zed/issues/8260#issuecomme...
Unfortunately, we no longer support self hosting. We're planning on reintroducing it once we've polished the single player experience a bit more :)
Oh, that's unfortunate. Why not support it at all, even if just for people who are kinda hacking it in?
We’ve been growing and have had to scale authentication beyond what our original collab server could handle. Not many people are using collab yet, we’re prioritizing non-collaborative features (like our recent Windows release), and we’re planning on rebuilding all of this on top of DeltaDB. Fundamentally, it just fell through the cracks.
Self hosting will be a vital feature for users and enterprises though, we’re planning on revisiting it once we have a few more features settled :D
Cool, thanks for the transparency and info.
I'm really rooting for you guys, and your direction and quality is exciting to see.
Looks like development of DeltaDB has been discontinued.
https://github.com/delta-db/deltadb?tab=readme-ov-file#-upda...
That is a different project :D
Here's our overall pitch: https://zed.dev/blog/sequoia-backs-zed#introducing-deltadb-o...
Looks great. I use some CRDTs like Loro and Automerge, are there any learnings or collaboration you're taking from them to improve DeltaDB?
Also the name, I thought it was a database with CRDTs due to the "DB" at the end of DeltaDB, but it's a version control system, I thought that was somewhat misleading, any reason why it's named so?
Is this / will this be open source? I have a direct immediate need for this and was about to break ground on greenfield implementation. Had no idea Zed was working on something similar. I would of course much rather collaborate than maintain a competing VCS.
Oh is this based on my favoritest data structure ever: zed's Sum Tree?
> last commit 10 years ago
Thanks for the update. Can't wait to hear more!
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.
"Collaboration as it stands today is considered alpha, and for the time being, is free for all to use!"
This doesn't fill me with confidence.
…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.
I personally worry it's not interoperable enough.
...doesn't mean the majority is right :)
That reminds me of a French saying that seems fitting:
C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
It's a personal tool. You're not wrong. Anybody isn't wrong either.
...doesn't mean there is a right or wrong either :)
...but it does mean there is a corporate controlled program that can back stab you at any moment!
Same thing could happen with non corporate open source
Uh no? You have to pull in the change and recompile
Same with corporate open source
AFAIK it’s all open source. If they go off the rails we could fork it.
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.
> What I mostly want from Zed is the ability to see the outline panel at the same time as the directory panel
You can do this now by moving one of them to the right dock (right-click the toggle-button)
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.
> And then toggle between that and the AI agent?
Yes
- Do you want to split a dock vertically?
- Do you want to open the panels inside an editor split?
- Do you want to detach the panels as separate windows? (https://github.com/zed-industries/zed/issues/17618)
Both 1 and 3 would make my day.
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.
> code-walks
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.
Problem is video is expensive and compression can get bad.
I agree being able to see the pointer is important, since not everyone is good about moving the cursor around.
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
> Code by mass live committee. Yikes.
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 just pair programming when you're doing it on code so if you can bear pair programming you'll be fine. Personally, I hate it.
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."
That's not how they, or anyone else, uses it on code though - that's on their notes. This is just a feature, it's up to you how you use it.
The concept of sharing and taking turns has been lost on the software engineer here....
a few years ago our company used Screenhero which allowed editing with multiple cursors while screensharing.
The experience was actually quite nice for two-three people but we always had the "ok let me type now" flow. Multiple changes happening at once sounds hyper distracting.
my understanding is that this is the dynamic in modern college classrooms. everyone opens a big shared google doc for notes and they all collaboratively edit a set of notes in real-time.
or at least that's what i've heard, no idea if they actually do it.
it is nice to see a crdt backed editor tool for markdown and code though. gdocs markdown support has been lacking for years.
> or at least that's what i've heard, no idea if they actually do it.
Yeah, we used to do that back when I was in college. It's only for certain classes and most people usually kept their own notes too (or instead, why write twice). Or some classes ban laptops so you'd write on paper anyway.
True, but the option of wysiwyg for editing markdown would really be a great addition. Or even just for preview ... https://github.com/zed-industries/zed/issues/21717
The metaphorical infinite monkeys on typewriters.
Actively programming in pairs (or more) is also not for me. Reviewing work async is great IMO though.
Yeah, people are different, but a lot of this difference results from various constraints, such as cultural practices around collaboration or technological options. Many of these limitations probably shouldn't be locked in by our tools or norms.
When learning a new way of thinking or moving (i.e. martial arts) people often really benefit from high-bandwidth, low-latency, shared-viewport-onto-reality interactions. Watching someone's cursor move while they talk is one way to get a window into their problem-solving toolkit.
You just need to channel your inner Akira Nakai. There is no shame in being an artist. Code artisan.
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.
We actually had it that way 20 years ago. SubEthaEdit could work with Coda 2 and TextMate
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.
> Despite attempts to make Atom—an Electron application—more responsive, it never reached the performance standards the team yearned for.
This feels like an attempt at deflecting blame. VSCode is another Electron application that ended up having better performance than Atom. There's another Electron adjacent application that has good performance, the one you're probably using right now to read this page.
Depending on page content of course
Reading this static HTML page and executing several megabytes of JavaScript to read and edit short lines of text are fundamentally different tasks, even if the same program can perform both actions.
VSCode can pretend to be fast in my desktop, and I would not care because desktops today are computing monsters that rival supercomputers of the past, but Sublime Text is still much faster at any text editing task.
VSCode has good performance, especially for how feature complete it is, but it really has nothing on the boot speed of Zed
Boot speed is nice and all but in general I boot once and I'm done!
I’m not saying that VSCode is the snappiest editor out there but for all its flaws it’s still the most responsive editor for my use case on moderately sized CUDA/HIP projects.
> VSCode is another Electron application that ended up having better performance than Atom
Atom was kinda like emacs. Extensions could do almost anything. VS Code has a limited api that extensions can use
What are you saying here? It is true that VS Code is less bad in terms of responsiveness in comparison to Atom. Zed, however, is written in Rust (i.e., not Electron), and I would guess it is at least an order of magnitude more responsive than VS Code across every possible scenario.
Web technologies are an unrivaled technological marvel for what they are, but it is disingenuous to imply they represent anything near the peak of what we are capable of in the context of performance.
It depends. It definitely opens faster and the general UI seems a bit faster, but open a largish file (a few MB) and VSCode will easily out-perform Zed because it doesn't have that fancy CDRT thing.
In my experience VSCode is plenty fast. Use it with no extensions and you will have zero problems with performance (though memory use isn't great). The real problems come when you have extensions, especially because it's often impossible to attribute performance issues to them because they can often do a lot of work all in the same "extension host" process.
> you will have zero problems with performance (though memory use isn't great)
Memory use is a part of performance, though, so I definitely would say VS Code has serious performance issues. It's why I no longer use it, in fact. It's inexcusable for something to eat as much RAM as VS Code does.
If you use vscode on a platform with limited resources you will see that vscode is absolutely NOT fastand zed outperforms vscose long way. Extensions or not. And electron is a pleague that needs to pass from this world
Why is Zed using a CRDT when I open a source file to edit code? Are they using it for more than their multiplayer stuff? (agentic stuff?)
Based on this comment [0], they're building DeltaDB as a version control system which uses a CRDT, so I assume even in single player mode, the file will instantiate its own CRDT for fine grained tracking of changes.
[0] https://news.ycombinator.com/item?id=45916196#45919739
Unlike a lot of other commenters, I found this to be an interesting approach. Text files are good. Having an integrated environment that combines files and channels and collaboration seems like a neat idea, and I could imagine building all sorts of neat stuff on it.
However, I just tried it myself and was really shocked to see other people in my sidebar after I clicked on the “collaboration” stuff. I expected to be dropped into my own collaboration environment built around my own channels, like a fresh private Slack instance, but instead I saw the built-in Zed channels and as I clicked around, it looked/sounded like I was joining voice channels. It was as if I’d accidentally joined someone else’s Discord. It was so mentally jarring that I got afraid I was on a live mic or would accidentally be live-sharing stuff with strangers.
https://en.wikipedia.org/wiki/SubEthaEdit
https://tidbits.com/2003/06/30/apple-announces-design-awards...
People have been doing collaborative text editing since the 60s actually! See, The Mother Of All Demos[0], referenced in our first blog post[1] :D
I'd say CRDTs are also a big change. CRDTs make live collaboration much more robust for all parties involved, and they only started to reach maturity in the mid-late 2010s
[0] https://en.wikipedia.org/wiki/The_Mother_of_All_Demos
[1] https://zed.dev/blog/crdts
SubEthaEdit was a very inspiring software project for me. The fact that a small team could, in a few months, produce an amazing app that solved real problems and gained notoriety was amazing.
As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster. I'm also a fan of Zed and everything they're doing, but it's notable that shipping next-gen editor software takes a lot more developer effort now than it did in the 2000s.
> As time goes on it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.
The Graphic Editor workspace, in fact all the Adobe programs alternatives is quite open.
I remember using Paint Shop Pro, and it was bought and killed by Corel. I would prefer to keep using Paint Shop Pro, instead of Photoshop, because it was super fast and had all the features I used and wanted.
Ask people why they can't migrate to Linux, and half or more of the answers are: Adobe.
> but it's notable that shipping next-gen editor software takes a lot more developer effort now than it did in the 2000s.
Yes, the scope increase is vast, due to more languages, more tooling, more features, higher expectations, and more competition.
> it feels like much of the low hanging fruit opportunities in software is disappearing faster and faster.
Yes I agree but so many things that might seem "done" (and in someways I think software/SaaS as an ecosystem is "done" compared to where we came from).
BUT - so many companies just bloat themselves and their products. I think the end of ZIRP is going to have an effect on that (more enshitification / rent seeking for sure) and I think there will be an opportunity to iterate and make copyware that doesn't take the higher development efforts.
We really need a winning electron alternative that is more resource friendly. That, IMO, will be a big game changer and I know there are lots of promising alternatives already.
I'd forgotten all about it but SubEthaEdit was such an amazing tech when we were using to collaborate internationally back in about '04. It went off my radar but I am glad to see its still available as a free app.
I don't understand why text editors became so complicated. When I ran zed, I think my gpu wasn't properly used and it ran at 5 fps. I couldn't even get the thing to boot.. Remember when people had 1024x768 and coded perfectly fine software without instant messaging pinging every few minutes? We peaked there
What I remember from those days was saving my work reflexively because the chances of the window manager or text editor crashing at any given moment were quite high. Also, emacs came in for lots of grief for being so slow. Remember “Eight Megs and Constantly Swapping?”
This is not necessarily to endorse Zed; I’m ecstatically happy with my current text editor. However, “we peaked 25-30 years ago” is just not true. Things have gotten better and they continue to do so.
I tried the collaborative features to pair program with a colleague a few months ago, but it was bad. It was very flaky in establishing a connection. In the cases we were able to establish a connection, the voice chat would not work. We tried to make it work for a couple of days, and then we gave up. Has there been lots of work in the past few months on the collaborative features?
Is this the new Zawinski's Law? Instead of extending to read email, Zed extends to enable chat and voice-video. :)
I’ve been using “The Notioning” for the last few years to refer to the convergence of tools like slack adding notion like features, clickup adding notion and slack type features, and so on. There seems to be a stable set of features that retains teams in an org
Perhaps we can call it the "Hashimoto Valley", analogous to the Uncanny Valley, but for DX
What does this have to do with Hashimoto?
HCL / TF DX and my missassociation of Zed / Hashimoto (see where I was corrected elsewhere in these comments)
I was very surprised to find a "forum" integrated in Zed when I first opened it. But to be honest, it is not something I ever felt the need for and overall I don't like having this in my text editor. So far it never got in my way and that's a good thing, I hope it stays that way :)
yeah, I love Zed - but I turn all this stuff off (even the AI)
It would have been good to include a link to the collaboration docs https://zed.dev/docs/collaboration in the article. There were a lot of links in that article and a lot of assumptions that I knew how things worked. And I daily drive and like Zed, but I had so many questions.
I don't work at zed anymore but I do find it funny that anyone would think that the collaboration features of zed are "tacked on"...
We started building zed in zed using it's collaboration in early 2021. Collaboration has always been part of it's DNA. Nearly everything at zed is written in pairs over collab.
Agreed.
I joined a Zed hackathon at RustConf 2024 where I built the "Open in split" functionality from the file fuzzy picker. A member of the engineering team who was floating around helping folks had us exclusively work through the included collaboration features. It was a great tour of the editor, and did not feel tacked on.
Tacked on was my first impression as well. But I am glad that they just shipped a feature and are measuring adoption in the wild. So refreshing.
I understand interacting with other engineers right in the editor but I dont get why so many collab tools need to be bolted on to what is basically a text editor. This will only fragment communications since its not just engineers that work in any company. Meaning you'll now have communication spread out in Slack and Zed making collaboration difficult, not easy.
I dont honestly dont get the allure of pair programming. My pair programs are the unit tests which I run as often as I can and limit discussions to Gitlab/Slack. I have worked ag FAANGs and large companies and never once pair programmed anything.
I honestly cannot think of a single software or process problem that requires real time collab in the editor. Having said that it is a cool feature and I quite like Zed as an editor.
I listened to the founders explain that the current process of syncing up to review or question code is very multi-step and sort of inefficient almost adversarial at a high level. A slack mention, Github discussion, screen share, etc it all ends up being kind of disorganized and painful versus just being able to edit the document collaboratively and directly, perhaps leaving some metadata tagged at certain locations (e.g, notes from a conversation about the code).
It's not like the editor prevents one from still using slack and other external tools, either. I guess I just see the value in in-editor integration to handle that stuff more smoothly, at least for those using the same editor.. I can see myself really appreciating the feature if there's a part of the codebase that consistently trips people up or is under active discussion.
My understanding was always that this is a way to monetize a text editor. How else do you monetize dev tools? Developers are used to very high quality free tools. You’re either one of the few old guards (like JetBrains, Microsoft or maybe Oracle) that can sell IDEs and other dev tools because 25 years ago open source dev tools were far from beginner friendly.
But how do you monetize a programming language, a text editor, a build system, a terminal emulator, etc in 2025? The examples are deno, bun, mojo, nextjs, zed, earthly, warp, etc. all know they can’t monetize the actual tool. You monetize services that you build around the tool. Like a cloud/workers/deployment (basically compute), or a sharing service or an AI service, etc. once you have critical mass on your platform, you can find other easy services to offer. Like if Zed has a critical mass of users, maybe the offer “in editor chat”. A small startup with just 3 devs working together can replace slack with zed. Maybe they offer an uptime check service. Why not? Maybe a file sharing service. Maybe a small wiki service, etc. all things that have million other solutions. But if you have critical mass, someone will pay for those things.
> I dont get why so many collab tools need to be bolted on to what is basically a text editor
It's because the collab tool wants to have access to the code as it changes live. It could and should be done in an editor-agnostic daemon like LSP, but then you wouldn't have editor lock in. And that's why both Zed's collab and VSCode's LiveShare are builtin.
Anyway Zed has a very interesting idea to provide links to codebase places that remain stable even after the codebase changes. This is pretty cool, because so many discussions about code quickly become outdated
> why so many collab tools need to be bolted on to what is basically a text editor. This will only fragment communications since its not just engineers that work in any company
Once they finish their collab platform they can make it standalone. The current version in Zed seems to be isolated very good.
A cynical take is that pair programming in the IDE implies network effects and custom protocols. Just the types of moats necessary to get VC backing.
As long as I don't have to use, feel free to include it. It is really not essential feature for editor.
I run update and Collab requires you to sign in... which again, it is fine if you want it. I don't, so it can be dormant, icon is really tiny, doesn't take much space.
The feature of Zed that is most annoying yet essential is frequent updates. Pretty much daily when I switch to Zed window, I can expect update and restart, which messes up my window layout, so this is annoyance. Getting updates and knowing you guys are shipping good stuff is what is essential.
I think integrating terminal ai's is great move and useful. Sometimes I use it like that, often I use it in terminal (like the outside of the editor terminal) and switch to editor to review or update stuff. Same with git. I am old-fashioned.
Looks a lot like Google Wave. This is interesting for some things but I don't think coding is it, for the same reason that IntelliJ's CodeWithMe doesn't work for pair programming. And apparently one of the guys is a former Pivot, so it's a little surprising.
Pair programming is Two People One Cursor. A critical aspect of it is you're both looking at the same lines of code and working on the same problem and following each other's thought processes.
CodeWithMe (and it seems Zed) is Same Codebase, Same Day. There's no shared focus. You edit stuff, I edit stuff, maybe there's overlap. But this isn't much different from doing separate git commits.
So far the only remote pairing tool I've found that works competently is pop.com.
Pair programming so often degrades into one pilot and one person just sitting there trying to catch mistakes. When those mistakes are caught they are mentioned taking the first persons attention away and breaking flow.
In contrast how I like to work, with similar level people, is to work at the same feature in the same codebase at the same time. We either sit next to eachother, or have a remote call, where we continuously talk through what we want to achieve. Sometimes this results in one person writing ahead (code, docs, doesn’t matter) and the second sweeping behind it and cleaning it up. Two cursors, one source. IntelliJ even manages to keep authors correctly in git.
The other mechanism is where we work on different parts of the code base at the same time. Either main code and tests, or split across interfaces and implementations. Because this happens on the same machine the iterations are way faster as they are local and incremental.
This basically saves the whole dance of creating branches, pulling/pushing, the fixing typos etc.
With zed you can also share your screen in the editor which makes it a bit better, but still you can't take control of the other machine.
IMO if you only care about coding doing it in the editor is the best approach, you get zero latency and have all the context that you need (most of the times). But if you want to do more, like opening the browser for whatever reason, or teaching how to use a specific cli, etc, then taking control works better.
If you liked pop you might like gethopp.app, which is an OSS pair programming app (full disclosure I am the co-maintainer). Unfortunately because we have chosen tauri for the frontend we can only support macos and windows, but I am working on a solution for Linux too.
> There's no shared focus.
I never used Zed collab, but isn't there an option to follow someone's cursor rather than having your own separate cursor? Zed even has an option to follow the cursor of an AI agent ffs.
I know that VSCode's Live Share allows you to follow the cursor of someone else. However Live Share is very buggy and will disconnect at times, so it's more like a cool demo than a product.
/offtopic
Is it just my vision, or are websites getting super low contrast these days, esp the text-heavy ones?
I feel like that's been a trend for the past decade at this point. I don't think this one is particularly egregious but it ain't great either.
Could be your monitor as well.
I'd say it's medium gray on white, which is not too bad in my subjective opinion. I have seen far worse. Light gray on white was "trendy" for a while and dark gray or dark green on black has always been popular among the edgy crowd.
Also the typeface, kerning and line heights are a bit - unconventional, which doesn't help the readability
I ... don't like this one bit. I hope Slack doesn't start including a text editor.
There are canvases.... Some similarities if you squint. Clearly not for code use but for shared durable notes....
I love Zed’s minimal design language ... clean, restrained colors, low visual noise.
The screenshot below surprised me:
https://zed.dev/img/post/zed-is-our-office/this-week.webp
All the colorful avatars and the busy side/top panels feel out of character with the usual Zed aesthetics.
I hadn't realized Zed was built from the ground up to support collaborative programming. I liked it already, and I like it even more now.
Looks very cool, and of course it's nice to basically have Slack inside of Zed.
But personally, what I want in a Code Editor / IDE, is to be the very best experience at writing code and working with code projects. That is what will save me time and make the coding experience better.
Collaborative features are nice but not essential since there are other tools out there. It's not likely to move a team away from Slack (though if it's self-hosted, it stands a chance).
I'm not yet at the point where I can rely solely on Zed for python coding. I mostly use Zed because I like new initiatives, especially open source ones, and it's fast and responsive. But PyCharm is still better for python development at this point, with its one black mark being endless indexing on large codebases / dependencies, and I find myself falling back to it regularly. I would argue that the priority should be to achieve parity as a _code editor / IDE_, and then we can talk about other shiny new features.
I use Zed instead of my normal text editor because it opens instantaneously. But I don't write code in it, and still use my IntelliJ + IdeaVim with Claude Code and Codex in a separate terminal in Ghostty.
But Zed is an insanely fast text editor to open text files in. Just double click and it's on the screen. Love that. Maybe over time I'll do more in it.
If that is all you need there has always been Vim and Nano.
I do use (and am in the Backers.md of) neovim. But the GUI versions open much more slowly than Zed. Zed is near instantaneous. I do often edit text in neovim by opening a terminal window and doing things, but the experience of browsing a large log file and filtering through it is much nicer in a GUI text editor, so if I ever double-click or open a JSON file I want that to happen instantly.
I can't stand Nano. I find it impossible to use because my brain is strongly vim-bound.
I kind of love this, although I feel like I'd need to try it out to understand exactly how it feels. I'd even like to see a video if Zed could make one. It would be good to understand e.g. if the issue of "who wrote that?" actually affects things in practice, or any other weirdness or limitations.
I also kind of get why it's built into an editor! I wonder how it compares to e.g. https://www.coscreen.co.
The default method of remote work, with e.g. Slack and video meetings, I think leaves a lot of potential on the table. I wonder if a flexible collaboration system like this could actually be a lovely default method for many companies.
Please work on decreasing the binary size - it's whopping 400mb!
What I see in posts like this is that it becomes clear to me that I am not their target demographic.
I work with IDEs and low-code/no-code tools, VSCode is kind of unavoidable in some scenarios as it has become the only programmers editor that some companies bother to provide tooling support for their SDKs, and that is it.
For bettr or worse, everyone and their dog that used Eclipse forks for their SDKs, now is doing VSCode forks.
For historical UNIX purposes vi and Emacs, and then any editor will do when changing some bunch of configuration files, in case nothing else is installed.
In no project I would be able to make Zed our office, that is what stuff like Monday, Jira, Confluene, Trello, Workfront, happens to be.
Zed looks really cool and I would love to give it a try, but I am just too beholden to devcontainers. I know there are workarounds to use them with Zed but with many extra steps compared to VS Code and it's forks. I can't go back to not having a totally integrated container per repo.
Really user here: Switched from vscode to zed for ~2 weeks entirely in a windows PC, getting back to vscode today, just not feeling good enough: 1. zed updates frequently, but I'm not feeling any update at all. I mean, no new features, not fixing stuff that I'm experiencing that's not good enough; 2. while it put heavy in AI stuff, the ACP thing and the integration of codex and claude code just not working as expected as is. Especially I'm getting really poor outcomes from the same tool in zed compared to the cli itself, which is really frustrating; 3. the terminal in windows zed is barely usable, it's slow and slugish, sometimes the texts or some symbols are not rendering properly, it's just not stable at all. I really like to use the terminal inside the ide especially when I need to start up dev server, but with zed I'm used to open an extra terminal app when I need to start up dev server; 4. I'm a frontend dev, which means the tech stack should have great support in morden editors, but the case is not quite right in zed. I got jetbrain style inline type hints for typescript files with deferred types, but it is so annoying cause it makes a line too long I may even need to scroll horizontaolly more than may screen width to see the content at the end of the line, but the line has only 40 chars. At the same time, I'm not sure how to shutdown this feature after openning the settings. And when I want to set wrap width to 80 chars, I don't know how to do this either. The settings maybe there and are easy to tweak but it is not doing great to make the user understand it and use it; 5. it constantly showing some language servers are down and I don't know why, I do not like to tweak with settings so it could not be my bad, I don't event know how to touch the language servers;
I have more to input here but I forgot some of them, overall, I just want to get back to vscode which is much easier and battle tested. I think zed have a totally different perspectives on feature sets and stuff, that's good, so people could have another choice. Hope zed could do great and I will definitely come back one day.
PS: I don't think collab worth too much effort in an IDE, you have much better tooling out there and have better intergrations.
Here is where I've settled on for Zed. I initially thought it might be a Sublime replacement for one-off files, but it seems it's geared towards projects. It's not as powerful as Jetbrains (RustRover, PyCharm etc), but is much faster. So here's how I'm using Zed:
I think its' a much nicer experience than VsCode, which I admittedly haven't figured out to run in a project-oriented way.I'm also trying their GPUI library, but am in the early stages, so can't really comment on how it compares to EGUI.
Zed is the only modern IDE-like editor which is fast enough to replace (n)vim for me. I plan to use it for more and more projects, but I've had minor issues with it's Vi-mode.
I'll always remain someone plugged into vim because I need it sometimes when shelled over a terminal. Editing files over SSH can work with editor support, but is often less reliable or fast than jumping through whatever hoops I need to to get an SSH connection once and then doing everything from there.
Incidentally, I use Vim for editing files via SSH as you do, or if I'm in WSL, but haven't figured out how to use it for projects!
I just have a few plugins which help. Mainly the LSP for gotodef and popovers for type info, etc. This was what finally made me transition to neovim. Also a tree viewer, Startify, and :Rg for ripgrep integration. Those are my big ones.
Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
> Sadly my workflow of using `!` to get back to my terminal and things like `!make` or `!cargo build` is fucked in neovim. So I do a lot of ctrl-z and the a lot of killing stopped processes I forgot I suspended. I've complained about this in various threads and chats, but the developers aren't interested in letting us use the old vim `!` which is super lame.
I'm sorry... what?? I still use vim as I haven't found a reason to jump to neovim, but you're telling me external commands don't work properly? That's wild.
They "work"... but instead of switching back from the alt screen and giving you your terminal back, they open a gimped little window within vim which makes it hard to navigate, copy, and search for things in the output.
Why would you use a tablet for this type of work? Honest question.
Surface tablet, so it's like a laptop. I can kick the keyboard off when I'm reading stuff, to allow room for food and drinks. And I do drawing/notes with the pen.
Another way of stating this: It's a general purpose portable computer; not specialized coding PC.
i'm now guessing the software engineering universe is becoming like the lawyer ones
1. big corporate shops / vc funded ones - many tens of programmers working on features (this is where zed collab features might be needed) 2. bespoke high productive small teams - less than 5 product programmers in a company e.g basecamp - these would be your bespoke law firms 3. the indies (injury lawyers) -> 1 - 3 programmers chunning out products at scale or eating of one product + maybe with help of A.I
for 2 & 3 - a lot of stuff being shilled is not needed. a legal pad + some notes that can be posted via a google doc is all that's needed. Jira isn't needed too
There is a lot of complaints about Zed in the comments here. I don't think that they are "hate", per se; they all definitely care about Zed and want it to succeed.
I daily drive Zed for work across several languages and I love it. I use a lot of its features, like the git interface, agentic editing, etc. I might even consider paying for Pro in the future if I want unlimited edit predictions.
However, all of these complaints are fully justified. I think Zed is a massive undertaking, only one that a VC-backed company has the capital to do. iirc, it requires 70k lines of Rust just for the cloud part [1]. I cannot fathom the amount of fundamental infrastructure they have to get the editor functional at all. That doesn't excuse all of the papercuts in Zed though.
If I were Zed I would do the following:
1. stop all work on future features, like DeltaDB etc. They all seem extremely cool but they won't meaningfully contribute to increasing Zed adoption or fixing its issues.
2. remove all agentic editing features. if Zed tries to simultaneously become the world's best agentic editor and a good general-purpose text editor, it will fail at both. Keep around ACP so users can still use other agents, but remove all of Zed's built in agent stuff.
3. fix literally every papercut. Triage every single issue and go through every PR, even if it will take half a year to do so. People won't switch to Zed until it's perfect, and the existence of this many issues means it's not perfect enough.
4. make extensions actually good. Every programming language, library, etc. has it's own ecosystem, and many such ecosystems mainly rely on VSCode extensions for advanced features. Zed needs to be extremely extensible like VSCode is; obviously its architecture makes this slightly harder, as it's nontrivial, for example, for extensions to render their own GUI, but there are a lot of low(er)-hanging fruit for extensions that need to get solved. People will only switch to Zed if they can get a similar breadth of ecosystems.
Of course, this won't happen, and given that none of these will really make them money, Zed has no incentive to focus on these, especially given the amount of time they would need to do this. But I think that if Zed can't nail the core experience, it won't get anywhere.
[1] https://maxdeviant.com/posts/2025/head-in-the-zed-cloud/
Haha it's like Google Wave!
Technically really impressive. In practice, completely unpractical in any medium to large organization. And although I adore Zed's speed and reliability, I still don't understand why we need these features at all.
Because Zed is not somebody's side project, it's a business looking for ways to pay everybody's salary
> Collaboration as it stands today is considered alpha, and for the time being, is free for all to use! Peruse the source code.
Based purely on this blog post it looks like they are trying to compete against notion but with an IDE extension
Because "maximum editor" was achieved with Visual Studio Code (which is why all these new editors look and feel like VSC), the same way "maximum toothbrush" was achieved with the electric toothbrush. But the toothbrush industry had to keep going, so now we have a $400 bluetooth connected toothbrush-as-a-service that monitors your brushing habits to optimize teeth cleanliness, with brush heads that cost more than 5 regular toothbrushes.
Zed and the current crop of AI editors (including VSC itself) are that toothbrush.
Their collab feature looks promising. But I can't move to Zed yet, because it's laggy on both my Linux laptop and workstation. They need to fix these issues first.
To me it feels like 2 different set of products, what they are showcasing here seems very similar to slack/teams.
Of course, it would be awesome to have a faster and open source slack, and if I can take notes on the same style as my editor great. So I guess, it would be nice to be able to embed zed in another product.
I think this would be appealing for a company that it's core product is code, like zed, but I do wonder if other companies even need this functionality.
You guys need to figure out how to create Slack shared channels in Zed and we're all switching until they won't be needed anymore.
Can you share more on this.
While I do not work at Zed, I'm curious to hear more about this use case for my own company needs.
Your company has a user pool, you sign a BAA or start working with a partner company that has their user pool. Instead of creating slack accounts in both you can share external slack rooms that only people that are invited in/from their respective orgs can join without having to co-mingle employee user pools.
But why would external partners want to look at your code? I guess if you're also integrating with them? But generally you just give them repo access instead. For Slack, it's different as messaging is a core feature to collaborate between different people in different companies, but looking at code is a very specific use case.
Not sure, I was only answering in regards as to what Slack shared rooms brings to the table for companies in the form of letting Project Managers/Account Managers have direct line of contact with clients.
Code wise I guess you can could be working with any agency or contractors and you could collab on PR reviews? No idea to be honest.
Very cool idea, and helps promote owning your own data, and it being highly interoperable (plain text!)
I do wonder if we need a term for shoe-horned dogfooding though. Like sure, you can do this. You could do this in Figma! Or in Notion! Or in LEETCODE if you wanted to.
At least with Zed though, its plain text. If you find another way to collab realtime on plain text, you're not bound to 1 vendor.
people live-dumping their comments into a text doc while i'm presenting with no ability to know _who_ left a comment (unless they manually prefix their name) really showcases that its the wrong tool.. https://i.imgur.com/vEttouw.png
This is insanely cool but it would be hard for non dev people to join the meetings and there is always an annoying "camera on" policy.
Moreover, this would be competing with Google Meet, Teams, Slack, Gather - way too much tech for collaboration
And I wish we were more async-first and less forced to deal with humans, especially over the network.
While certainly an amicable goal, I doubt that many companies/groups would be willing to put their comms inside zed, where it feels locked outside any other ecosystem.
Any plans to leverage 3D at all in the interface?
was floored by the "explode all layers in the user interface and simulate a 3D camera rotating around them" graphic when i first saw it !
3D is always difficult to get right, but felt it had some really cute possibilities,
any way to open this up so devs can try things out?? < 3
> was floored by the "explode all layers in the user interface and simulate a 3D camera rotating around them" graphic when i first saw it !
What is this in reference to?
https://zed.dev/blog/videogame !
thanks!
From reading some of the comments, I'm not sure which is worse, Zed Shaw or Zed the code editor
Because I'm apparently a billion years old, I still use Sublime Text and just text editor. If I do switch, it will be to this. However, is it as responsive? Do file changes just appear if I change them elsewhere in like terminal?
I’m always _this_ close to adopting Zed, but I just can’t get used to the project search. I’m too used to telescope now. Maybe I need to bite the bullet because I think Zed’s search is objectively better. Old dog, I suppose…
Whenever a product tries to be too many things, it dilutes the core USP. Try to be an excellent code editor. Add extensibility. Done.
I get it, you are VC funded, investors want to turn this into a multi billion dollar unicorn.
Do not focus on investors, but developers.
As mentioned in the post, Zed's collaboration functionality is its core USP. The entire editor was literally built around it. IIUC their moonshot is to replace the GitHub PR model with something more collaborative and granular.
I love Zed as an idea. They built some impressive tech. They're clearly a smart and capable bunch. I tried zed out for a bit, then I switched back to vscode.
I'm just too hooked on that OpenVSX ecosystem.
Zed sounds desperate, nobody in the world would use Zed as office. Zed is a niche. Nobody wants it's multiplayer features since coding id usually asynchronous until crunch happens and nobody wants crunch All the time. All office have their own communication tools , you can't expect all developers just to use zed l, it is missing features and the whole ecosystem which would take one more decade and non development people won't even touch it. Then the office cannot happen inside Zed for the rest of the world, except Zed team.
I have been trying to figure out how this works in concert with Git (or SCM in general). Is one of the developers in the session merely responsible for it?
I mean, you have the same "problem" when peer coding in person. Whoever is officially working on the fix will commit it. I've helped devs get around a hump for ages, you don't get "credit" for all the work you do. It's why I hate most ticketing systems (when management starts to ask why your tasks fell behind), they don't let you correctly track multiple people when they work together.
Does a `Co-authored-by:` trailer in the commit message not resolve this issue?
commence feature creep
The collab editing stuff was Zed's original gimmick. The AI stuff is the real feature creep.
Without AI, the company would be dead in the water. You can very easily disable all AI features.
I think Tuple is a better collab app, but far more expensive.
The collaboration tools built into Zed have basically existed since the product launched. It is one of the primary drivers behind the product - they wanted to build the best editor for remote code collaboration.
I think the most difficult question are going to be how do you constraint that core feature without ever wanting to add more to it?
For instance, collaboration is a huge topic. You can have coding collaboration on the file, and that would be basic and appropriate, you can then replicate slack and you'll have chat rooms, which is entering creep territory, but it's natural! Then soon the chat room will need to link with issues and you can now have TODOs linked to some kanban board and we should be able to speak while we code on the same file! And this goes on and on.
It's exceedingly rare that the organization found hard courage to specifically avoid features that looks like easy pickings for the purpose of avoiding them.
Many of these features were in Zed since first release.
Also Zed was announced as a closed source comercial tool.
Zed's dead, baby, Zed's dead
oh good Slack embedded inside my editor. Just exactly what I have always wanted.
When it comes to writing tool the trend has been strong that people want distraction free writing with no interruptions.
Seems like code editors are going the other way on speed.
Don't tell the Posthog guys about this. Far too much collaboration going on here!!!
This is interesting to read and very important to me since I am building a coding agent with team collaboration in mind. I used to use Zed daily till the point that I moved away from writing code directly and instead generate all my projects only from prompts.
I think collaboration for people who eventually use the software will be more critical in the era of agentic coding. Project Management will change. We are not waiting for 2 weeks to build prototypes, it gets done in a hour. What does that mean for end users - do they prompt their changes and get access to new software? Who would double-check, would AI reviews be good enough, would AI agents collaborate along with humans in the loop?
There are so many questions not answered. If anyone is keen on having these talks, I would happy to share what I think. Here is what I am building: https://github.com/brainless/nocodo
I want to see a future where end users can prompt their needs, have collaborators in the company to help clear things up and in an hour the feature/issue is tackled and deployed.
What's up with the letter spacing on that blog? It looks bad.
I lost all faith and interest in Zed after they introduced AI features.
I feel the opposite way, but fwiw you can turn off all AI features in Zed by adding `"disable_ai": true` to your settings.json.
Yes, that is correct, but this indicates change of the product direction that make me lost any trust or interest in it. Their core features were done nicely, they should have stayed and developed them, maybe introduce more file editing related functionality.
That's alright, there's always Sublime Text.
Or TextMate -- that Sublime was, let's say, "inspired by."
My main editor for the last 15 years is Emacs.
The AI features work well but to each their own
Why? Its still incredibly plug and play, by default you don't even see it
you dropped this king
Does anybody actually want this?
This looks more like a collab note-taking app. Don't know about code since i don't code anymore inside an editor but for collab things who knows
Welcome back, Google Wave.
It's nice to see Zed's collaboration features discussed in their blog. The collaboration features are really what makes Zed such an interesting project and product. I was worried they'd gone full AI hype train. There's so much opportunity to improve digital collaboration tools.
Random thing spotted in the article:
> "Wish there was a windows laptop I could buy that is good"
What does it even mean? There are macs, there are chromebooks and there are just laptops. Wth is a Windows laptop? There's a good Linux laptop?
Just a nit :P
I'm now more convinced that I made the right choice to invest in Neovim.
Just another fence for monkeys :)
I love Zed. I, mostly, love the direction they are taking the editor in.
But. There are now two times I see Zed going in the wrong direction. The AI integration was one. This feels like the wrong direction again.
I never really liked the AI integration. It felt off to me. I do love coding with Claude and I think I know why. It presents the "information I need to know" in a way my puny brain can handle it. Colored diffs. Summaries of what happened. It isn't perfect, but it has been incredibly productive for me. I never got that from Zed's AI integration; perhaps this has been improved, but I was up and running with Claude in a way that I never was with Zed.
This write-up sounds like "slack in my editor." If it is that, I hate it. Slack has destroyed company culture and communication. People, who are inherently lazy (I'm an old Perl programmer, so I can say that), have stopped thinking carefully and writing carefully, and in that void just throw the first thing in their head into a slack channel and think that is "collaboration" and "communication." It's toxic.
For example, this comment rubs me the wrong way: "Staff members hop in, volunteer to show off a cool feature or bug fix they worked on, and get real-time feedback from the rest of the team." I don't think our human brains work well with "real time feedback" UNLESS we have the information presented in a way that gives us massive clues on what's right and what's wrong. Reading a wall of text is not the way. A colorized git diff, or a video, or an entirely new way of presenting information might make real time feedback possible, but I am highly skeptical a text editor is the way or place to do that. And, I'm an emacs user and love text UIs, don't get me wrong.
Do I want to have "generalized one off rooms for things that don't fit anywhere?" I definitely don't want that. I want you AS THE AUTHOR to be really intentional about what's important and fit that into the proper channels. I need to know that information, but I don't want to know about, nor have the unspoken expectation that I SHOULD have known, about the other stuff. And, I want "managers" (if that still exists) to be carefully thinking about those channels and how the company is organized and push that structure down to people in the organization.
As Zed is the office, having one off rooms instead of in person coffee time feels very dangerous. That's the world a lot of people live in, but I don't like that office.
If this comment is the guiding light, then I'm worried: "We're building toward a future where collaboration is continuous conversation, not discrete commits—where every discussion, edit, and insight remains linked to the code as it evolves, accessible to both teammates and AI agents." I'm human, I have kids, I have other interests. A continuous conversation is impossible for me. I want discrete ideas, and right now, discrete commits and PRs are better, IMHO, than what I hear here. It's hard, but setting the expectation that to be successful I need to be paying attention to a river of information flowing by seems like a bad idea to me. I don't buy that Zed solves the problem of hiding the pieces of information that I don't need to see.
Oh hey! I have an idea. Why not use AI to summarize those conversations into discrete pieces! </joke>
I do love Zed. It is the best GUI editor out there. I know they will get it right. I just am skeptical about this direction and feel it misses the forest for the trees.
Man, Im like the total opposite in terms of preferring the Zed UI vs claude code. I really try to avoid raw claude when possible. I very rarely pull it up to do concurrent sessions when I have Zed open already working on something else. Or if I need to do something quick while in the CLI in a random directory. Otherwise, I think just the "files modified" feature is worth using Zed as the primary interface.
You make some good points, and I need to revisit Zed+AI to see where things are at. This probably proves you are a better developer than me.
But, also, after reading your comments, I'm just not sure I need an "editor" anymore. I love that I can npm install claude anywhere. Zed does not exist for ARM servers yet, but I can install claude there, and it can troubleshoot my database connections, and edit code, and grep files. Those are all the things I used an editor for, because an editor has better ergonomics than using the CLI. I'm sad to say "misspelled prompts" might have better ergonomics for me.
If I were still hardcore avoiding a GUI Id probably be in the same camp. But I moved to VSCode as my primary interface a long time ago, and Zed is just a better version of my workflow when comparing against that.
100%. I also moved to VSCode years ago. Then, I got disillusioned by the performance, and by M$ telemetry. Zed is so much better in so many ways if you have to go with a GUI for all those reasons.
I agree about the bad side of slack culture, except when compared to how things were before slack: Horrible email threads, in-person meetings, phone calls, and people walking over to your desk to ask you stupid things they could have looked up themselves.
Slack revolutionized this for me because I can turn it off anytime I want. When I want focus, I close it and it cannot reach me for some time. Then I pull it up and read all the threads while taking a poop.
Having it in zed is the same: You can just log out of collab anytime you want! You would only use it if you _want_ to use it. When you do want to use it, it's incredible. Someone can just join your channel and work on a tricky problem with you and you don't even need to screen share. It's like the best of discord and slack available at the touch of a button. It's much lighter weight than slack. Slack huddles are super annoying to me. I want it to behave more like discord, and that's what zed does!
That's a good point. Email is much worse than slack.
But I still think it is impossible to manage all the things happening in slack. And the expectation is that it was said in slack, so you should know about it! Whereas, I definitely go through and review PRs and if there is a culture and management agreement around good PRs, then I can easily understand how things work, how things have changed, etc. I never get that from slack. And, I never got it from email either, fairly.
The topic of "expectation" is really interesting and worth discussing more. I refuse to accept the expectation of slack meaning I am literally always available to message, and also that I must read and keep track of everything in there. If somebody asks me about something and I suspect it might be in slack, I might do search for it to catch up on that topic if I am inclined. But obviously so many people feel the pressure you're describing (to know about everything said in slack)--- which sounds terrible!
[dead]
[dead]
Haha: Can't find a good Windows laptop.
It's true, most of them are bad. Galaxy Book5 Pro or Microsoft Surface are OK.
Ever since Apple Silicon macs came out, it's been a real struggle. Almost 6 years later and there is still nothing on the market that:
* Has the same level of performance
* With the same or better battery life
* With the same quality of screen
* With the same quality of speakers and touchpad
* Runs as quiet or as cool
as the Apple Silicon macbooks. If you add in "needs to be able to run Linux" your choices go down from maybe 1 or 2 to 0.
They all have some sort of compromise. Either the speakers, screen, keyboard, touchpad, build quality, battery life, or thermals.
I have a Surface Laptop 7 with the Snapdragon X Elite, and it's pretty close. Checks the boxes for Screen, build quality, and touchpad. Loses out on speakers and battery life, and the fans need to run a lot more than my M4 Pro MBP does. It also loses on performance, and it doesn't run Linux. Windows on Arm also still has a lot of little quirks and bugs that start to become daily annoyances.
It's incredibly frustrating. I want, essentially, my 14" M4 MacBook Pro, but in a Linux laptop, and there's no OEM out there that's fulfilling that need without compromises.
Apple keeps pulling ahead in silicon and every other laptop OEM is just being left in the dust, shrugging their shoulders, and putting out the same old 1200p 16:9 plastic garbage they have always been putting out.
I could imagine that in ten years git will feel strangely slow and ceremonial. Why not just continuously work and continuously deploy live-edited software
I feel the opposite way, that git branching and merging will become a bigger part of the job as more code is written by agents in parallel and then accepted by other agents or humans.
for now yes absolutely. but I’m already hearing rumblings that some people are having luck letting multiple agents edit the same directory simultaneously instead of putting changes through PR merge hell. It just needs coordinations tools, see https://github.com/Dicklesworthstone/mcp_agent_mail as one (possibly insane) prototype
for example it’s not out of the question that we could end up with tooling that does truly continuous testing and integration, automatically finding known-good deployments among a continuously edited multiplayer codebase
we’d have to spend a lot more energy on specifications and acceptance testing, rather than review, but I think that’s inevitable - code review can’t keep up with how fast code gets written now
Having tried a janky version of this myself with a NOTES directory, I am very bearish on this being a better workflow than just improving the ui wrapper around git worktrees and the isolation that provides.
Codex already has a fantastic review mode, and gemini / claude are building tools around pr review that work no matter how that pr was produced, so I think this interface is going to get baked in to how agents work in the near term.
That’s a very optimistic outlook for the future.
Often projects need a history of stable checkpoints, and source control is one way to provide that.
Yes, but does it need all the ceremony surrounding it? If, every time I saved the file, the changes were analyzed and committed to git, and a useful commit message included, and commits squashed automatically and pushed and tested and tagged (using magic, let's say); if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?
> if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?
They would look like noise.
You would be the source of that noise.
One commit per edit? Nonsense.
Me and any other developer would hate to share a repository with you.
ye gods, have you never heard the word squash?
Why should I do your work instead of mine?
Even your comment is also noise =)
Who's asking you to do my work instead of yours in this hypothetical magic future system that I've invented in my head?
automated commit message will tell you the "what" not the "why".
In any circle of "what makes a good commit message and why even do it" discussions, invariably the recommendation is to explain the "why" and leave out the self-evident "what".
If your stance is that commit and commit messages can be automated away then we might as well not even have them.
I don't share this view, but yeah in this world we don't need AI to do things that shouldn't be done in the first place.
> we might as well not even have them.
You can't see any value in being able to see the "what" in a short bit of English at a glance vs having to analyze a 300+ line diff to figure out what it's doing?
increasingly, the automated systems have access to the original ticket or bug report, and maybe even the conversation while implementation is happening. They can record the “why”
Use jujutsu
Counter argument to living software is that it treats "never done" products as a virtue instead of a failure of design.
Here's a thread where the person replying to me makes this case: https://news.ycombinator.com/item?id=45455963
I love it when I have a tool that’s “done” but the software I work on in my career is never, ever done. It’s almost like there’s two different things we call “software”. there are tools like, idk, “curl” where you can use and old version and be happy. and there are interactive organizations in the world, like, eg, Hacker News, which mutates as the community’s needs change
Software for evolving business-needs is the same for me. What's insightful is that we (I) take continuously evolving software as just that: evolving. It's a defacto virtue to continuously tinker.
Doing away with check-ins entirely is the extreme end-game of that pov. I'm in product and every day and every week yes we very much continually change the product!
But I'm growing less convinced that the natural end-state of this methodology produces obviously better results.
Ohh no, you should be able to decide which changes to commit, line by line, before committing them.
What you describe sounds like a security nightmare to me.
Maybe you are using a remote dev server, and every change you do needs to be committed before you see the result?
Please setup a local environment instead. Not even F5 should be required, you save a file, you see the result in the browser.
When your work is finished, and only then, you should commit your changes.
it doesn't work quite well for complex projects that require integration with other teams/software.
You would need to either have separate versions running at the same time or never do breaking changes or devise some other approach that makes it possible.
It's not always feasible to do it this way
I think that’s a tooling problem. Maybe we do end up running a lot more versions of things in the future. If we believe that code has gotten cheaper, it should be easier to do so.
I wonder how many nines of uptime your team is required to have..
Imagine if someone clicks the deploy button when you're in the middle of typing something and then the service goes down due to a syntax error. To prevent this, we will need some sort of way to set a global lock to indicate that "I'm not done typing yet" and you can only deploy once everyone has released this lock.
Or you don't deploy unless it makes it through at least testing, and a build started while someone was editing the code would probably fail fast unless you coincidentally hit the button right when it's valid, but wrong, code.
It's truly showing that the zed team is chauvinistic by dismissing different encodings not being supported and focusing on other things. "It wurks in merica", it gut i guess
If software developers use anything other than utf-8 it's on them
Don't want to sound negative, yet when I read "it's in our DNA", I immediately lose interest.