Code review con IA sin bajar el listón de calidad

Poner un LLM a revisar pull requests es una de las primeras ideas que surgen cuando un equipo adopta IA. También es una de las más fáciles de hacer mal, porque parte de un malentendido sobre para qué sirve el code review.

El code review no existe solo para encontrar bugs

El estudio más completo sobre el tema, hecho en Google, muestra que la revisión de código sostiene cuatro cosas a la vez: encontrar defectos, mantener consistencia de estilo y arquitectura, difundir conocimiento por el equipo y crear registro de quién conoce cada parte del sistema.

Un LLM contribuye bien a las dos primeras. No contribuye en nada a las dos últimas. Si automatizas la revisión entera, cambias defectos encontrados por conocimiento no distribuido, y la cuenta llega meses después, cuando una sola persona entiende el módulo crítico.

Dónde paga la revisión automática

Tres categorías rinden de inmediato:

• Chequeos mecánicos con contexto. Un nombre inconsistente con la convención del repositorio, manejo de error faltante en un camino específico, un log que filtra dato sensible. El LLM lee el diff y el archivo alrededor, cosa que el linter no hace.
• Primera pasada en un PR grande. No para aprobarlo, sino para que la persona revisora llegue sabiendo dónde mirar.
• Explicar código ajeno. Reduce el costo de revisar un área que no conoces, que es justamente donde la revisión humana suele quedar superficial.

Dónde estorba

El modo de falla más común no es el falso positivo, es el volumen. Un bot que comenta quince observaciones de bajo valor en cada PR entrena al equipo a cerrar los comentarios sin leerlos. A partir de ahí, el comentario que importaba también se ignora.

El segundo modo de falla es la falsa sensación de cobertura. "El bot ya revisó" se vuelve justificación para que la persona revise menos, sin que nadie lo haya decidido explícitamente.

El dato que debería cambiar tu configuración

Un experimento controlado publicado en CCS 2023 comparó a personas escribiendo código con y sin asistente de IA en tareas relacionadas con seguridad. Dos resultados, juntos:

1. Quienes usaron el asistente escribieron código significativamente menos seguro en la mayoría de las tareas.
2. Quienes usaron el asistente quedaron más confiados de que su código era seguro.

La combinación es el problema. No es solo que la IA introduzca riesgo, es que reduce la desconfianza de quien debería revisar. Eso significa que el quality gate de seguridad necesita volverse más estricto cuando el equipo adopta IA, no más laxo.

Diseñando el gate

Un diseño que funciona en la práctica separa tres niveles con autoridades distintas:

Nivel 1, bloqueante y determinista. Lint, tipado, pruebas, SAST, verificación de dependencias. Nada de LLM aquí: debe ser reproducible y no puede variar entre ejecuciones.

Nivel 2, LLM como revisor consultivo. Comenta, no bloquea, y con presupuesto explícito: como máximo tres a cinco observaciones por PR, ordenadas por severidad. El límite es la parte importante. Obliga a priorizar y preserva la atención del equipo.

Nivel 3, humano con alcance declarado. La persona aprueba apuntando a corrección de dominio, decisiones de arquitectura y legibilidad para quien venga después. Explicitar que no necesita cazar comas es lo que hace al nivel 2 útil en vez de redundante.

Para requisitos de seguridad, ancla los niveles 1 y 3 en un estándar verificable en vez de en criterio personal. El ASVS de OWASP sirve bien porque está organizado en niveles, lo que permite exigir más de un endpoint de pagos que de una pantalla interna.

Mide el gate, no el bot

La métrica que importa no es cuántos comentarios generó el bot, ni cuántos se aceptaron. Es si el gate está frenando defectos antes de producción sin trabar la entrega. Dos series bastan: tasa de fallo en cambios y tiempo de revisión. Si la tasa de fallo no bajó y el tiempo de revisión subió, el gate cobra peaje sin entregar seguridad.

Vale también seguir la proporción de código reescrito poco después de entrar. Los análisis de repositorios vienen señalando aumento de duplicación y caída de refactorización a medida que los asistentes se popularizan, y ese es un síntoma que aparece semanas antes de volverse incidente.

Qué significa esto para tu equipo

Empieza consultivo y acotado: un LLM comentando como máximo cinco puntos por PR, sin poder de bloqueo, durante un mes. Compara la tasa de fallo en cambios antes y después. Promueve un chequeo a bloqueante solo cuando tenga historial de acertar.

Y mantén la revisión humana obligatoria en código generado por IA, sobre todo en caminos de autenticación, autorización y manejo de dato personal. La evidencia disponible dice que es justamente ahí donde la confianza sube más que la calidad.