Pair programming in Zed: real-time collaboration with AI assistance for both seats

Published 2026-05-01 by Owner

Zed has built-in real-time collaboration. Two engineers can edit the same file at the same time, see each other’s cursors, share a terminal, talk over voice. Unlike most editor pairing tools (Live Share, Cursor’s collab), Zed’s collaboration was built in from the start, which shows up in how cleanly it works.

I’ve been pairing in Zed for about three months. The technical setup is easy. The harder part is the social patterns when both people have AI assistance running.

Setup

Both pairs need a Zed account (free). One person creates a Channel:

Click the Channels icon in the left sidebar
Create a new channel (or use an existing one)
Click “Share Project” to add the current project to the channel
Invite the other engineer by username

The other engineer accepts the invite. Both can now edit, see each other’s cursors with names attached, and run shared terminal sessions. Voice chat is built in via the channel.

The project sharing is local — Zed doesn’t upload your code to a server. The connection is peer-to-peer over Zed’s relay. For most networks, this works without configuration. For corporate networks with strict outbound rules, the relay endpoint may need to be allowlisted.

The AI dynamic

Here’s where it gets interesting. Both engineers have their own Zed assistant panel running. Each one’s assistant has its own conversation history, its own model selection, its own context.

By default, the assistants are independent. If you ask your assistant to refactor a function, your pair sees the resulting edits in the file but doesn’t see your conversation with the assistant. They see code changes appearing in real time, the same way they’d see you typing.

This is closer to traditional pairing than I expected. The AI is more like a tool one person is using than a participant in the conversation.

The shared assistant pattern

Zed has a feature for sharing the assistant: in a channel, you can pop the assistant panel into a shared mode where both pairs see the conversation and can both prompt.

This is genuinely different from “two people with two assistants” pairing. With a shared assistant:

Both pairs see what’s being asked
Both can refine the prompt
The conversation history is shared context for both pairs going forward
The model’s response appears once, in one panel, visible to both

When this works well, it’s better than independent assistants because the pair’s reasoning is on the screen. You can argue about the prompt before sending it, which is often more productive than debating an output.

When this works badly, it’s because two people typing in the same prompt at the same time creates conflicts. Zed’s collaborative editing handles the conflict (you both see what you’re typing), but the prompt ends up incoherent until one person yields.

A pattern that works

After three months, here’s the pattern my regular pair partner and I have settled on:

Driver/navigator with AI as the navigator’s tool. The driver writes code; the navigator uses the AI assistant to research, plan, and verify. The navigator’s assistant runs in independent mode (their own conversation). The driver focuses on the editor.

This works because the AI is doing different work than the driver. The driver is in flow with the code. The navigator is one level up — checking documentation, exploring “what if we tried X,” reviewing the driver’s diff for issues. The AI accelerates the navigator’s research without distracting the driver.

When we want to use the AI for the actual code change (e.g., to scaffold a class structure), we switch to shared mode briefly, agree on a prompt, run it, then go back to driver/navigator.

What goes wrong

Both people prompting the AI at the same time. With independent assistants, this is fine — two parallel conversations. The risk is that you each generate a different version of the same code change and now have a merge conflict you’ve created with yourselves.

Talking past each other through the AI. When the AI is the third party, sometimes pairs end up debating the AI rather than each other. “But Claude said X.” “Well I asked it Y and it said Z.” This is unproductive and easily caught — call it out and step back to direct conversation.

Using AI when the pair is already in flow. If you and your pair are deep in a problem and making progress through human-to-human reasoning, asking the AI breaks the flow. The AI is faster at certain things; some kinds of reasoning are slower with the AI in the loop than without it. Notice which is which.

What goes right

Asynchronous review. When pairing across time zones, leaving notes for each other in the AI conversation is a useful artifact. The next session, your pair can read the conversation history to catch up on what was tried and what was learned.

Shared context for similar tasks. If you’re working on a feature that touches three similar parts of the codebase, the AI’s context (the files it’s seen, the patterns it’s learned) carries from one part to the next. When pairs share this context, they don’t have to re-establish it for each piece.

Reducing the cost of “let me just check something.” In traditional pairing, “let me check what this function does” requires both pairs to switch context. With AI, the navigator can ask the assistant while the driver continues writing. Five minutes of context-switching becomes 30 seconds of parallel work.

Channel persistence

Zed channels persist. Files shared in a channel stay associated with it. The next time you open the channel, the project is still there. The conversation history of the shared assistant (if you used shared mode) persists.

This is more useful than it sounds. Pairing sessions used to be ephemeral — start, work, end, lose the context. With persistent channels, “let’s pick up where we left off” is a real workflow. The previous session’s mental state, including what the AI knew, comes back.

Limitations

A few things Zed’s collab doesn’t do well yet:

Three-plus pairs. Zed handles two well; three or four people in a channel works mechanically but the cursor density gets confusing
Permissions. All channel members have full edit access; there’s no read-only mode
Recording. Sessions don’t record; if you want to review the pair session later, you need external recording
Mobile. No mobile clients; if your pair is on a phone, they’re out

For 1:1 desktop pairing with optional AI assistance, the setup is solid. For broader use cases, you’d still reach for tools like tuple or Slack huddles.