Pair programming con IA en 2025: hábitos que quedan

Actualizado: 2026-05-03

Después de dos años de convivir con asistentes de IA en el editor, las rutinas de trabajo se han asentado lo suficiente para ofrecer una reflexión más madura que la de cuando empezamos. Entonces todos estábamos descubriendo cómo usar Copilot, experimentando con prompts, y sintiendo una mezcla de fascinación y escepticismo. Hoy la experiencia es más sobria, más práctica, y hay hábitos concretos que han cuajado y otros que no.

Este post no es un review de herramientas, sino un balance personal sobre cómo ha cambiado el pair programming con IA y cuenta qué hábitos han quedado y cuáles han caído con el tiempo.

Puntos clave

• La fricción para escribir código boilerplate ha desaparecido casi por completo.
• Explorar código desconocido con el asistente es más rápido que grep-and-read, sin sustituir la lectura —la IA la guía.
• Revisar siempre el código generado antes de commitear: la tasa de errores sutiles es real (variables mal nombradas, funciones que no existen, librerías imaginadas).
• El modo agente (Claude Code, Cursor Composer) funciona bien para tareas acotadas; sin supervisión activa puede generar cambios no deseados.
• La IA es un amplificador, no un sustituto: habilidades como razonar sobre concurrencia o diseñar APIs se oxidan si siempre se delegan.

Qué ha cambiado en el día a día

Lo más importante es que la fricción para escribir código boilerplate ha desaparecido. Cualquier cosa repetitiva (un CRUD, un test de integración estándar, un parser de un formato conocido) se delega al asistente y sale razonablemente bien. Su efecto acumulado durante dos años es considerable: cierto tipo de trabajo que antes consumía mañanas ahora consume minutos.

También ha cambiado la forma de explorar código desconocido. Entrar en una base de código nueva y preguntar al asistente «¿cómo funciona el flujo de autenticación aquí?» o «¿dónde se gestiona la caché de productos?» es mucho más rápido que buscar con grep y leer. La IA te orienta, y tú lees las partes relevantes con el foco correcto.

La tercera cosa que ha cambiado es la facilidad para probar ideas. Si tengo una idea de cómo resolver un problema pero no estoy seguro, pedirle a Claude o a Cursor que me enseñe cómo se vería ese enfoque en mi código es un ejercicio de cinco minutos. Antes, sondear una alternativa consumía una tarde; ahora pruebo dos o tres antes de decidir. Las decisiones de diseño son mejores porque las comparaciones son más baratas.

Los hábitos que han cuajado

A base de ensayo y error, me he asentado en unos pocos hábitos que han demostrado rendir bien:

1. Escribir un contexto inicial breve antes de pedir algo significativo. Cinco o seis líneas explicando qué intento conseguir, qué restricciones hay y qué decisiones ya están tomadas. No es un prompt engineering sofisticado; es simplemente no esperar que la IA adivine.
2. Revisar siempre el código generado antes de commitearlo. La IA produce código que parece correcto pero tiene errores sutiles: variables mal nombradas, condiciones al revés, usos de funciones que no existen, librerías imaginadas. Leer línea por línea es más rápido que debuggear después.
3. Pedir tests al mismo tiempo que código de producción. Si pido una función nueva, pido también al asistente un par de tests que la cubran. No son los tests definitivos, pero sirven para comprobar que el código hace lo que debe.
4. Usar el modo «agente» con cautela. Las herramientas que ejecutan comandos y modifican archivos por sí solas (Claude Code, Cursor Composer, Aider) son muy útiles cuando la tarea está bien acotada. Pero pedirle al agente «arregla todos los warnings del linter» sin supervisar qué hace puede terminar en cambios masivos no deseados.

Los hábitos que no han cuajado

Hay cosas que probé durante meses y terminé abandonando:

