Programación en pareja con IA: cómo trabajar con un agente

La programación en pareja con IA es la misma práctica que los desarrolladores usan desde hace décadas, con uno de los asientos ocupado por un agente de código. Un lado pilota: escribe el código. El otro hace de copiloto: mantiene el plan, vigila los errores y decide qué viene después. La diferencia es que un agente escribe mucho más rápido de lo que tú lees, así que lo difícil ya no es escribir código. Es no perder el control de lo que se escribe.

Esta guía cubre cómo repartir los papeles con un agente, cuándo dejar que pilote solo y cuándo revisar cada paso, cómo encajan en esa decisión los modos de aprobación de Claude Code, Codex y Gemini CLI, cómo mantener los pasos pequeños y los diffs legibles, cómo programar en pareja para aprender y no solo para delegar, y cómo dejar que dos agentes trabajen en pareja mientras tú haces de copiloto. Los nombres de comandos y modos siguen la documentación oficial a octubre de 2026.

Piloto y copiloto, con un agente en uno de los asientos

En el pair programming clásico los papeles se intercambian a menudo. Con un agente hay dos configuraciones útiles.

Tú eres el copiloto, el agente pilota. Es lo habitual en la mayoría del trabajo. Describes el objetivo, las restricciones y el siguiente paso; el agente edita archivos y ejecuta comandos; tú lees lo que ha hecho y corriges el rumbo. Tu trabajo es el de un buen copiloto: no perder de vista el conjunto, notar cuando el código va en mala dirección y pararlo pronto.

Tú pilotas, el agente es el copiloto. Escribes tú el código y usas al agente como segundo par de ojos. Pídele que revise la función que acabas de escribir, que proponga casos límite, que encuentre de dónde sale un valor o que escriba el test antes de que escribas el código. Es más lento, pero es la configuración correcta cuando necesitas entender cada línea, por ejemplo en código que mantendrás tú solo o cuando estás aprendiendo un lenguaje nuevo.

Decide la configuración antes de empezar una tarea y dilo en el prompt: «Yo escribo el parser; tú revisas cada función que pegue y listas casos límite» es una sesión muy distinta de «Implementa el parser; para después de cada función para que pueda revisarla.» Cambiar de papel a mitad sin decirlo es como acabas con código que nadie entiende del todo.

Cuándo dejarle pilotar y cuándo revisar cada paso

La pregunta no es si te fías del agente. Es cuánto cuesta un error y cuánto tardarías en notarlo. Una regla sencilla:

Dos cosas hacen seguro dejar pilotar al agente: tests que fallan cuando el comportamiento se rompe y una forma de deshacer. Si tienes las dos, un giro equivocado te cuesta unos minutos. Si no tienes ninguna, revisa cada paso o añade tests primero (escribir tests unitarios con IA explica cómo).

Un buen término medio para tareas grandes es planificar primero. En Claude Code, el plan mode permite al agente leer y proponer un plan sin editar nada; revisas el plan, lo corriges y luego cambias de modo y le dejas ejecutarlo. El plan mode de Claude Code lo explica paso a paso. Revisar un plan lleva un minuto; revisar una implementación equivocada lleva mucho más.

Modos de aprobación: cuánto puede hacer el agente sin preguntar

Todas las CLIs de agentes de código importantes tienen un ajuste para decidir cada cuánto se detienen a preguntarte. Ese ajuste es tu estilo de pareja escrito como configuración.

Claude Code tiene modos de permisos, a octubre de 2026:

• default: pregunta antes de editar archivos y antes de comandos que no estén ya permitidos. Es revisar cada paso.
• acceptEdits: las ediciones de archivos en la carpeta de trabajo, más comandos de archivos sencillos como mkdir y mv, se aceptan sin preguntar; los demás comandos siguen preguntando.
• plan: lee y propone, no edita.
• auto: un clasificador en segundo plano revisa cada acción y bloquea las arriesgadas, así que el agente pregunta menos. Su disponibilidad depende de tu plan y tu modelo, y los administradores pueden desactivarlo.
• bypassPermissions: ninguna comprobación. La documentación solo lo recomienda en entornos aislados como contenedores o máquinas virtuales.

