Cómo usar ia para programar: flujo de trabajo para equipos
Resumen
Usar ia para programar funciona cuando decides antes qué vas a pedir y revisas el resultado con más cuidado que a un compañero. Los datos de Stack Overflow 2025 y un estudio de METR muestran que la sensación de velocidad engaña: en el estudio, los desarrolladores tardaron cerca de un 19% más con IA aunque creían haber ido un 20% más rápido. Este flujo cubre el plan previo, los prompts concretos, qué herramienta elegir y qué nunca delegar.
Abres un ticket, pegas la descripción en una ventana de chat y recibes 200 líneas de código con aspecto razonable. Compila. Dos días después, un revisor pregunta por qué ignora tu wrapper de reintentos, y nadie del equipo sabe responder. Ese es el fallo habitual cuando alguien aprende cómo usar ia para programar: el paso de generar sale bien y todo lo que lo rodea sale mal.
Aquí tienes el flujo que doy a los ingenieros nuevos. Trata al modelo como un junior rápido y muy seguro de sí mismo que nunca ha visto tu repositorio. Está pensado en torno al tiempo de revisión, no al tiempo de escritura.
¿Te hace realmente más rápido la IA al programar?
A veces, y la respuesta honesta depende de la tarea. La Encuesta de Desarrolladores de Stack Overflow 2025 reveló que el 84% de los encuestados usa herramientas de IA o planea hacerlo, pero solo el 33% confía en sus resultados en algún grado. La queja principal, con un 66%, es un código «casi bien, pero no del todo». Otro 45.2% afirma que depurar código generado por IA lleva más tiempo de lo esperado.
Los datos controlados son menos favorables. En un estudio de 2025 de METR, 16 desarrolladores experimentados de código abierto resolvieron 246 issues reales en repositorios que conocían bien. Con IA permitida, terminaron cerca de un 19% más lentos, mientras creían haber ido alrededor de un 20% más rápido. METR ya publicó datos más recientes, así que toma ese número como una foto de las herramientas de principios de 2025, no como un veredicto.
La lección no es que la IA sea lenta. Es que la sensación de velocidad es un mal instrumento. Mide en minutos desde que se abre el ticket hasta que el PR se fusiona, no en lo rápido que apareció el primer borrador.
¿Qué debes escribir antes de pedirle algo a la IA?
Un plan, con tus propias palabras, de menos de diez líneas. Si lo saltas, el modelo rellena los huecos con sus propias suposiciones, que por definición son genéricas.
Mi plantilla es corta:
El cambio de comportamiento, en una frase.
Los archivos que esperas tocar, aunque no estés seguro.
La función o el patrón existente que el código nuevo debe reutilizar.
Una cosa que no debe hacer (ninguna dependencia nueva, ningún cambio de esquema).
Cómo sabrás que funciona: un test, un curl, una captura.
El punto 3 es el que la gente salta, y de ahí sale gran parte del código «casi bien». El modelo no sabe que existe tu helper withRetry a menos que lo nombres o que pueda leerlo.
Evita el prompt de «constrúyeme toda la aplicación». Principiantes y seniors obtienen el mismo resultado de él: un diff enorme que nadie entiende y un proyecto a medio terminar.
¿Cómo es un buen prompt en la práctica?
Toma una tarea real: el emisor de webhooks pierde eventos cuando el receptor no responde a tiempo. Un prompt débil dice «arregla la fiabilidad de los webhooks». Uno útil se parece a un ticket:
Añade reintentos con backoff exponencial a sendWebhook() en src/webhooks/sender.ts.
Reutiliza withRetry() de lib/http.ts. Máximo 4 intentos, con jitter activado.
No cambies la firma pública ni añadas dependencias.
Añade un test de vitest para un receptor que falla dos veces y luego responde bien.Ese prompt nombra el archivo, el helper a reutilizar, un límite y una comprobación. El resultado es un diff de unas 30 líneas que puedes leer de una sentada. Si el diff vuelve con 150 líneas, el modelo se ha desviado, y lo rechazas en lugar de editarlo.
Dos trucos ayudan. Pide primero un plan y léelo antes de que cambie ningún archivo: un plan equivocado cuesta treinta segundos, un diff equivocado cuesta diez minutos. Y cuando una respuesta no sirve, repite la restricción que se incumplió en lugar de discutir. «Has añadido una dependencia nueva; la regla es ninguna» funciona mejor que un párrafo de explicaciones.
¿Qué tipo de herramienta de IA encaja con cada tarea?
Existen tres formas, y confundirlas es el segundo error más común.
La autocompletación en línea predice tus siguientes líneas mientras escribes. Va bien con código repetitivo y tests cuando el patrón ya está en pantalla. El chat dentro del editor responde preguntas sobre el código seleccionado y propone cambios que aceptas bloque a bloque. Los agentes reciben una tarea, leen archivos, ejecutan comandos y te devuelven una rama.
Elige según lo barato que te resulte verificar. Una completación que lees en dos segundos tiene poco riesgo. Una ejecución de agente que toca 14 archivos tiene mucha recompensa y mucho coste de revisión.
Cursor es la opción centrada en el editor: un fork de VS Code con una autocompletación Tab muy sólida y sesiones de agente en paralelo. Merece la pena si pasas el día dentro de un editor. Sáltatelo si tu equipo estandariza en JetBrains y no va a cambiar.
GitHub Copilot es la opción de menor fricción para equipos que ya usan GitHub, porque los PR, las incidencias y la revisión están en el mismo sitio. Vigila la facturación: desde junio de 2026 pasó a créditos por uso, así que el uso intensivo de agentes cuesta más de lo que sugiere el precio por puesto.
Claude Code es nativo de terminal y agéntico: delegas una refactorización o la caza de un bug y luego revisas el resultado. No tiene autocompletación en línea y solo usa modelos de Claude. Es un intercambio justo si quieres delegar por tareas.
Aider es la opción por scripts y nativa de git. Hace un commit automático por cada cambio con su mensaje, así que deshacer es un git revert. Solo pagas los tokens del modelo, lo que encaja con quien quiere controlar el coste.
¿Cómo evitar que la IA escriba código que ignora tu repositorio?
Dale contexto de forma deliberada. La mayoría de las malas respuestas vienen de que el modelo nunca vio el archivo relevante.
Tres hábitos ayudan. Primero, adjunta dos o tres archivos que definan el patrón, no el directorio entero. Segundo, pega el test fallido o el error literal en lugar de describirlo. Tercero, mantén en el repositorio un archivo corto de reglas (nombres, manejo de errores, librerías prohibidas) que la herramienta lea en cada ejecución. La mayoría de las herramientas de agente admite uno.
# AI-RULES.md
- Errores: devolver Result, nunca lanzar excepciones en services/
- Las llamadas HTTP pasan por lib/http.ts (tiene reintentos y trazabilidad)
- Sin dependencias nuevas sin una nota en la descripción del PR
- Tests: vitest, junto a los archivos como *.test.tsCuatro líneas así eliminan una parte sorprendente de los comentarios de revisión. También ayudan a las personas.
En un repositorio que aún no conoces, haz preguntas antes de pedir cambios. «¿Dónde se aplica la caducidad de la sesión y qué la invoca?» es mejor primer prompt que «añade un refresh token». Lees la respuesta, abres los dos archivos que cita y solo entonces decides qué cambiar. Es el mismo bucle de grep, blame y preguntar a alguien que ya haces, solo que más rápido.
¿Cómo debes revisar el código generado por IA?
Más despacio que revisar el código de un compañero. Un compañero tiene historial en tu base de código. El modelo no lo tiene.
Mi lista, en orden:
Ejecútalo antes de leerlo. Un test que escribiste y que pasa vale más que una explicación convincente.
Lee los imports. Los paquetes inventados y los helpers desconocidos aparecen ahí primero.
Busca lo que falta. Rutas de error, manejo de nulos, limpieza de recursos. Los modelos escriben bien el camino feliz.
Revisa el tamaño del diff. Si pediste un arreglo de 10 líneas y llegaron 120, se reescribió algo que no pediste.
Borra lo que no sepas explicar. Si no puedes defender una línea en la revisión, no se fusiona.
Mantén el commit pequeño y el mensaje honesto. «Añade reintentos al emisor de webhooks (asistido por IA, tests añadidos)» está bien. Ocultarlo no ayuda a nadie y dificulta depurar después.
¿Qué nunca deberías entregarle a la IA?
Cualquier cosa en la que equivocarse sea silencioso y caro. La lógica de autenticación, los flujos de pago, las migraciones de datos y las comprobaciones de permisos son lugares donde «casi bien» pasa los tests y falla en producción.
Aun así puedes usarla ahí, pero en otro modo: pídele que revise tu código y liste riesgos, en lugar de escribir el código. Leer una lista de cinco posibles problemas te cuesta tres minutos. Leer una migración generada te cuesta la tarde que pasarás dudando de ella.
Si estás aprendiendo, hay una exclusión adicional. Escribe tú la primera versión y luego pide al modelo que la critique. Un junior que siempre acepta la versión generada aprende a pedir, no a programar, y la brecha aparece en su primera caída en producción.
¿Cómo cambia esto en un equipo?
La diferencia entre una persona y un equipo es la carga de revisión. Un desarrollador que usa agentes puede abrir más PR al día de los que los revisores pueden leer. Acordad tres cosas pronto:
Un límite de tamaño. Los PR de más de unos cientos de líneas cambiadas se dividen, lo haya escrito quien lo haya escrito.
Una norma de transparencia. Indica cuándo un cambio está asistido por IA, para que los revisores ajusten su atención.
Un archivo de reglas compartido. Una sola fuente de verdad para las convenciones gana a cinco prompts personales.
Para la incorporación de personas nuevas, el mejor uso que he visto es la lectura guiada por preguntas. Quienes llegan preguntan al asistente dónde vive cada cosa y luego lo verifican en el código. Acorta la primera semana de «¿quién es el dueño de esto?» sin entregarles código que no puedan mantener.
Un plan de la primera semana que puedes copiar
Día 1: usa solo la autocompletación en línea, para tests y código repetitivo. Día 2: haz tres preguntas sobre la base de código al día en el chat y verifica cada respuesta. Día 3: deja que el chat proponga un cambio pequeño por tarea y lee cada bloque. Día 4: prueba un agente en una tarea de bajo riesgo, como renombrar una clave de configuración en varios archivos, dentro de una rama. Día 5: escribe tu archivo de reglas a partir de lo que te molestó en la revisión.
Sigue un número a lo largo de la semana: minutos desde que empiezas un ticket hasta un PR fusionado, incluidas las correcciones de revisión. Si no bajó, has aprendido dónde la herramienta no encaja con tu trabajo, y eso también es un resultado.
Úsala primero para leer y después para escribir
La mejora más rápida y honesta que he visto no es la generación. Es la comprensión: entender un módulo desconocido en diez minutos en lugar de en una hora. Escribir código nunca fue la parte lenta del trabajo. Lo lento era leer, decidir y verificar. Apunta la herramienta a esas tareas, conserva tu criterio en el botón de fusionar, y lo demás llega solo.