La revisión de código con IA desborda a los ingenieros senior

Los equipos que más han adoptado la IA para escribir código fusionan un 98% más de pull requests, y el tiempo dedicado a revisarlos ha subido un 91%, según un estudio de Faros. Quien firma la pieza dirige una comunidad de ingenieros senior y lo describe sin rodeos: su mejor gente, la que más se preocupa por la calidad, se está ahogando en colas de revisión que ya no disfruta.

No es una impresión suya. En otro de los estudios que cita, el 77% de los ingenieros dice dedicar ahora menos tiempo a escribir código, porque ese tiempo se ha ido a revisar lo que producen los modelos. El trabajo ha pasado de construir a verificar.

Por qué revisar código de IA cuesta más

Cuando el código lo escribió un compañero, la intención viaja con él: puede explicar qué alternativas descartó y con qué restricciones trabajaba. Con una máquina ese razonamiento no existe, y el revisor acaba deduciendo la intención a partir del diff. Es una tarea cognitiva distinta. Y el código generado pasa el examen visual, que es justo lo que lo vuelve peligroso a escala.

El autor agrupa los fallos típicos en cinco familias: código plausible pero incorrecto, que cubre el camino feliz y rompe en los bordes; sobreingeniería, donde un problema de 15 líneas se resuelve con una capa de abstracción de 200; código que ignora las convenciones del repositorio; alucinaciones seguras, llamadas a API que no existen o a métodos ya deprecados; y patrones copiados sin entender por qué están ahí, con reintentos donde no tienen sentido.

La carga se ve en los números: quien revisa puede tener 15 pull requests de 400 líneas cada uno en la cola, todos los días. Y no son precisamente los que se resisten a la IA los que más lo sufren, sino los que la adoptaron antes y construyeron la cultura de revisión del equipo.

Qué propone

La respuesta no es "revisar mejor" ni poner un LLM a revisar, porque el mismo modelo comparte sus puntos ciegos. La propuesta es sacar trabajo de encima al revisor en tres frentes. El primero, convertir en invariantes el feedback que se repite: revisar los últimos 100 comentarios de PR del equipo y clasificarlos. El autor cifra el reparto en un 45% deterministas, un 30% verificables ejecutando el código y un 25% de juicio real. Un comentario que se repite es una regla que falta por escribir, y una comprobación de AST no vuelve a necesitar revisor.

El segundo frente es conservar la intención: los prompts y las sesiones de agente que produjeron el cambio contienen las decisiones de diseño, y casi todo el mundo los tira. Convertidos en criterios de aceptación, el revisor discute si se resuelve el problema correcto en vez de leer 400 líneas a las cuatro de la tarde. Conviene señalar que el autor trabaja en Aviator y construyó Verify, la herramienta que vende exactamente esto, así que esa parte es también un argumento de venta.

El tercero es medir y reconocer ese trabajo. El 31% de los PR se fusionan hoy sin ninguna revisión, y un panel que mida líneas de código o adopción de IA no va a reflejar nunca el esfuerzo de quien sostiene la revisión.

Lo que está en juego no es la velocidad. Mientras el código generado siga pareciendo bueno a simple vista, el cuello de botella seguirá siendo humano, y será uno que antes no existía.