Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: