Agent sessions are the new pair programming

Published July 30, 2026 · by the AQ team

For twenty years, the fastest way to turn a junior engineer into a good one was to sit them next to a senior and let them watch real work happen: how a vague ticket became a plan, which errors mattered, when to abandon an approach. AI coding agents have moved exactly that judgment into a new place: the agent session, where an experienced engineer scopes a task, corrects drift, and decides what to trust. If your juniors never see those sessions, they are locked out of the room where the craft now happens. The teams ramping juniors fastest in 2026 treat watching real agent sessions the way earlier teams treated pairing: a scheduled, first-class practice, not something that happens by accident.

What pairing actually transferred

The lasting value of pair programming was never the second pair of hands. It was the transfer of tacit knowledge: the judgment that never makes it into documentation because the person who has it does not know they are using it. A junior pairing with a senior absorbed how to read a stack trace without panic, how to decide what to test first, when "works on my machine" is good enough and when it is not, and a hundred small codebase-specific conventions. Learning sciences has a name for this pattern, cognitive apprenticeship: novices learn reasoning-heavy skills by observing an expert perform real work, with the expert's normally invisible thinking made visible, then practicing with coaching.

Pairing was the software industry's version of that model. And it worked because the expert's decisions happened somewhere the novice could see them: one screen, two chairs.

The room moved, and juniors were not invited

Agent-assisted work broke that visibility quietly. An agent session lives in one person's terminal. The prompts, the corrections, the abandoned first attempt, the moment the operator rejects a plausible-looking suggestion: all of it happens in a place exactly one person can see, and the only artifact that escapes is the finished pull request. The data says this is now the dominant shape of the work: 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.

That isolation is usually discussed as a review problem (we cover that side in the self-review problem). But it is equally a teaching problem. When coding was typed by hand, a junior could at least read the senior's finished code and reconstruct some of the reasoning. Agent work inverts that: the finished code is the least instructive part, because the agent wrote it. Everything a junior needs to learn (what was asked, what was rejected, what was verified) is in the session, and the session is private by default.

Juniors are the ones who cannot afford the black box

The same LeadDev analysis flags the downstream risk directly: junior engineers may not have the experience to recognize when an agent's suggestion is wrong. That is the core skill agent-era engineering runs on, and solo agent use is a poor way to build it. A February 2026 Anthropic study ran a randomized controlled trial with 52 mostly junior engineers learning an unfamiliar Python library: the group working with AI assistance scored 17 percentage points lower on a follow-up quiz covering the very concepts they had just used, with the largest gap in debugging, the skill of recognizing that code is wrong and working out why.

Put those two findings together and the failure mode is clear. A junior working alone with an agent produces plausible code they cannot fully evaluate, learns less from producing it, and then, four times out of five, is also the only human who checks it. Nothing in that loop teaches them the thing they most need: what an experienced person does differently.

What does teach it is watching. An expert's agent session is unusually good apprenticeship material, better in one way than watching them type ever was, because the expert's thinking is externalized by the medium itself. The prompt is the plan, written down. The correction ("stop, the fixture is wrong, look at how the other tests build it") is the judgment, written down. The moment they close the session and start over is taste, written down. This is also why the LeadDev piece's own recommendation to engineering leaders is team-level learning over solo experimentation: the skill spreads when the sessions are shared, not when everyone grinds alone.

How to run session watching without any special tooling

Pair on runs over a call. The simplest version is pairing, unchanged, with the agent as the third participant: the senior shares their screen on a call and drives a real task while the junior watches and asks questions. The senior narrates the parts the screen does not show ("I am rejecting this because it invents a config option"). One real session a week beats a training deck. Reverse the chairs regularly: the junior drives the agent while the senior watches, which surfaces exactly where the junior's judgment needs work, on a task that actually ships.

Share the terminal itself. For terminal agents, tmux gives you a watchable session with nothing but SSH: run the session on a shared box and let the junior attach read-only.

# Senior, on a shared dev box:
tmux new -s payments-fix
claude   # or codex, or any terminal agent

# Junior, over SSH to the same box:
tmux attach -t payments-fix -r   # -r: read-only, watch without touching

Run transcript read-alongs. Live watching does not scale past a couple of people, but transcripts do. Keep the session records retrievable (exported transcripts, tmux scrollback captures, whatever your agent tooling preserves) and make one good session a week a 30-minute team read-along: what was the brief, where did the operator intervene, what got verified. Failed sessions are often the best material. This is the same habit that makes agent work reviewable at all; the checklist in how to review an AI coding session doubles as a read-along agenda, and session review is the name for the practice it belongs to.

Make it structural, not heroic. A rota beats goodwill: name whose session gets watched or read each week, and put it on the calendar. Practices that depend on someone remembering to invite the junior die in the first busy sprint.

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. It makes the watchable session the default instead of a setup task. 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 junior opens the workspace and watches the same live terminal the senior is driving, from any device, with the scrollback there to catch up on. Sessions survive a closed laptop, so this morning's session is still watchable this afternoon, and the workspace owner decides visibility: team-visible by default for learning, or private and shared with specific people.

The reversed-chairs drill works the same way: the junior drives in their own workspace while the senior watches live, and if the senior needs to type, the junior approves a control request in one click while keeping their own input. Because the diff, the live preview, and the PRs the agent opens all live on the same workspace as the terminal, a read-along covers the whole story in one link. Teams that run their onboarding this way are the subject of onboarding engineers with live agent sessions.

Plainly: the manual practices above work, and a team that pairs on runs weekly over a call is ahead of most. AQ removes the parts that make the practice fragile (the shared box, the SSH access, the screen-share scheduling) so watching real sessions can be how the team works rather than a meeting someone has to keep booking.