The agent writes the code. The team still pairs

Pair programming appears to have a terminal problem with coding agents: a programmer need not be present while the code is written.

A person can describe a change, send an agent into the repository and return later to a completed branch or pull request. The delegator may be a developer, but they are not sharing the implementation—and while the agent works, there is no pair at all. GitHub documents this background-delegation model directly, contrasting it with a synchronous session between a developer and an assistant.¹ Early evidence from 25,264 agentic pull requests finds the corresponding social pattern across open-source projects: single-human oversight dominated and multi-human collaboration was uncommon.²

If producing code was the reason to pair, the practice has become obsolete. Before defending it, we need to ask what disappears when the entire human pair leaves.

What disappears with the pair?

XP does not oblige us to preserve pairing’s old mechanics. Beck’s values–principles–practices framework instead asks what the practice made concrete, and whether those needs still have an adequate expression under new constraints.³

Four parts are especially relevant.

Communication and feedback ask that knowledge move between people and meet evidence while it can still change the work. Pairing made that exchange continuous; solitary delegation may defer the next human response until the agent asks for clarification or returns an implementation.

Diversity recognises that teams need differences in perspective, skill and experience, even though those differences also create conflict.³ Pairing applied two perspectives as the premise and design formed. With one delegator, the same human perspective frames the request and judges the result.

Reflection asks teams to examine how and why they work. Pairing externalised that reasoning: assumptions had to be explained and could be challenged immediately. Solitary agent work can leave the framing and judgement inside one person’s private reasoning.

Mutual benefit favours work that helps now without borrowing against the team’s future. Implementation pairing could advance a change and distribute knowledge; industrial research has observed teacher and student roles when partners hold different knowledge.⁴ An agent may complete the task without increasing the team’s shared ability to understand the next one.

These values and principles do not, by themselves, require pairing to survive. A team might express them through some combination of discovery workshops, asynchronous challenge, shared decision records, review, rotation and deliberate learning practices. They give us criteria for judging whatever comes next.

The question is whether a modified form of pairing can supply these qualities together, or whether they are better distributed across several new practices.

Pair in discovery

The task breakdown appears ready when the agent challenges one word in the working decision record: replacement.

Replacement is underspecified. If an administrator selects Resend twice, which link remains usable?

A product manager and engineer have been exploring a constructed change: let an administrator resend an expired invitation without recreating the recipient’s access. They have agreed to issue a replacement with the same access while keeping the expired link invalid. The agent has investigated the system, recorded their decisions and proposed reusing its existing path for issuing an invitation.

The agent’s challenge exposes a behaviour they have not decided. The product manager says that only the latest invitation should be usable: if both links work, resend has multiplied access rather than replaced it. The agent checks the token model and confirms that its proposed task would leave both replacement links valid. The engineer revises the design from issue another invitation to rotate the invitation. The agent updates the behavioural example, design constraint and affected tasks—all before implementation begins.

This is what I mean by discovery pairing. Two people continuously navigate one change, challenge each other’s reasoning and share authority over its decisions. The agent investigates, answers questions and keeps a working decision record coherent while the people judge and revise it.

The agent is not a passive scribe. It tests whether an answer has enough depth to carry into the next decision, challenges vague or unsupported responses and keeps the question open until the people address it. It does not own the decision. The pair can explicitly choose a direction the agent questions, but they must make that choice rather than hide it inside an ambiguous word.

It is not pair programming if the term is defined exclusively as two programmers producing code at one computer; those mechanics have ended. I retain pairing because shared attention, immediate mutual challenge and joint navigation survive. The agent becomes the driver of the record, not the second human perspective.

BDD discovery workshops provide established prior art. Cucumber’s guidance brings product, development and testing perspectives together shortly before implementation, keeps the conversation brief, and uses examples to expose rules, questions and smaller slices.⁵ The proposal here borrows that attention to examples and pairing’s continuous co-navigation. A repository-aware agent connects the conversation to the current system and propagates each accepted decision through the record; it does not make the decision.

The process supplies the earlier criteria together. Communication and feedback happen while decisions remain revisable. Product defines what replacement promises; engineering exposes its consequence for system state. Their exchange forces reflection on an unstated assumption, and the agent tests it against the repository. Both people leave with a better model of the product and system.

Some teams may keep the record in a work item, divide it among examples and design notes, or preserve accepted behaviour in a durable specification. I use OpenSpec because its proposal, behavioural delta, design and task artefacts make the decisions inspectable, and its workflow allows implementation discoveries to reopen them.⁶ The process depends on connected, revisable decisions rather than that particular structure.

Who should be present?

Choose the participants before the session by predicting which perspectives the slice is likely to need. That prediction is a starting point, not a fixed attendance list.

Two engineers bring different system knowledge, design instincts and implementation experience. A product-and-engineering pair connects intended behaviour with technical consequences. A designer contributes interaction, accessibility and journey-level judgement; a tester contributes examples, boundaries and failure modes. Either may pair with product or engineering when those concerns dominate the uncertainty.

The conversation will sometimes prove the prediction wrong. A person or the agent may expose a question the group cannot answer with enough depth. Pause and bring in the missing perspective rather than handing the question off. Keep that person while their knowledge is likely to matter again; let them leave when it no longer justifies their attention. The aim is not constant reshuffling but a pragmatic correction as the change reveals what it needs.

