Revisar código generado por IA cuesta más en módulos maduros que en código nuevo

Un preprint firmado por Michels et al. y enviado el 20 de agosto de 2026 defiende que el problema de revisar código generado por IA no es el volumen, sino dónde aterriza ese código. Su conjetura de cierre es que la ganancia de la IA es real en código nuevo y se reduce o cambia de signo en bases de código maduras. Los propios autores la presentan como falsable, y ahí está su interés: si se sostiene, explicaría buena parte del desacuerdo que hay en la literatura sobre productividad.

El razonamiento es fácil de seguir para cualquiera que haya revisado un merge. En terreno nuevo el trabajo es aditivo, el contrato con el resto del sistema es pequeño y el radio de explosión también. Un agente que razona en local alrededor de una función nueva suele salir bien parado, y el esfuerzo de revisión por línea es bajo porque hay poco que romper.

Un módulo longevo es lo contrario. Un cambio toca llamadas, invariantes, orden de operaciones y comportamiento del que dependen otros ficheros. Lo que el agente no ve desde el diff es justo lo que se rompe: el acoplamiento con estado, el caso límite que resolvió alguien que ya no está en el equipo. Ahí la generación es rápida y confiada, y el revisor tiene que cargar con el modelo mental completo que el generador no construyó. La mayoría de los arreglos sobre código maduro cae precisamente donde la validación es más lenta.

Tarifar la revisión por edad, no por tamaño

La lectura práctica que hace el autor de la nota no es revisar menos, sino asignar el esfuerzo por edad y acoplamiento del código en lugar de por tamaño del diff. Un cambio pequeño en un módulo central merece un revisor con más contexto que un merge grande en zona nueva. Si la cola de revisión es plana, la redistribución que trae la IA empuja peso hacia el extremo caro mientras el equipo lo gasta en el barato.

El respaldo empírico es limitado y viene de la telemetría recogida en esa misma revisión: el tiempo de revisión sube un 441% bajo vibe coding, mientras la salida crece más rápido que el entendimiento necesario para aceptarla. Es la cifra de los autores, no de un tercero independiente.

Qué se puede medir ya

Para un equipo con un piloto en marcha, el siguiente paso concreto no requiere esperar a nada: separar las métricas de revisión por edad del código. Minutos de revisión por línea en ficheros nuevos frente a ficheros tocados en el último ciclo de release. Si los minutos se concentran en el lado maduro, la conjetura se está cumpliendo en tu repositorio y el plan debería apuntar la supervisión humana al núcleo acoplado, dejando las rutas de revisión baratas para el trabajo aditivo.

Conviene no perder de vista la naturaleza de la fuente. Es un preprint, no ha pasado revisión por pares, y algunos de los estudios que resume sí la han pasado, cosa que el texto indica donde corresponde. No hay todavía ningún benchmark publicado que resuelva la pregunta, y los propios autores insisten en que la suya es una conjetura y no un resultado establecido. Sirve como modelo para decidir dónde poner la atención, no como dato cerrado.