Shared AI pair programming: pairing when one side is an agent

Published August 13, 2026 · by the AQ team

Shared AI pair programming is classic pair programming discipline applied to agent work, in two moves. First, the human and the AI coding agent split the traditional pairing roles: the human navigates (intent, constraints, architecture, the quality bar) while the agent drives the keyboard. Second, the session itself is kept visible, so a second human can watch the live terminal, comment, or take a turn, instead of the work happening in a private window only one person ever sees. Most guidance covers the first move and ignores the second, which is backwards: pairing with an agent is a learnable technique, while keeping agent work shared takes deliberate setup that almost nobody does.

The roles flipped: you are the navigator now

In traditional pairing, the driver types and the navigator thinks ahead: reviewing each line as it appears, holding the larger plan, catching the wrong turn before it compounds. When one side of the pair is an agent, the assignment is forced. The agent produces code faster than any human driver, but it has no product context, no memory of last quarter's outage, and no sense of what your team considers done. So the human takes the navigator seat: you decide what to build, what good looks like, and when to stop; the agent does the typing.

A navigator does not dictate keystrokes, and you should not either: describe the destination and the constraints ("add rate limiting to the public endpoints, reuse the middleware pattern in the auth routes, do not touch the session code"), then correct course as the work unfolds. The failure mode is the disengaged navigator who says "build the feature," tabs away, and merges whatever comes back. That is not pairing; that is delegation without review.

Techniques that make human-agent pairing work

Plan before code. Good pairs talk before they type, and the agent CLIs support it directly. As of August 2026, Claude Code ships a plan mode where the agent can read and explore the codebase but every file edit is held back until you approve the plan it presents, and Codex CLI has an equivalent posture in its read-only approval mode, where the agent browses and proposes but changes nothing until you approve. Start substantial tasks there. Five minutes reviewing a plan catches design mistakes that would cost an hour in review.

Scope like you would for a human pair. A pairing session has a goal you can state in one sentence. Give the agent the same: one task, one branch, a definition of done. When a second task shows up mid-session ("while you are in there..."), open a second session on a separate branch or worktree instead of derailing this one.

Review in rounds, not at the end. Read the plan, then read the diff after each meaningful chunk, not after two thousand lines. Interrupt early: the cheapest correction is the one made before the agent builds three more layers on the wrong foundation.

Take the keyboard when describing is slower than doing. Good human pairs swap roles when the driver is stuck. Same rule here: if you have re-prompted twice and the agent still misses the point, make the edit yourself; the agent picks up your change as context and continues from it. Knowing when to stop steering and just type is the difference between pairing with an agent and fighting one.

Try ping-pong for test-driven work. The classic ping-pong pattern maps cleanly onto agent pairing: you write a failing test that encodes what you actually want, the agent implements to green, you write the next test. The human keeps defining behavior, the agent handles mechanics, and the test suite becomes the audit trail of every decision.

The missing half: nobody else can see the session

All of the above can be true and the work still ends up effectively unreviewed, because the entire collaboration happened in one person's terminal. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. The judgment calls a pairing partner used to see (the rejected first approach, the correction that saved the design, the moment the human took the keyboard) now happen where exactly one person can see them.

So the "shared" half of shared AI pair programming is its own problem: how does a second human join, watch, or review a session that lives in your terminal? There are several vendor-neutral answers, each with real limits.

Vendor-neutral ways to share a live agent session

Screen sharing. The default, and fine for a scheduled one-hour pairing block: run the agent, share your screen on the call, and your partner navigates with you. The limits: it is synchronous, it ends when the call ends, and the partner can never type.

A shared tmux session over SSH. The classic terminal-native answer. Two people SSH into the same machine and attach to the same tmux session; both see the same live terminal and both can type:

# On the shared machine: start the agent inside a named session
tmux new -s pair
claude   # or codex, or any terminal agent

# Your partner, from anywhere with SSH access to the same box:
ssh dev-box
tmux attach -t pair

This is genuine shared control of a live agent session with zero new tooling. The costs: everyone needs SSH access to the same machine (an attached partner can do anything your shell can), sessions die on reboot, and there is no record of who did what. Tools like tmate automate the invite step but inherit the same trust model.

Editor collaboration layers. Visual Studio Live Share remains free and actively maintained as of August 2026, with collaborative editing, shared terminals, and shared localhost servers. A Live Share session pointed at the workspace where an agent is running gets a teammate into the code and the terminal output. It lives on the host's machine, though, so it has the same lifetime as screen sharing: when the host closes the laptop, the session is gone.

Transcript sharing after the fact. Session logs and transcript exports let a teammate replay what the agent did, which serves review and mentoring well. It is not pairing: by the time anyone reads a transcript, every decision has been made. Worth noting when planning around the CLIs themselves: none of the major agent CLIs offers a built-in way for two people to join one live session from their own accounts as of August 2026; live multi-user collaboration is an open feature request in the Claude Code issue tracker.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ makes the "shared" half the default instead of a project. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: a teammate opens the same workspace and is watching the same live session, no SSH keys, no screen share, from any OS or a phone. Sessions survive a closed laptop and resume from any device, so a pairing block can pause at lunch and pick back up from wherever.

The trust model is tighter than a shared tmux socket. Watching is the default for anyone the workspace is visible to, but typing into someone else's terminal is delegated: the owner approves a control request in one click and keeps their own input the whole time. Visibility is owner-managed per workspace: team-visible, or private and shared with specific people. Each workspace gets its own isolated git worktree, so a second pairing session never tramples the first, and everyone signs into the agent CLIs with their own accounts (AQ never marks up model usage). When the pair wants eyes on the running app rather than the terminal, each workspace has a live dev-server preview with a shareable link that works without an account for viewing, and comments pinned on the preview can be sent to the agent as prompts.

Plainly: if your pairing happens in scheduled blocks between two people with access to the same box, tmux over SSH is enough, and this guide just gave you the commands. AQ earns its place when you want agent sessions shared by default (watchable, joinable, persistent) rather than shared by appointment. The Free plan is a personal sandbox AQ creates for you, nothing to install and no time limit; the Team plan is $50 per user per month in early access (standard $200), rate locked for your first 12 months.