AI pair programming is a claim about turn-taking, so we counted the turns. Across the 87 Claude Code sessions that built this site — 45.0 MB of transcripts, 2026-08-06 to 2026-08-22, twelve CLI builds — the human took 57 turns and the agent took 4,453. In the 19 sessions where a person was actually present, one human sentence bought a median of 30 tool calls and, once, 236 tool calls with 75 file edits inside them. What follows is what that measurement says about picking a tool, and which controls change the number. If you have not chosen a surface yet, the assistants pillar is the decision above this one.
Key takeaways
- The ratio is 78 agent messages to one human turn, measured over every interactive session on this repository. Pairing is not the shape of the collaboration; delegation is.
- The run-length distribution is bimodal with an empty middle. 66% of working runs finish under 50 tool calls, 34% run past 100, and not one run landed between 50 and 99.
- We interrupted on 12.3% of turns — 7 escapes out of 57. The interrupt is the only navigator move the interface offers and it is the one we used least.
- Permission mode is the real pairing control, not the model. Three of Claude Code's seven documented modes appear in our transcripts, and the split is 47 / 28 / 25.
- 78% of the sessions had no human in them at all by construction: 68 of 87 are headless
claude -pprobes, most of them this site's own measurement scripts.
The short answer
Pick the tool by its gates, not by its model. An ai coding partner that cannot be stopped mid-run, cannot be started in a read-only mode, and cannot show you a plan before it edits is not a partner in any sense the word carries — it is a batch job with a chat prompt. Every tool in this category writes usable code; they differ enormously in how many places you are allowed to stand.
The second decision is which mode you start in, and it is a bigger lever than the model choice. Auto mode versus plan mode covers the two ends of that range on Claude Code specifically.
npm run check:pairing # → 87 sessions, 45.0 MB, 2026-08-06 to 2026-08-22, across 12 CLI builds # → 57 human turns, 4,453 agent messages, 2,650 actions, 659 file edits
Is ai pair programming actually pair programming
The practice has a definition, and it is a definition about frequency. The Agile Alliance's pair programming glossary entry describes two programmers at one workstation and states that "it is expected that the programmers swap roles every few minutes or so." Martin Fowler's essay on pair programming makes the same point about the navigator staying continuously engaged rather than reviewing at the end.
Here is what that looks like when you count it on real work. npm run check:pairing reads every local Claude Code transcript for this repository and records structure only — turn types, tool names, timestamps, permission modes. No prompt, response, file path or tool argument is stored in the fixture.
| Class | Sessions | Human turns | Agent messages |
|---|---|---|---|
| interactive | 19 (38.4 MB) | 57 | 4,453 |
| headless | 68 (6.6 MB) | 0 | 172 |
The headless row is the first finding and it is not a rounding error. 68 of 87 sessions on this project have no human turn by construction — they are one-shot claude -p runs, and most of them are this site's own measurement scripts probing token counts and model identity. Any honest denominator has to exclude them, which is a thing we got wrong on the first pass. The initial version of the script computed the ratio across all 87 files and printed 80.6 agent messages per human turn. The number barely moved when we split the corpus — it became 78.1 — but what it was a claim about changed completely, from "agent sessions" to "sessions with a person in them."
Inside those 19 interactive sessions:
| Measure | Total | Per human turn |
|---|---|---|
| agent messages | 4,453 | 78.1 |
| tool calls | 2,650 | 46.5 |
| file edits | 659 | 11.6 |
| interrupts | 7 | 12.3% of turns |
Swapping roles every few minutes produces a ratio near 1. This ratio is 78. Whatever this is, the practice being described in the glossary is not it.
The solo run has no middle
A run is every action the agent takes between one human sentence and the next. It is the number the pairing metaphor is actually about: how long one party holds the keyboard.
| Run length | Runs | Share |
|---|---|---|
| 1-4 actions | 7 | 18% |
| 5-19 actions | 9 | 24% |
| 20-49 actions | 9 | 24% |
| 50-99 actions | 0 | 0% |
| 100+ actions | 13 | 34% |
Nothing landed between 50 and 99 actions. Out of 57 runs — 19 of which were conversational and took no action at all — the 38 working runs sort cleanly into two populations with an empty band between them. Under 50 is a conversation with some work attached. Over 100 is a delegated task. The middle case, the one where you and the agent are genuinely alternating on the same problem, did not happen once in sixteen days.
The extremes are worth naming. The median working run is 30 tool calls. The longest is 236 tool calls containing 75 file edits, from a session with two human turns total: one greeting and one instruction. The longest by wall clock ran 576 minutes — the machine held the keyboard for most of a working day on a single sentence of input.
That empty band is the practical finding. If you are trying to make an agent session feel like pairing, you are trying to move mass into a bucket that is currently at zero, and no prompt phrasing does that. The controls that do are in the next section.
The three levers we actually used
Claude Code's settings reference documents seven permission modes. Reading them side by side is the clearest statement of what "pairing" means to a terminal agent, because each one is a different answer to when does it stop and ask you:
default— runs only reads without asking.acceptEdits— also runs file edits and common filesystem commands without asking.plan— reads and plans but blocks edits until you approve a plan.auto— runs everything, with background safety checks.dontAsk,bypassPermissions,manual— the remaining three, one of which is an alias.
Our 57 human turns used three of them:
| Mode at the prompt | Turns | Share |
|---|---|---|
| default | 27 | 47% |
| acceptEdits | 16 | 28% |
| auto | 14 | 25% |
Plan mode does not appear in these transcripts at all, which is the uncomfortable half of the measurement. The one documented mode that structurally converts a long solo run into two shorter reviewed ones is the one this operator never started a turn in. The 13 runs over 100 actions and the zero runs in the 50-to-99 band are not unrelated facts — the gate that would have split those long runs was available and unused. What plan mode costs and what it buys covers the mechanics.
The second lever is the interrupt, used on 7 of 57 turns. The third is the shape of the request itself, and the tool mix shows what our requests turned into:
Bash 1398 ← 53% of everything
Edit 497
Read 220
Write 162
PowerShell 81
WebFetch 79
... 19 distinct tools; 92% of actions are in the top six
More than half of all agent actions were shell commands. That is what a session looks like when the work is build a measurement, run it, read the output, fix it — and it is also why the runs get long. Each command's output is the input to the next decision, and a person cannot usefully sit in that loop at one decision per second.
Choosing an ai coding partner by its levers
The commercial question underneath "best pair programming ai" is which tool lets you stand somewhere useful. Rank on the gates, in this order:
- Can it start read-only? A mode where the agent may read and plan but not write is the difference between reviewing a proposal and reviewing a fait accompli. This is the single highest-value feature in the category and it is not universal.
- Can you stop it mid-run? Seven interrupts in this corpus each cost one keystroke and saved an unknown amount of re-reading. A tool that only checks for input between tasks cannot be navigated, only started and audited.
- Does it ask before the class of action you care about? Edits and shell commands are different risks. A single approve-everything toggle collapses that distinction; a per-class mode preserves it.
- Does it leave a transcript you can count? This entire article exists because Claude Code writes structured JSONL to
~/.claude/projects. A tool that keeps no local record cannot be audited by you at all — you have its word for what it did. - Does the surface let you watch? The terminal-versus-editor split matters here more than for any other question in this category, because watching is the navigator's whole job. Terminal versus editor workflows is the comparison that decides it.
Nothing above is a claim about output quality, and none of it needs a benchmark. These are all properties of the harness rather than the model, which is the same conclusion model plus harness reaches from the other direction.
How to pair with an agent
- Start turns in a read-only or plan mode by default. The cost is one round trip; the benefit is that disagreement happens before 75 files change rather than after. Our own transcripts are the argument: 47% of turns started in
default, and those are not the runs that hit 236 actions. - Interrupt on the second surprising action, not the tenth. A wrong direction caught at action 5 costs five actions. The same direction caught at action 100 costs a full re-read, and 34% of our working runs went past 100.
- Size the request to the run you want. "Write the script and the article and the cover" is one sentence and it is a 200-action delegation. Three sentences would have produced three reviewable runs.
- Make the agent print evidence, not conclusions. 53% of actions here were shell commands precisely because the standing rule on this project is that a claim without a command behind it does not ship. That rule is also what makes long runs auditable after the fact.
- Keep the context small enough that the navigator can hold it too. If you cannot summarise what the agent is doing in a sentence, you are not navigating. What actually fills the context window covers the mechanics of the other half of that.
Common mistakes we made
- Counting the wrong denominator. Tempting because 87 sessions is a better-sounding corpus than 19. The symptom was a headline ratio of 80.6 that quietly included 68 machine-driven probes with no human in them. The fix was splitting on
entrypointand saying so. - Treating the average as the shape. 11.6 edits per human turn is a true number and it describes almost no actual run, because the distribution is bimodal with nothing in the middle. Any single average in this category is hiding the same structure.
- Never starting a turn in plan mode. Tempting because the gate feels like friction when you already know what you want. The symptom is thirteen runs over 100 actions and a review you cannot really perform. This is a documented feature we wrote about and did not use.
- Reading a long run as productivity. A 576-minute run is not eight hours of leverage; it is eight hours during which nobody could have caught anything. The honest reading is that it was one prompt and one very late review.
- Assuming the transcript is complete. It records what the harness wrote, not what happened in the terminal beside it. Manual edits, browser checks and everything done outside the session are invisible to this measurement.
What we are not claiming
No tool is ranked here. This is one agent on one repository, and every number would move on a different codebase with a different operator. The transferable part is the method: a session transcript is countable, and the count answers the question the category name raises.
Long runs are not defects. A 236-action run that lands working code is better than eight reviewed runs that do not. Nothing in this measurement can distinguish those two outcomes, and any article claiming otherwise is grading itself.
The mode split is a habit, not a benchmark. 47 / 28 / 25 across default, acceptEdits and auto describes how one person drove one project. It is evidence about what the levers do only in the sense that the lever nobody pulled is also the one whose absence is visible in the run lengths.
The corpus includes the session that wrote this article, which is unavoidable and worth stating. The figures are a dated snapshot; npm run check:pairing --scan reproduces them and exits non-zero if the CLI ever changes how it marks a typed prompt, because at that moment every ratio above would silently start measuring the schema instead of the work.
Conclusion
Choose your ai coding partner on its gates — read-only start, mid-run interrupt, per-class approval, a local transcript — and then actually use them, which is the part we failed at. If you want agent sessions that behave like pairing rather than delegation, start turns in plan mode and interrupt earlier than feels polite; those two habits are the only things in this measurement that would move mass into the empty band. Then run npm run check:pairing against your own transcripts, because the ratio in your sessions is a fact about you, not about the tool. Habits are the weakest enforcement mechanism there is, which is the argument for putting the ones that matter behind something automatic — this project states 273 rules, backs 36 with a check, and fires none of them on its own.
Frequently asked questions
Is AI pair programming really pair programming?
How often should you interrupt an AI coding agent?
What is the difference between an AI coding partner and an AI coding agent?
Does plan mode make AI pair programming work better?
How much code does an AI agent write between your prompts?
Muhammad Kashif
Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.