Pulsa Shift+Tab para recorrer los modos durante una sesión, arranca con claude --permission-mode acceptEdits o define permissions.defaultMode en los ajustes. Cuando respondes a una petición con «Yes, and don’t ask again», la regla se guarda y ese mismo comando no vuelve a preguntar. Los permisos de Claude Code explica el extremo arriesgado de la escala.

Codex CLI combina un sandbox con una política de aprobación. Su preset Auto, el predeterminado, le permite editar y ejecutar comandos dentro del proyecto y pregunta antes de salir de él (--sandbox workspace-write --ask-for-approval on-request). Usa /permissions durante una sesión para cambiar, por ejemplo a Read Only, o arranca con --sandbox read-only cuando solo quieras que mire.

Gemini CLI tiene --approval-mode con default (preguntar), auto_edit (aceptar ediciones y preguntar por otras herramientas), plan (solo lectura) y yolo (aceptarlo todo).

Una equivalencia práctica: revisar cada paso significa el modo por defecto en todas partes. Dejarle pilotar en trabajo rutinario significa aceptar ediciones pero seguir aprobando los comandos de shell, porque es en los comandos donde pasan las cosas irreversibles. El modo totalmente automático va en un contenedor o en un worktree desechable, nunca en una máquina con credenciales de producción.

Pasos pequeños

Programar en pareja funciona porque cada paso es lo bastante pequeño como para comentarlo. Con un agente esto importa todavía más, porque puede producir mil líneas antes de que termines de leer las cien primeras.

• Pide un paso cada vez. «Añade la función de validación y sus tests, y para» es mejor que «construye el flujo de registro».
• Di cuándo parar. Los agentes tienden a seguir con lo siguiente que les parece obvio. «Para después de esto y resume lo que has cambiado» hace que el ritmo lo marques tú.
• Haz commit después de cada paso en verde. Un commit por paso te da un punto limpio al que volver y un historial legible. git add -p te deja revisar cada hunk al añadirlo.
• Usa checkpoints para lo de en medio. En Claude Code, /rewind (o pulsar Esc dos veces) devuelve el código y la conversación a un prompt anterior. No registra los cambios hechos por comandos de shell, así que git sigue siendo tu red de seguridad real. Deshacer los cambios de Claude Code cubre las dos cosas.

Si un paso sale mal, deshazlo y vuelve a escribir el prompt con lo que has aprendido. Pedirle al agente que arregle su propio giro equivocado encima del código equivocado suele crear un lío mayor que empezar el paso de nuevo.

Revisar diffs

Como copiloto, el diff es tu herramienta principal. Léelo antes de aceptar el paso, no después de los tres siguientes.

git status
git diff --stat
git diff

En Codex, /diff muestra los cambios actuales dentro de la sesión. En cualquier agente puedes pedir: «Enséñame el diff de lo que has cambiado y explica cada hunk en una línea.»

Qué mirar, además de si el código funciona:

• Alcance. Archivos cambiados que no tienen nada que ver con la tarea. Los renombrados, el reformateo y las «pequeñas limpiezas» esconden cambios reales.
• Tests borrados o debilitados. Una aserción cambiada para que coincida con la nueva salida, o un test marcado como omitido, es una señal de alarma.
• Errores silenciados. Bloques catch vacíos, conversiones a any, reglas de lint desactivadas, flags --force.
• Dependencias nuevas. Cada una es código que ahora mantienes tú.
• Cosas que no sabes explicar. Si no puedes decir por qué está una línea, pregunta antes de aceptarla.

La guía de revisión de código con IA profundiza en cómo revisar lo que producen los agentes en la fase de pull request.

Aprender o delegar

Programar en pareja con un agente puede hacerte más rápido en lo que ya sabes o enseñarte lo que no sabes. Son sesiones distintas.

Cuando delegas, te importa el resultado. Da criterios de aceptación claros, deja pilotar al agente y revisa el diff y los tests. Es lo adecuado para código repetitivo, migraciones y código en áreas que ya entiendes.

Cuando quieres aprender, ve más despacio a propósito:

• Pide un plan y una explicación antes de cualquier código: «Explica cómo lo abordarías y por qué; no escribas código todavía.»
• Escribe tú la lógica principal y pide al agente que la revise.
• Pregunta «¿por qué esto y no aquello?» sobre sus decisiones, y pídele que te enseñe la alternativa.
• Pídele que escriba primero un test que falle y hazlo pasar tú.