Sometimes those likely needs justify gathering the whole squad from the outset. At other times an ongoing pair widens because the slice crosses several kinds of judgement, omitting one would be expensive to unwind, and calling people in only after the session would lose the context in which the issue formed.

That wider form is a mob. Woody Zuill’s foundational experience report described the whole team working on the same thing, at the same time, through one computer.⁷ In the agentic version, the agent reads the system, drafts, asks, answers, revises and challenges responses that lack sufficient depth. The squad navigates and retains authority: the agent proposes that a decision or task breakdown is ready; the mob decides whether to agree.

The literature does not establish that larger groups generally make better decisions. A study of mob-programming practice found substantial variation, stressed its social and organisational conditions, and noted that much of the field’s literature consisted of experience reports.⁸ The case for mobbing is narrower: use the squad when the likely cost of a missed perspective exceeds the cost of concentrating its attention. A mob cannot guarantee that the relevant knowledge is present—it may sit outside the squad—but it can reduce the need to predict which of the squad’s perspectives will matter.

This is a proposed operating rule, not an outcome established by the studies. It should be tested against the total attention, rework and learning it creates in a team’s own context.

End the collaboration before implementation

Human attention remains expensive even when agent implementation is cheap. Pair-programming research found trade-offs among quality, duration and effort rather than a universal advantage,⁹ with controlled evidence showing effects that vary by system complexity and developer experience.¹⁰ A mob raises the cost further.

Use one person and an agent for local, reversible and well-understood changes. Use a pair when a second perspective earns its cost. Begin as a mob when the likely decisions justify the squad’s attention, or widen into one when the discussion exposes missing knowledge whose potential cost justifies it. Correct the group in either direction as the work becomes better understood.

Once the people agree on the decisions and implementation breakdown, they leave. The agent writes the code alone. If implementation reveals that the system cannot preserve an agreed constraint, it reopens the decision that no longer holds and calls back the people whose judgement is needed.

This is not upfront design followed by a one-way implementation phase. The task breakdown in the invitation example changes the agreed behaviour and design before code exists; implementation evidence can revise them again. The work stays inside one thin vertical slice, no record section is mandatory, and the participants leave as soon as shared judgement is no longer needed.

The economic test is substitution. Teams already spend attention in refinement, planning, discovery workshops, clarifications, handoffs and late design discussions. Discovery pairing or mobbing must replace enough of that fragmented work to justify its cost. If the existing interactions remain unchanged, the session is another ceremony and should be removed.

Across matched event studies, Demirer, Musolff and Yang estimated a much larger increase in code written than in releases after teams adopted AI coding tools.¹¹ The measures are not directly comparable and do not isolate pairing, but they make the mechanism worth testing: one disagreement about what resend means can prevent an entire attempt at the wrong change.

Do not move pairing to review

A pull request is a useful integration boundary, not a substitute for pairing. Tests, contracts, static analysis and architectural rules should challenge an implementation without waiting for another engineer. Human review has a narrower purpose: use it when unresolved judgement remains or when someone deliberately needs to learn the implementation.

Research into modern code review identifies knowledge transfer, team awareness and alternative solutions among its expected outcomes, and finds that understanding a change’s reason and context is central to reviewing it effectively.¹² Fowler also distinguishes pull requests from the continuous review pairing can provide.¹³ Those benefits can justify selective human review, but they do not make it a new pairing surface.

A reviewer encountering the second-resend ambiguity must reconstruct why the change exists, reopen what replacement means and discard code built from the earlier answer. Discovery pairing encounters it while the decision is still forming. Pair there, automate routine verification of the implementation, and involve a human reviewer when the remaining judgement or learning warrants the cost.

What discovery pairing still loses

Discovery pairing does not preserve every benefit of implementation pairing. Agreeing intent and design does not teach another engineer how the generated code works, ensure several people can debug it later, or recreate the teacher and student roles observed in industrial pairs.⁴

Human review may sometimes earn its cost as an implementation-learning practice, but it cannot be assumed as the answer. Teams may need rotation, deliberate code exploration, teaching sessions or another practice not yet established. AI review, linting and tests do not automatically express everything they value about architecture, operability or maintainability either.

A team could distribute the original criteria across several practices: a workshop for diversity, a decision record for communication, asynchronous challenge for reflection, automated and human review for feedback, and rotation for learning. That is credible, but it introduces handoffs between the people, context and moments at which a decision can change.

Discovery pairing combines communication, feedback, diversity and reflection while the decision is forming; the record preserves the result instead of replacing the conversation. That integrated timing is why I would maintain pairing in a changed form. Mobbing extends it when the relevant perspectives are known to be broad or prove broader than expected. A deliberate ending keeps its cost bounded.

Pairing can survive agent implementation, but not as two people sharing the production of code. Move it into discovery when a second perspective earns its cost, choose the people for the expected uncertainty, correct that group as the change reveals missing knowledge, and end the session when the agent has an agreed implementation breakdown.

The agent implements the bounded slice alone. The team has already paired while its meaning was cheap to change.

References