Desde que empezamos a incorporar la inteligencia artificial a nuestro flujo de desarrollo, encontrar una forma natural de seguir trabajando en pair programming se ha vuelto más difícil. La velocidad con la que la IA genera código, la cantidad de contexto que acumula y el hecho de que una sola persona controle la conversación pueden hacer que el trabajo deje de sentirse compartido.

Mientras una persona escribe las instrucciones y conduce la interacción, la otra intenta seguir un razonamiento que avanza demasiado rápido. Los papeles tradicionales de driver y navigator empiezan a perder sentido: ya no hay una persona escribiendo cada línea mientras la otra observa, anticipa y orienta.

Pero quizá el problema no sea que la IA haya roto el pair programming. Quizá intentamos aplicarlo sobre el objeto equivocado.

Del código al modelado

El valor del pair programming nunca estuvo únicamente en compartir un teclado. Estaba en construir una comprensión común del problema, confrontar perspectivas y asumir conjuntamente la responsabilidad sobre las decisiones tomadas.

Con la IA, ese valor no desaparece, pero cambia su centro de gravedad. El pair ya no tiene que girar principalmente alrededor de la escritura del código, sino del modelado de la solución.

Modelar no consiste solo en dividir una feature en tareas. Significa comprender sus criterios de aceptación, identificar las reglas de negocio, separar responsabilidades, definir límites, decidir cómo encaja la solución en la arquitectura, plantear la estrategia de pruebas y convertir la implementación en cambios pequeños y revisables.

La IA participa en ese proceso como una tercera voz. Puede cuestionar nuestro enfoque, detectar riesgos, explorar alternativas y ejecutar tareas ya definidas. Tiene voz en el debate, pero no la decisión final. Esa responsabilidad continúa siendo humana y compartida.

Nuevos papeles para una nueva dinámica

En nuestro flujo hemos actualizado los roles tradicionales: hablamos de driver de contexto y navigator crítico.

Ambos participan en el modelado y en la conversación con la IA, pero el driver de contexto conduce materialmente esa interacción: formula las ideas acordadas, mantiene la continuidad del contexto y desarrolla las líneas de trabajo que la pareja decide explorar.

El navigator crítico sigue activamente el razonamiento, cuestiona las respuestas de la IA, detecta supuestos o incoherencias y modifica junto al driver el rumbo de la conversación cuando es necesario.

Los roles no determinan quién modela la solución, sino quién conduce la interacción y desde qué perspectiva participa cada persona. Los roles se mantienen durante una feature para conservar la continuidad y se intercambian en las siguientes, lo que evita que siempre sea la misma persona quien aprende a trabajar en profundidad con la IA.

Un flujo con puntos de sincronización

Nuestro trabajo tampoco es lineal. Cuando llega una nueva feature, comenzamos juntos: analizamos el problema, separamos responsabilidades y debatimos cómo abordarlo. Después, quien actúa como driver de contexto profundiza con la IA y construye un flujo de tareas.

Antes de que las decisiones sean definitivas, volvemos a sincronizarnos. El driver explica qué problemas encontró, qué alternativas valoró y por qué tomó determinadas decisiones. El navigator aporta distancia crítica y puede descubrir aspectos que la conversación prolongada con la IA había normalizado. Si es necesario, remodelamos el plan.

La implementación se realiza mediante tareas y MR pequeñas. El código generado se revisa primero por quien lidera la feature y después vuelve a revisarse en pareja. Esa revisión no es una ceremonia de aprobación: puede devolvernos al modelado si la solución todavía no se comprende o no respeta los principios acordados.

Lo vimos con una implementación que funcionaba y cuyas pruebas pasaban. Al revisarla juntos descubrimos que las pruebas estaban demasiado acopladas a la implementación: comprobaban cómo estaba construido el código, pero no protegían todos los comportamientos y reglas de negocio relevantes.

La revisión no encontró únicamente fallos. Reveló que habíamos confundido código ejecutable con una solución verdaderamente comprendida.

La incomodidad también aporta valor

Al principio puede resultar pesado defender continuamente las decisiones tomadas. Sin embargo, esa incomodidad suele aparecer cuando hemos aceptado algo porque funciona sin entender del todo por qué está ahí.

Tener que explicarlo nos obliga a leer, comprender y evaluar cada solución. Si no podemos justificar una decisión sin decir «lo propuso la IA», aún no deberíamos considerarla nuestra.

Para nosotros existen cuatro límites que ninguna propuesta debe vulnerar: separación de responsabilidades, reglas de negocio explícitas, calidad de las pruebas y legibilidad. Se proporcionan a la IA como contexto, se utilizan para evaluar sus alternativas, se le pide que justifique cómo los respeta y se comprueban nuevamente durante el modelado y la revisión humana.

Esto no significa aplicar siempre el proceso con la misma intensidad. En cambios pequeños, rutinarios o de bajo riesgo, el coste de sincronización puede superar el valor que aporta. El flujo debe adaptarse a la complejidad, la incertidumbre y el impacto de cada tarea.

La IA transforma el pair, pero no lo elimina

La IA puede generar código más rápido de lo que nosotros podemos escribirlo, pero no deberíamos aceptarlo más rápido de lo que somos capaces de comprenderlo y explicarlo.

El pair programming con IA no exige compartir cada pulsación de teclado. Exige compartir el entendimiento del problema, el modelado de la solución y la responsabilidad sobre lo construido. Introducir puntos de sincronización, cuestionar las decisiones antes de que sean definitivas y preservar una mirada externa evita que la conversación con la IA se convierta en una cámara de eco.

Quizá la IA no haya roto el pair programming. Quizá nos está obligando a recordar cuál era su verdadero valor.