Un hábito útil: si no podrías reescribir un trozo de código sin el agente, todavía no lo has aprendido, solo lo has aceptado. Eso es aceptable para parte del código, pero debería ser una decisión, no un accidente.

Dos agentes en pareja: uno escribe, otro revisa

El papel de copiloto también puede ir a un segundo agente. Un agente escribe; otro, idealmente de otro modelo para que sus puntos ciegos sean distintos, revisa; tú decides qué atender.

Una versión sencilla con dos CLIs en el mismo repositorio:

# Terminal 1: Claude Code implements the step
claude "Add rate limiting to the /login route. Stop when tests pass."

# Terminal 2: Codex reviews the uncommitted changes
codex review --uncommitted

codex review también puede revisar contra una rama base (--base main) o un único commit (--commit <sha>), y dentro de una sesión /review hace lo mismo. Pega al agente que escribe los hallazgos con los que estés de acuerdo e ignora los demás: la salida del revisor es un consejo para ti, no órdenes para el otro agente.

Unas pocas reglas hacen que la pareja entre agentes funcione:

• Otro modelo, o al menos una sesión nueva. Un revisor que comparte el contexto del que escribe tiende a darle la razón.
• El revisor no edita. Ejecútalo en solo lectura. Dos agentes editando los mismos archivos a la vez es un conflicto de fusión, no una revisión.
• Tú sigues de copiloto. No pases la salida de la revisión directamente al que escribe en un bucle sin fin. Léela, elige los problemas reales y envía esos.
• Escribe los criterios. «Busca validación de entradas que falte, errores sin gestionar y comportamiento cambiado» da una revisión mucho más útil que «revisa esto».

Para trabajos más grandes, el mismo patrón escala a varios agentes que escriben en worktrees separados con un revisor, algo que cubren los equipos de agentes de IA.

Cómo hacerlo en AgentVera

AgentVera ejecuta Claude Code, Codex, Gemini CLI y otros agentes de CLI lado a lado en una sola ventana, así que las dos configuraciones de pareja caben en una misma vista.

• Espacio de trabajo. Pon al agente que escribe y al que revisa en paneles contiguos sobre el mismo proyecto. Cada agente tiene su propio ajuste de permisos (Ask, Auto o Full access), así que el que escribe puede aceptar ediciones mientras el revisor solo lee.
• Aprobación automática (Pro y Team, Claude Code). Las lecturas, el git de solo lectura y los comandos de test, lint y build se aprueban por ti, mientras que los comandos arriesgados como git push, rm o git reset --hard siempre te llegan a ti. Es la configuración «déjale pilotar, pero lo peligroso es cosa mía» sin ir pulsando cada petición.
• Notificaciones y aprobaciones. Cuando un agente te espera, un atajo te lleva directamente al que lleva más tiempo esperando.
• Checkpoints. Cada turno se guarda, así que puedes deshacer un paso de una sesión sin tocar el historial de git.
• Revisión de código. Al final de un turno, el modelo de Claude que elijas revisa los cambios y lista los hallazgos con su gravedad y su file:line, y puedes devolvérselos al agente. Es un segundo agente integrado en el asiento del copiloto.
• Bandeja de revisión. El trabajo terminado espera en tarjetas con los archivos cambiados, notas de riesgo y diffs, donde lo apruebas o lo devuelves con una nota.
• Mensajes entre agentes. Los agentes del mismo proyecto pueden enviarse mensajes y compartir una lista de tareas, también entre CLIs distintas, así que el que escribe puede preguntar directamente al revisor.

Para terminar

La programación en pareja con IA funciona cuando los papeles están claros. Decide quién pilota antes de cada tarea. Ajusta el modo de aprobación al riesgo, no a tu estado de ánimo. Mantén los pasos pequeños y haz commit después de cada uno en verde. Lee cada diff antes de aceptarlo. Elige a propósito entre delegar y aprender. Cuando quieras una segunda opinión, deja que un segundo agente revise mientras tú sigues de copiloto.

Si quieres un trabajo largo y paso a paso para practicar, migrar JavaScript a TypeScript con IA es buena opción: cada paso es pequeño y el compilador te dice cuándo está terminado.