¿Es imprescindible leer cada línea de código generado por inteligencia artificial para confiar en él? La respuesta es no. En lugar de eso, es mucho más efectivo centrarse en cinco aspectos clave: el propósito detrás del cambio, los criterios de aceptación, las invariantes que no se pueden romper, las decisiones tomadas durante el desarrollo y la evidencia que demuestra que el código funciona correctamente.
En la empresa Aviator, la adopción de esta estrategia ha significado que sólo nueve ingenieros puedan fusionar cuatro veces más solicitudes de extracción (pull requests), reducir el tiempo medio de fusión de 2,1 días a tan solo 3,4 horas y disminuir los retrocesos en un 40%. Aunque cada solicitud sigue siendo aprobada por un humano, el cambio radical está en qué aspectos lee y revisa dicho humano.
“Las decisiones requieren la intervención humana, y un diff (diferencia entre versiones de código) es el peor lugar para tomar esas decisiones.”
Esta conclusión surgió tras analizar los comentarios de revisión en sus propias solicitudes. La mayoría de las observaciones de los revisores eran o bien normas previamente establecidas o decisiones concretas. Los primeros pueden ser verificados automáticamente por máquinas, pero las segundas requieren juicio humano, y hacerlo leyendo únicamente diferencias de código es poco práctico.
El problema: la revisión de código no escala con la IA
El equipo pasó de un código escrito mayoritariamente por humanos con ayuda de IA a código generado por IA con soporte humano. Como resultado, las solicitudes fusionadas semanalmente aumentaron de 100 a más de 400, y el tamaño medio de cada solicitud superó las 640 líneas, mucho más allá del límite recomendado de 400, tras el cual detectar errores es complicado.
Sin embargo, detectar errores nunca fue el principal objetivo de la revisión. Un estudio de Microsoft en 2013 reveló que sólo el 14% de los comentarios se centraban en defectos. Más importante, la revisión es un mecanismo para compartir conocimiento y mantener actualizado el modelo mental que el equipo tiene del sistema, especialmente crucial cuando la mayoría del código lo genera una inteligencia artificial.
“La revisión es el medio por el cual los ingenieros comparten conocimientos y mantienen su comprensión del sistema actualizada, y eso es lo que realmente merece protección.”
Desde que se planteó que las revisiones tradicionales estaban muriendo, la pregunta recurrente fue si habían dejado de revisar el código. La respuesta es que dejaron de revisar las diferencias (diffs) de código.
Las soluciones intentadas y por qué fallaron
- Un revisor basado en IA: En una de sus propias solicitudes, este sistema generó 16 de 18 hilos de comentario, destacando problemas como números «mágicos», claves React basadas en índices de arrays o componentes con ejecución prolongada. Sólo uno de esos hilos detectó una condición de carrera real. Los comentarios importantes, relacionados con decisiones de diseño, se perdieron entre críticas menores.
- Un acuerdo de nivel de servicio (SLA) para revisión de cuatro horas: Sin poder añadir más revisores, implantaron una regla que aceleró las primeras revisiones pero dejó aprobaciones superficiales, ya que los revisores repasaban por encima para cumplir el plazo y luego se bloqueaban en otras tareas.
- Una autoselección de revisiones adaptada a sus normas: Mejor que un bot genérico, pero seguía leyendo las diferencias tras finalizar el código y las discusiones más valiosas —las decisiones y argumentaciones— quedaban perdidas en un chat.
Todos estos intentos fallaron porque intentaron mejorar la revisión basada en diffs, que es la parte menos crucial de la revisión de código, ya que muestra qué cambió, pero no por qué se hizo el cambio.
Para comprobar qué incluía realmente la revisión, el autor revisó una solicitud del año anterior con 14 hilos de discusión: 8 generados por bots que detectaron un error, 3 comentarios repetidos que eran reglas ya establecidas (como «usar GraphQLRetryableException para que Celery reintente»), y sólo 2 hilos con decisiones reales (por ejemplo, determinar si informar al usuario sobre comentarios no extraídos).
La estrategia que sí funciona: verificar la intención, no el código
La revisión de código tradicional abarcaba varias tareas a la vez: detectar errores, aplicar convenciones, definir decisiones de diseño y actualizar la comprensión del sistema. Ahora las han separado, asignando a cada función un enfoque diferente y más eficaz.
Debate previo a la solicitud de fusión: Un agente automatizado contraargumenta las propuestas del desarrollador mediante otro modelo distinto, documentando desacuerdos. En una reciente solicitud, plantearon cuatro diferencias; tres se resolvieron con motivos claros, dejando sólo una para que decidiera un humano, relacionada con nombres de variables.
Capturar la intención y criterios de aceptación: No se escriben como especificaciones previas, sino que se extraen durante la sesión de programación con el agente IA. Cada corrección o respuesta de un ingeniero genera un criterio. La intención explica por qué se hace el cambio, y los criterios cómo debe comportarse el resultado. Sin intención, los criterios son inservibles; sin criterios, la intención no puede ser evaluada.
“La intención explica por qué hacemos el cambio; los criterios de aceptación cómo debe comportarse. Sin intención no pueden verificarse, y sin criterios no pueden juzgarse.”
Convertir los comentarios repetidos en invariantes: Tras analizar un año de historial de revisiones en tres etapas (eliminar ruido, clasificar comentarios y unificar los repetidos), transformaron 11.400 comentarios en 212 reglas candidatas y 64 invariantes aprobadas. Cada invariante tiene un ámbito, método de verificación, autoría y un responsable asignado.
Por ejemplo, la regla “cada cambio en la configuración genera una entrada en el registro de auditoría sólo si hay cambios detectables” se aplica a mutaciones GraphQL y controladores API, se verifica ejecutando pruebas preliminares que guardan y leen registros, proviene de 23 hilos en 17 solicitudes revisadas y la supervisa el equipo de plataforma.
Comprobar cada invariante en todas las solicitudes es costoso y a veces inconsistente; por ello, agentes convierten estas reglas en patrones AST-grep que se ejecutan paralelamente para validar su efectividad antes de aplicarlas definitivamente, reduciendo el tiempo de revisión a menos de 0,3 segundos en 19 invariantes deterministas.
Demostrar que cada criterio se cumple con evidencias: Cada criterio se transforma en un escenario de prueba concreto. Un agente despliega un entorno de previsualización, interactúa con él como un usuario, y documenta capturas, solicitudes y registros. Por ejemplo, para la invariancia de auditoría, guarda un ajuste, verifica el nuevo registro, guarda nuevamente sin cambios y confirma que no se generan registros adicionales.
Muchas de estas comprobaciones nunca se hacen al revisar un diff. Algunas evidencias no requieren navegador: un contrato API se prueba con una solicitud y respuesta grabada; una regla de código con un patrón AST-grep. Se elige la prueba más sencilla que resuelva la duda, porque un marcador verde en la integración continua solo indica que las pruebas previstas pasaron.
Debatir las decisiones: Las decisiones aparecen de la sesión de codificación, la discusión entre agentes o pruebas que no pasan. Todas quedan registradas en la solicitud, identificando su origen y responsable. En una solicitud que añadía reintentos a entregas fallidas de webhook, cuatro de cinco decisiones se resolvieron automáticamente, y la restante, referente a la deduplicación de reintentos, exigió una decisión humana.
Los revisores repasan lo acordado, definen lo pendiente, reabren temas si disienten y dialogan con el autor, fortaleciendo así el conocimiento colectivo.
Gestión activa de las reglas: Los ingenieros dejan de leer cada línea individualmente y asumen la responsabilidad de las reglas que validan automáticamente el código. Mantienen su comprensión del sistema leyendo la intención, las pruebas y las decisiones.
Resultados tangibles
- Cuatro veces más solicitudes de extracción fusionadas por semana manteniendo el mismo equipo de nueve personas.
- Reducido el tiempo medio de fusión de 2,1 días a 3,4 horas.
- Comentarios humanos por solicitud de extracción disminuyen de 6,2 a 1,3.
- Retrocesos en el código bajan un 40% por cada 100 solicitudes revisadas.
El trabajo de revisión no ha desaparecido, simplemente se ha desplazado a perfeccionar invariantes, discutir decisiones y mejorar la verificación automatizada. La transición supone inicialmente un esfuerzo doble, pero a partir del segundo mes las reglas permiten reducir el tiempo de revisión, y en tres meses el equipo pasa a leer la intención, las evidencias y las decisiones, en lugar del código línea a línea.
