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 2023. 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 para mí y para varios equipos con los que he trabajado. Cuenta qué hábitos han quedado y cuáles han caído con el tiempo, con la idea de que quien esté empezando con esto pueda saltarse algunos errores.
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. Esto no es ningún secreto, pero 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. Y no sustituye la lectura, sino que la guía: 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.
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.
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, libraries imaginadas. Leer línea por línea es más rápido que debuggear después.
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. Desarrollar y testear en el mismo prompt es más eficiente que hacerlo en pasos.
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 que no pretendía.
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, y ahí la IA no añade valor claro.
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. Al principio probé a aprender una librería solo con la IA, y el resultado fue quedarme con 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. Revisar el resultado y adaptar manualmente sigue siendo necesario, especialmente en proyectos con convenciones internas.
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. Esto 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, y se nota. 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. Los saltos siguientes (agentes verdaderamente autónomos, código completo generado sin supervisión humana) no son inminentes. La IA en el editor es una herramienta madura con beneficios claros y limitaciones claras, y esa madurez es sana.
Mi recomendación para quien empieza ahora
Si estás incorporándote al uso de IA en tu flujo de programación en 2025, mi recomendación es concreta y corta.
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.
Empieza con tareas donde puedas verificar el resultado inmediatamente: escribir tests, generar scripts sueltos, refactorizar funciones pequeñas. Deja los casos más ambiciosos para cuando tengas criterio formado.
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.
Y 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. Uno, asistentes más integrados con la herramienta completa (IDE, terminal, git, CI/CD, observabilidad) que puedan actuar con contexto más amplio. Claude Code y derivados están avanzando en esa dirección. Dos, mejor comprensión de contextos grandes: más contexto efectivo, mejor rendimiento en corpus extensos, integración más profunda con herramientas de búsqueda en el proyecto.
A medio plazo, el foco va a estar en la fiabilidad. Reducir errores sutiles, mejorar la capacidad del asistente para decir «no lo sé» o «necesito más información» en lugar de inventar, hacer el código generado más mantenible. Esto es menos espectacular que los avances de 2023-2024 pero es donde más trabajo queda.
Lo que parece improbable a corto plazo, a pesar de lo que prometen algunas startups, es el «desarrollador autónomo» que escribe y despliega software por su cuenta. Los pequeños pasos hacia ese destino son útiles, pero la visión completa sigue requiriendo avances que no se ven en el horizonte de los próximos meses. 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.
