Parallel agents in Zed
zed.dev
zed.dev
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 it deletes those databases.
The best at that that I've found is Conductor, but I can't use it at work because we only have Copilot and they're locked to a Claude/Codex backend. Arbor is close, but it's not under as active development and has a lot of rough edges. Opencode GUI has create hooks but not teardown.
If Zed can hook that up _and_ also keep its great editor roots, that'll definitely be a game changer.
FYI, you can use Copilot directly in Zed!
And then I guess setting up tasks for the cleanup part, but it'd be great to see that get automated too so I don't need to remember it.
by far the most popular worktree manager
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?
This is helpful to know - we're working on adding more agents, Copilot and OpenCode harnesses are among the most popular requests.
We also recently built an escape hatch. If you turn on Settings → Experimental → Big Terminal Mode you can create new terminals in the center panel (with ⌘⇧T) and use any agent you'd like (Copilot, OpenCode, etc). It isn't the best experience because you don't get notifications etc (yet), but at least it lets you use the harness you'd like until we build out the first-class UI for it.
Send me feedback anytime, I'm charlie@conductor.build.
But I’ve tried to reinstall it since and it just gets stuck in a weird infinite loop.
I liked conductor though. Hope you are able to fix those bugs and I can try again in a few weeks.
However with worktrees I am not really able to easily copy secrets, etc to run my app, ports conflict, I end up with a bunch of separate dbs and services, etc.
Does conductor help with this? Have you all found any useful ways of making this easier or more automated?
I don't use it much anymore, but last I did I would run into port conflicts with docker projects.
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.
The key advantages Zed has are being agent-agnostic (so not a first party UI like Claude/Codex/Cursor Desktop), supporting multiple repositories on the same agent via creating a worktree for each automatically, and having a high quality custom agent UI rather than wrapping over CLIs (I've used their IDE's agent UI in the past and it's great). AFAIK, this is the first mainstream tool that supports all of these features.
I really like Zed, I use it every day. But, if I'd seen this layout when I first installed, I never would have taken it seriously
I imagine this will push some new users away
I suspect it will gain them more users than it will lose
Most other tools doing this are heavy, buggy, and built on electron
They'll definitely lose me though if the whole plan is to turn this into Codex running on GPUI.
⌘B : toggle the left dock
⌘R : toggle the right dock
Turning Zed into Codex alienates the existing user base who installed Zed because it's a code editor. If I wanted Codex I would have installed Codex.
Of course, that's only the default layout. I'm not familiar enough with Zed, but there's probably a way to change it? In JetBrains IDEs, you can configure panels to sit at the top left/bottom left/left bottom/right bottom/bottom right/top right side and show/hide them with one click (if only one panel on the respective side is shown, it will take up the full space). So you could have files at the top left and the agent panel at the bottom left. And the code editor is of course still the "centerpiece" in the middle.
It should go: project tree | text editor | agent view | threads
Not to mention on most laptops you'll only have room for about two panes at a time. So they should be focusing on pane management and making it easy to swap between views. Not highlighting 4 pane workflows. Unless you have an ultra-wide monitor, I'd rather have a separate Agents window.
I use Zed a lot and this is a minor (can be configured) but telling design decision that really bothers me. How long until they decide editing itself isn't worth it anymore? Stop supporting VI mode?
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.
Unfortunately.
Personally, I still pay Zed because I think they’re doing great foundational work. However I’ve now almost entirely migrated to helix for editing needs.
AI and agent tooling is the only way this VC-backed company is going to make any money. Nobody is going to pay for a text editor, so they've had no choice but to enshitify it by chasing AI features for the last year+.
I don't think they'll drop it anytime, though.
That seems like a leap.
Sessions are linear though, so you cant do this _while_ an existing session is cooking.
That said, I am excited about this update too, I've been playing with ACP support and Zed's UX was bare bones. I want to run my agent with multiple workers now, and see what happens.
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!
My approach these days is to do one change at a time, until I can fully merge it with confidence.
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.
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.
lobster thread: https://lobste.rs/s/yyqowj/gram_zed_fork_without_all_ai if you want Zed without AI
It's certainly interesting though, and I'll give it some time - the post says "It feels more natural once you've spent a little time with it"
A lot of times, I find it has incredibly stupid ideas and tends to make the code very messy. I would love to figure out how to stop that from happening automatically.
The upside of checking in on the code, though, is that I can come up with smart directions for the AI from both a product and tech perspective. This is especially helpful when the dumb suggestions add a lot of complexity.
I think it's like when a product person asks for a new feature, or when a founder building their own product selects which feature is smarter to build and how.
AGENTS.md
-- which will be ignored just often enough that you can never quite trust it.
What one developer calls clean the other calls messy.
My advice is to use it, then document the issues when it gets messy. It takes some time, but no more than recruiting, training, paying another engineer.
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.
But now using claude-code,gemini-cli,codex,etc it just seems less relevant. Just opened nvim with lazyvim and it feels nice, since I'm in terminal anyway it just feels more natural.
Still have zed opened, still like it but I guess honeymoon is over.
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.
Edit: Although I can integrate an agent in NeoVim, I don’t do it. I want to use my editor solely for that purpose, while the rest (versioning, agentic coding, git client, etc.) is done in the terminal. My NeoVim setup is simple and fast, which is why I prefer it over any other IDE or editor. Especially with the native package manager in the latest version. I also replaced BBEdit by installing Neovide, a GUI version of NeoVim. It starts in a split second and is incredibly smooth and fast. And it’s so enjoyable to work with that I use it as my preferred frontend to Obsidian.
I hope someday they get the funding they deserve, because it has insane potential. It's why I subscribe to their pay plan, even if I dont use it all the time, I want them to succeed.
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. Punted back to Cursor for now.
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.
In terms of in-line instantaneous error highlighting, introspection, refactoring, and autocomplete, it's not on the same level as JetBrains.
The claim really falls flat the moment you open it up and it is "native but not as you know it" providing the same UX experience of any other electron junk.
Its multi buffer and speed sound trivial but using anything else feels wrong now.
What's needed today is a nice way to orchestrate agents and do some small manual edits there and there to the code.
Love your editor again
Zed is a minimal code editor crafted for speed and collaboration with humans and AI.
And if you want AI integration at your choice and control, agent-shell (and chatgpt-shell, which is LLM-agnostic despite the name) are great packages. They’re totally hackable with elisp like you’d expect, which I personally haven’t done a ton with, because I use AI pretty sparingly, but I imagine the crowd here could come up with plenty of ideas for how to program your editor and your agent interface together.
Search for font size in preferences.
You'll see a 'font size' under 'buffer' (editor), under 'UI Font', and under 'Agent Panel' to let you control font sizes in all of those places independently.
> Is there any editor still being being developed and focusing on the experience of coding by hand?
Zed lets you hand-edit too! It's fast and decent. vim, neovim, Emacs, Helix, and JetBrains products continue to do that well too. There are still more traditional IDEs/editors than pure AI ones.
You can also toggle AI features off in Zed from preferences if you want to.
I do use Zed without AI features, it's just a bit of a disappointment (though understandable) since it was originally marketed as just a nice speedy editor.
https://zed.dev/docs/icon-themes
I don't think changing icon size independent of UI font size would be a dealbreaker for many. (I'm quite happy having icons that scale in line with font size, but then I use the Material Icon Theme, which is easy to scan at most sizes.)
Is Zed lacking any feature you need?
I end up doing things in the terminal tab because its faster than the ui or is more clear.
The basics are good but thats about it.
Another bug is that clicking on new files in the git UI doesn't bring up their diff---you need to click them twice to open the file. I'd like to have those files included in the diff view just like other files are.
I'd love for there to be an easier way to get to the "view file history" view---I didn't realize that it existed until I tried searching for it. I'd love a "line history" view like GitLens has, as well.
https://github.com/zed-industries/zed/discussions/42583
Thanks for building an awesome product :)
Do you really think Zed's focus on AI is just about money? You do realize software engineering is in the midst of a tectonic shift?
As an everyday user of AI, both at work and privately, I am not that convinced. The biggest effect I've seen so far is demand for faster work because "everything is faster with agents", but software quality is slowly dropping in software I see around me.
Current AI is very useful as a trivia engine and as a language manipulation tool - i.e. it can quickly extract information from a huge amount of text. But it still sucks when writing new things.
Admittedly, here has been much progress, but it seems to be slowing down. Money is drying out, models are getting nerfed, and only better scaffolding and workflows are making it better. Unless they build 100x more data centers, I don't see models getting significantly better.
Yes? Legitimately curious what other explanation is there here, thats the reason all of these LLM integrations across all software is being pushed.
Like this.[1]
> AI-assisted coding has become the norm and with tools like Cursor, GitHub Copilot, Claude Code, Codex, we are increasingly letting models touch our code.
... how is it good literaly style to both (1) assume that something is the norm, and (2) use a long intro-sentence to state that something is the norm? Pick a lane—either it is the norm and you don’t need to state it or it isn’t and you need to set the stage. Stating the apparently obvious makes your (their) writing read like a eighth grade paper.
In short I’m agnostic as far as proclamations go. ;)
And Zed lets me do that while remaining fast and minimal.
As for (even more) minimal editors, perhaps just Gnome Edit? Or Kate?
such a dark and gloomy quote as the mission statement.
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, neither worktree is "wrong" but the code is incoherent. You need either a shared decision log that every agent reads before starting, or an orchestrator that hands out scope narrow enough that no two agents can collide.
Zed's post is solving filesystem-level parallelism. The harder coordination problem is semantic, and that's where time savings from parallelization go to die.