Live data from Hacker News

Parallel agents in Zed

zed.dev

91–100 of 178 posts

Re: Parallel agents in Zed

#91
post #7

I'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…

self-promotion, but check out worktrunk.dev

by far the most popular worktree manager

Re: Parallel agents in Zed

#92
post #7

I'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…

No need for any AI-specific tool, this is exactly what devcontainer is for! Just tell your agent to use devcontainer up (and docker compose down the other way).

Re: Parallel agents in Zed

#93
post #15

Funny 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…

I'm building Paneditor with that focus. My goal is to close the gap so that (competent) humans can work with code at levels of editing throughput usually reserved for users of LLMs.

Re: Parallel agents in Zed

#94
post #85
post #82

Earlier quoted context omitted.

I'm expecting we'll likely end back up on agents making PRs, and having to review them. Either that or giving up on quality etc/dealing with very messy code. I've been trying various automated testing/linting/etc strategies, and they only work so well.

That would be a nightmare. One thing is to review a PR generated by a human using AI and caring about the code; another is reviewing wild agents, especially when they make changes everywhere

I'm not excited about it, but the only main way I've been able to discover LLM-isms that sneak in are

1. via seeing them glimpse by in the agents' window as its making edits (e.g. manual oversight), or 2. when running into an unexpected issue down the line.

If LLMs cannot automatically generate high quality code, it seems like it may be difficult to automatically notice when they generate bad code.

Re: Parallel agents in Zed

#97
post #89

The worktree part is the easy half. Running parallel Claude Code subagents, the bottleneck is never "can they run without stomping each other's files." That's solved the moment each one has its own checkout. The hard problem is architectural consistency. Agent A renames a type to X. Agent B, in a different worktree, independently renames the same type to Y because neither saw the other's decision. When you merge, nei…

[dead]

Re: Parallel agents in Zed

#98
post #92
post #7

I'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…

No need for any AI-specific tool, this is exactly what devcontainer is for! Just tell your agent to use devcontainer up (and docker compose down the other way).

Devcontainers always disappointed me. The sales pitch is that everyone uses the same container, but that's not accurate. Everyone builds a container from the same config and it'll be similar, but it takes a ton of effort to make sure it's identical.

The idea that a devcontainer gets built on-demand instead of checked out like 'docker pull ..." has always felt weird to me. It's so close to being awesome, but ends up being barely useful.

Or maybe I'm wrong. Is there a way to checkout an immutable devcontainer?

Re: Parallel agents in Zed

#99

Earlier quoted context omitted.

I do wish they'd focus on closing the gap to Jetbrains by implementing the QOL features that are missing. I understand they have to do what VC wants to see, but this agentic stuff is so tiring.

I give them a try about twice a year. I write a lot of Rust which should be squarely in their wheelhouse. This last time I was pleasantly surprised to find they mostly fixed their SSH remote editing support. But then it started truncating rustc inline error messages and I couldn’t figure out how to view the whole thing easily. When you’re just trying to get something done little bits like this can add up quickly. Pun…

I don't like the way remote editing works with plugins. IIRC, the remote agent pulls the plugins from the connecting client. I get why it's done like that, but I'd way rather have it go the opposite direction.

I want a setup where I can have an immutable devcontainer with local copies of everything I need to develop 100% offline; dependencies, tools, etc.. Having my local editor pull plugins from a devcontainer for the project seems to make more sense to me.

I didn't dig in too much. Maybe there's a way to make it work somehow.

Re: Parallel agents in Zed

#100
I tried Zed and was really convinced that I could use it full-time, but the lack of extensions (TODO highlight, TabOut) + other QoL (line number goto as easy as VSCode + tab filter like another comment said).

I also thought it was odd that I can't configure the font size in the git commit message editor.

On recent additions, the dev container integration was great.

Rooting for you Zed!

Post reply on HN