Ir al contenido

Pair programming

De Scrum Manager BoK
Esta página es una versión traducida de la página Programación en pareja. La traducción está completa al 100 %.
⏱ 4 min  ·  📅 2026
Pair programming is an agile software development technique in which two programmers work together at a single workstation. One of them (the driver) writes the code, while the other (the observer) reviews it in real time. The two alternate roles throughout the session.

Description

Code developed by programmers working in pairs is shorter and of higher quality than what they would produce individually, because the observer role allows for ongoing reconsideration and continuous improvement of the strategy and of the code the driver is writing. The continuous conversation between the two roles also speeds up error detection and design decision-making.

It is a core practice of Extreme Programming and is part of the set of technical agility practices. In Scrum Manager's Scrum Master v4.0 manual it is called working in pairs, indicating that the concept is broader than programming: it applies to any work in which the quality of the result depends mainly on the knowledge of the person doing it.

The manual cites non-technological examples of the same logic: trains run with a driver and an assistant when technology cannot completely prevent human error, and aircraft cockpits have two pilots for the same reason.

When it is especially valuable

  • When the task requires a high level of concentration and a mistake could have significant consequences.
  • When working on legacy code or on a part of the system the driver knows little about: the navigator can provide context.
  • For onboarding new team members: pair programming with an experienced developer is one of the most effective ways to transfer tacit knowledge.
  • When working with TDD: the red-green-refactor cycle works especially well in pairs, alternating who writes the test and who writes the code that makes it pass.

Pair programming with AI tools

The adoption of coding assistants (GitHub Copilot, Cursor, and the like) has given rise to a new form of pair programming: the developer as the driver and the AI as a permanent observer/copilot. This approach has advantages but also a specific risk:

In human pair programming, the observer actively questions the driver's decisions and can sense when the direction is wrong. Generative AI neither questions nor has judgement about whether the strategic direction is the right one: it executes without discernment. The risk is that the developer ends up working alone de facto, using AI as an advanced autocomplete, without the benefit of the active questioning that a human partner provides.

To preserve the value of the practice when working with AI, it is advisable to:

  • Combine AI as a tool with human pairs for the most critical parts of the work.
  • Treat the review of AI-generated code as a pair review activity: at least one additional person verifies each significant AI contribution.

Common mistake

Forcing pair programming on every task. Pair programming delivers its greatest value on complex, critical, or highly uncertain tasks. On routine or well-understood tasks, it can reduce productivity without a proportional gain in quality. The decision to work in pairs should rest with the team and focus on the tasks where the practice adds the most value. It should not be a bureaucratic rule applied indiscriminately.

Resources

📄 Scrum Master v.4.0 [in Spanish] — Section: technical practicesFree download · Scrum Manager

See also

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.