[dead]
Parallel agents in Zed
161–170 of 178 posts
Re: Parallel agents in Zed
#162Funny how Zed's tagline is Love your editor again Zed is a minimal code editor crafted for speed and collaboration with humans and AI. At home, I don't use any AI when coding, to keep my brain sharp. But it's clear that Zed's focus is on AI integration because that's where the money's going (seriously, where is the setting to have a different ui icon size vs ui font size). Is there any editor still being being develo…
ecode [0] is ridiculously fast -- makes Zed feel like molasses -- and quite customizable. It's still early in development and mostly just made by one guy (who is also developing the GUI framework used), so progress is slow and there are some rough edges, but it has all the important stuff and quite a few niceties too. Really cool project, reminds me of Sublime. [0] https://github.com/SpartanJ/ecode/
thanks for sharing. I'm looking for the next Sublime and this might be it.
Re: Parallel agents in Zed
#163Re: Parallel agents in Zed
#164Love Zed for my personal projects at home with Openrouter. But I cant use it at work as I'm forced to use claude code at work and find the VSCode+claude code combo better. I know zed has claudecode integration, but I found it to be very weak compared to zedagent+claudemodel. Has this improved?
Do you mind sharing what your spend is like on Openrouter? I pay for the $200 Claude Code plan just so I never have to think about usage or feel like I'm paying per prompt. But I nearly max out my usage each week and I have no idea what that would cost me on Openrouter. I hear a lot of people are using MiniMax of Openrouter. Is that what you do?
From my observation, people who use the api either end up learning to be much more token efficient, or use a cheaper model.
I have been using the API for the last 2 years, OpenRouter for personal projects and Claude API for work, most of it in zed, always on high thinking. For work I usually spend $25 if I use opus/sonnet all day, and for personal stuff I usually spend $2-$5 if I use sonnet for a full evening.
But, I don’t think someone who’s used to not thinking about token cost and efficient use would get anywhere close to that low spending if they switched from a plan to the API.
Re: Parallel agents in Zed
#165I'm buying into this workflow more the more I use it, but the real gamechanger is (a) parallel threads in worktrees, with (b) enough lifecycle hooks to treat them similarly to spinning up a VM. Specifically for me that means that after I create a worktree I get some local config files copied over and Postgres duplicating my local dev and test databases so I can test in isolation, and then when I close out a worktree…
Unless I misunderstand something but why not just roll a couple of helper shell scripts that create a new git worktree for you, copy over a local .env file (or any other config file) and populate it with ports/variables that are unique across all worktrees (to avoid collisions if you're on localhost, but you could also do this with Docker) and a helper script for tearing down a worktree after you've merged the changes back into main. I'm even supplying unique chrome debug ports and unique temp user data dirs for isolated automated testing in chrome via chrome devtools mcp. Like, I'm not sure why an external library/tool is needed for this.
Re: Parallel agents in Zed
#166I'm buying into this workflow more the more I use it, but the real gamechanger is (a) parallel threads in worktrees, with (b) enough lifecycle hooks to treat them similarly to spinning up a VM. Specifically for me that means that after I create a worktree I get some local config files copied over and Postgres duplicating my local dev and test databases so I can test in isolation, and then when I close out a worktree…
tried parallel agents for a sprint and bounced off it. the worktree dance is fine, real blocker for us was test data isolation. scoped postgres schemas per branch worked, but reasoning about which agent broke teh shared migration when three of them touch it got old fast. we just run one agent at a time now and go for a walk.
[flagged]
Re: Parallel agents in Zed
#167I'm buying into this workflow more the more I use it, but the real gamechanger is (a) parallel threads in worktrees, with (b) enough lifecycle hooks to treat them similarly to spinning up a VM. Specifically for me that means that after I create a worktree I get some local config files copied over and Postgres duplicating my local dev and test databases so I can test in isolation, and then when I close out a worktree…
Unless I misunderstand something but why not just roll a couple of helper shell scripts that create a new git worktree for you, copy over a local .env file (or any other config file) and populate it with ports/variables that are unique across all worktrees (to avoid collisions if you're on localhost, but you could also do this with Docker) and a helper script for tearing down a worktree after you've merged the change…
Oh, yeah 100% I'm putting up scripts for them, the conductor hook is "run the one script" for setup/teardown.
The difference is removing friction, having a UI that shows me what's set up, that I don't need to hit the filesystem or git status to check in, that gives me _direct_ access to a shell/etc in that worktree path.
Re: Parallel agents in Zed
#168Earlier quoted context omitted.
Yeah, first thing I did was change all the locations back. I really dislike the automatic layout change they pushed. Also, watching the change notes, most effort seems to be focused on agents this days, which is a bit worrying. I love Zed because it's great editor that also knows a bit about agents; I don't want it to continue pivoting towards pushing agent management deeper and deeper into the experience.
I don't have any problem with them investing heavily in this, I just think they need to be smart about the UX and not let the business VC drive the experience this much. Pivoting from text editor to agent manager is a bad choice IMO, when it can easily be both and help people onboard from editor to agentic workflows.
I just wish they made multi monitor work, something visual studio had 25 years ago.
Re: Parallel agents in Zed
#169I really want to like Zed, but for some reason the way it interfaces with the TypeScript language server is dog slow compared to VS Code and its derivatives.
Check the lsp servers that run when you are editing TS file. I noticed something like 5-6 when editing a TSX file. There was even tailwind thrown in for a good measure (the project has no tailwind). All that buttery smooth 120fps wasted on poor resource management when it comes to LSPs.
I noticed the same, I had to basically force disable the tailwind LSP in my config to stop it from running since I don’t use tailwind.
Also I’ve noticed the rust LSP causes the Zed text editor to lag badly when there’s a lot of warnings.
For an editor that claims to be focused on performance, I am disappointed that LSP issues can lag the editor.
Re: Parallel agents in Zed
#170I personally explicitly avoid parallel agents, since it creates too much cognitive debt, and sometimes an agent may need steering towards an architectally sane solution mid-work.
Agreed. With simple stuff it works. But then again with simple stuff it’s pretty fast to do it sequentially.
With complex stuff I often have open the “thinking” output so I can stop/interrupt with guidance. Without that it’s often garbage output that I then have to work to fix, which is difficult to do while you’re also doing the same with a parallel process.