• Pedir diseños arquitectónicos completos. La IA es buena para ayudar a pensar en alternativas, pero pedirle «diseña la arquitectura de este microservicio» produce resultados que suenan razonables pero no son ni mejores ni peores que lo que haría yo solo. La decisión requiere conocer el contexto humano del equipo, historia del proyecto, trade-offs implícitos.
• Confiar en explicaciones de código ajeno sin verificar. Cuando le pregunto a la IA «¿qué hace esta función?», la respuesta suele ser correcta, pero a veces inventa comportamiento que no existe. Para cosas importantes, leer el código es inevitable.
• Usar el asistente como fuente única para aprender tecnologías nuevas. El resultado son huecos de comprensión serios. Hoy uso la documentación oficial como primera fuente y el asistente para acelerar la parte aplicada.
• Intentar que el asistente entienda el estilo de todo un proyecto. Con repositorios grandes, las herramientas actuales no tienen aún la capacidad para mantener coherencia de estilo a gran escala.

Lo que más ha sorprendido

Tres cosas me han sorprendido durante este tiempo:

La primera es cómo ha cambiado mi relación con los lenguajes de programación. Antes tenía preferencia clara por ciertos lenguajes (Python, Go) porque me resultaban cómodos. Hoy, con el asistente, la fricción de usar un lenguaje que conozco menos bien (Rust, Kotlin, Elixir) es mucho menor. Puedo elegir el lenguaje adecuado para el problema en lugar del lenguaje con el que soy más rápido. Este me parece un cambio importante de fondo.

La segunda sorpresa es la importancia de la calidad del contexto. He visto muchas veces que el mismo prompt, con el mismo modelo, produce resultados muy distintos según qué archivos tiene abiertos el editor. Cursor, Zed y Claude Code han invertido mucho en este aspecto. Parte de la diferencia entre equipos que sacan partido a la IA y equipos que no se reduce a cómo gestionan el contexto.

La tercera es que el entusiasmo inicial se ha moderado. Hace dos años sentía que la IA estaba a punto de cambiarlo todo; hoy siento que ya lo ha cambiado, en la cantidad en que lo iba a cambiar a corto plazo. La IA en el editor es una herramienta madura con beneficios claros y limitaciones claras, y esa madurez es sana.

Para entender cómo este mismo patrón se aplica en el contexto del code review, ver nuestro análisis de code review asistido por IA. Y para el contexto más amplio de cómo los agentes de codificación están evolucionando, ver Claude 3.7 Sonnet y Claude Code.

Mi recomendación para quien empieza ahora

Si estás incorporándote al uso de IA en tu flujo de programación, mi recomendación es concreta:

1. Elige una herramienta y úsala tres meses antes de juzgar. Todas las opciones serias (Copilot, Cursor, Claude Code, Zed con IA, Windsurf) son razonablemente buenas; cambiar entre ellas cada semana te va a impedir desarrollar hábitos efectivos.
2. Empieza con tareas donde puedas verificar el resultado inmediatamente: escribir tests, generar scripts sueltos, refactorizar funciones pequeñas.
3. Pide siempre al asistente que explique lo que ha hecho, aunque el código parezca obvio. Esa explicación te revela si el asistente entendió lo que querías, y te enseña patrones nuevos.
4. Mantén la costumbre de escribir código sin asistente de vez en cuando. No por nostalgia, sino porque algunas habilidades (razonar sobre concurrencia, diseñar APIs, leer código ajeno) se oxidan si las delegas siempre. La IA es un amplificador, no un sustituto.

Cómo creo que va a evolucionar

A corto plazo, las mejoras van a venir por dos lados: asistentes más integrados con la herramienta completa (IDE, terminal, git, CI/CD) que puedan actuar con contexto más amplio; y mejor comprensión de contextos grandes.

A medio plazo, el foco va a estar en la fiabilidad: reducir errores sutiles, mejorar la capacidad del asistente para decir «no lo sé» en lugar de inventar, hacer el código generado más mantenible.

Lo que parece improbable a corto plazo es el «desarrollador autónomo» que escribe y despliega software por su cuenta. Para quien programa, el mensaje es tranquilizador: la herramienta va a seguir mejorando, pero tu papel sigue siendo esencial, y vale la pena invertir en aprender a trabajar bien con ella.