La IA escribe código más rápido, pero revisarlo sigue costando lo mismo

Un asistente de IA puede escribir en minutos una función de reintento de pagos que compila, pasa los tests y se lee sin una sola arruga. Y aun así acabar cobrando dos veces al mismo cliente. El problema no es que el modelo genere código sucio: es que producir código se ha abaratado mientras entenderlo y verificarlo sigue costando tiempo de ingeniero. Cuando el volumen de cambios supera la capacidad de revisión del equipo, los defectos se cuelan sin que nadie los vea.

Los datos que respaldan esa sensación no son muchos, y conviene leerlos con cuidado. En un experimento controlado de GitHub, desarrolladores profesionales que usaban Copilot terminaron una tarea concreta un 55% más rápido de media. Ojo con la letra pequeña: es una tarea, no el ciclo de vida completo, y el propio trabajo no promete que cada funcionalidad vaya a salir en la mitad de tiempo. El informe DORA de 2024 describe una tensión parecida a escala de entrega: la adopción de IA se asoció a mejoras declaradas de productividad individual, flujo de trabajo y satisfacción laboral, junto a efectos negativos en la estabilidad y el rendimiento de las entregas.

Eso no demuestra que la IA degrade la calidad por sí sola. Es un argumento para medir lo que ocurre después de generar el código, no solo lo rápido que apareció.

El reintento que cobra dos veces

El ejemplo que usa el autor original es un reintento de pago. El asistente devuelve un bucle de tres intentos limpio, con su bloque catch. Compila, y los tests de un cargo correcto y de un fallo inmediato pasan. ¿Y si la pasarela procesa el cargo y la respuesta se pierde por timeout antes de llegar a la aplicación? El siguiente intento vuelve a cobrar. El código no está desordenado: simplemente nunca se hizo explícito qué hacer cuando el resultado es desconocido. La solución pasa por una clave de idempotencia estable por pedido, reutilizada en cada reintento, y por definir qué errores son reintentables. La guía de revisión de Google insiste en lo mismo: hay que mirar diseño, complejidad, tests y contexto, no solo si el parche funciona.

De ahí salen cuatro hábitos que no dependen del lenguaje ni del asistente. Definir el comportamiento antes de pedir código —qué pasa con un timeout, qué errores se reintentan, cómo se evitan efectos duplicados— y dejar que el asistente escriba primero un plan. Mantener los cambios pequeños, separando el comportamiento, la limpieza y la documentación en pull requests distintas. Probar el comportamiento y no la implementación, preguntándose si el test fallaría al volver el bug que preocupa. Y que siempre haya una persona capaz de explicar cada línea que firma.

El cuello de botella ya no está en escribir. Está en revisar, y eso se sigue midiendo en horas de gente. Queda por ver cuántos equipos cambian sus métricas para reflejarlo.