Revisión de código con IA: herramientas y cómo hacerlo bien

La revisión de código con IA es el uso de grandes modelos de lenguaje para leer un pull request y comentarlo como lo haría un colega: señalando errores, sugiriendo redacciones más limpias y explicando qué hace un cambio. Ha pasado de novedad a estándar en un tiempo notablemente corto. Si tu equipo usa un asistente de codificación con IA para escribir código, probablemente ya estés usando herramientas de revisión de código con IA para comprobarlo, ya sea mediante un bot dedicado en tus pull requests o una pasada de revisión integrada en tu editor.

Esa velocidad es real, y vale la pena tenerla. Pero la velocidad también es donde empiezan los problemas. Una IA de revisión de código automatizada es segura de sí misma, elocuente y rápida: tres cualidades que hacen muy fácil confiar en ella más de lo que se debería. Este artículo es un análisis honesto de lo que la revisión de código con IA hace bien, dónde se queda ciega y cómo encajarla en un flujo de trabajo que de verdad mantenga el código inseguro fuera de producción. La versión corta: la revisión con IA hace la revisión más rápida, pero no hace el código seguro. Para eso, todavía necesitas pruebas de seguridad deterministas y criterio humano.

Lo que la revisión de código con IA hace bien

Empecemos por las buenas noticias, porque hay muchas.

La revisión con IA es excelente para la retroalimentación de gran volumen y bajo riesgo que solía consumir la tarde de un ingeniero sénior. Detecta erratas en nombres de variables, formato inconsistente, código muerto y errores de "uno de más" (off-by-one). Se da cuenta cuando olvidaste manejar un caso nulo o dejaste un bucle que nunca termina ante una entrada límite. Estos son los errores "obvios una vez que los ves", y un modelo los detecta al instante en todo un diff sin cansarse en el archivo número cuarenta.

También es una sólida compañera de legibilidad. La revisión con IA sugiere nombres de función más claros, señala un comentario que ya no coincide con el código que hay debajo y apunta dónde un condicional anidado podría simplificarse. Para equipos sin una guía de estilo formal —o sin la capacidad de aplicarla— esto eleva el nivel de la calidad del código de forma consistente y sin egos.

Luego está la capa explicativa, que es genuinamente nueva. Un buen revisor de IA puede resumir lo que hace un pull request en lenguaje sencillo, describir la intención detrás de un cambio desconocido y ayudar a un revisor sin contexto a orientarse rápido. Para ingenieros en onboarding y para revisiones entre equipos, ese contexto es valioso por sí solo.

Por último, es incansable e inmediata. Revisa a las 2 de la madrugada, revisa el PR número cien del sprint con la misma atención que el primero y nunca deja una revisión pendiente durante dos días por estar ocupada. Bien utilizada, la revisión con IA acorta el ciclo de retroalimentación y libera a los revisores humanos para dedicar su atención limitada a las cosas que realmente requieren criterio.

Nada de esto es trivial. El error es suponer que, porque la revisión con IA es buena en todo lo anterior, también es buena en seguridad. No lo es.

Dónde la revisión de código con IA es ciega

La brecha de seguridad no es una aspereza que se pulirá en el próximo lanzamiento de un modelo. Es estructural, y proviene de cómo funcionan estos sistemas.

Un revisor de IA razona sobre el texto de un diff. Ve las líneas que cambiaron y algo de contexto alrededor, y predice lo que diría un revisor experto. Lo que no tiene es un modelo fiable de toda tu aplicación: cada frontera de confianza, cada lugar por donde entra la entrada del usuario, cada comprobación de autorización que debería existir y la ruta completa que recorren los datos desde una solicitud HTTP hasta una consulta a la base de datos tres servicios más allá. Los errores de seguridad viven precisamente en ese panorama de todo el sistema, y ese panorama es en gran medida invisible en un único pull request.

Así que las categorías que la revisión con IA pasa por alto son las que más importan:

• Autorización rota. Un modelo que mira un nuevo endpoint no tiene forma fiable de saber que esta ruta en concreto debe comprobar si el usuario actual es dueño del registro que solicita. El código parece correcto. La comprobación ausente no está en el diff: su ausencia es el error, y las ausencias son exactamente lo que a la coincidencia de patrones le cuesta ver.
• Falta de codificación de salida. Si un valor necesita codificarse en HTML, escaparse para un shell o parametrizarse en una consulta depende de dónde termine. El revisor tendría que rastrear el valor a través de funciones y archivos para saberlo, y normalmente no lo hace.
• Inyección. La inyección de SQL, de comandos y de plantillas depende de que la entrada no confiable llegue a un sink sensible sin sanitización. Eso es una propiedad de flujo de datos que abarca toda la base de código, no algo local visible en las líneas modificadas.
• Problemas sutiles de flujo de datos. Datos sensibles registrados en el lugar equivocado, un secreto que fluye hacia un mensaje de error, una validación que ocurre después de que el valor ya se usó: estos requieren seguir los datos a través del sistema, que no es lo que hace un revisor limitado al diff.

Además de los puntos ciegos, hay dos problemas de fiabilidad. La revisión con IA produce falsos negativos: guarda silencio ante vulnerabilidades reales, que es el fallo peligroso, porque el silencio se interpreta como aprobación. También produce falsos positivos: advertencias seguras sobre problemas que no son reales, que entrenan a tu equipo a descartar sus comentarios y, con el tiempo, a pasar por alto el que importaba. La precisión reportada de la revisión de seguridad con IA varía mucho según el modelo, el prompt y la base de código; no hay un número estable en el que apoyarse, lo cual es, en sí mismo, la clave.

El riesgo más insidioso es humano, no técnico: el sesgo de automatización. Cuando un sistema fluido y seguro de sí mismo dice que un cambio se ve bien, los revisores se relajan. La marca de verificación verde se convierte en permiso para dejar de mirar. Así es como un error de autorización que un revisor de IA nunca estuvo equipado para detectar pasa la revisión con todos sintiendo que, de hecho, sí se revisó.

Revisión con IA vs SAST vs revisión humana: necesitas las tres

Es tentador plantearlas como competidoras y elegir una ganadora. No son competidoras. Fallan de maneras distintas, y esa es toda la razón para ejecutar las tres.

La revisión con IA es probabilística y consciente del contexto de forma superficial. Es amplia, rápida y buena en la superficie legible del código, y poco fiable y no determinista en seguridad. Ejecútala dos veces y puedes obtener comentarios distintos. Eso está bien para sugerencias y es fatal para garantías.

SAST y SCA son deterministas. El análisis estático rastrea el flujo de datos por tu código contra un conjunto definido de reglas y encuentra la ruta de inyección, el sink contaminado, la codificación ausente, de la misma forma cada vez, en cada ejecución, aparezcan o no las líneas relevantes en el diff de hoy. El análisis de composición de software hace el equivalente para tus dependencias, comparando las bibliotecas que incorporas con vulnerabilidades conocidas. Su fortaleza es exactamente la cobertura estructural, de todo el sistema y repetible de la que carece la revisión con IA. Su debilidad es que no entienden la intención y pueden ser ruidosos sin ajuste, que es donde entran los otros dos.

La revisión humana aporta lo que ninguna máquina tiene: la comprensión de lo que se supone que debe hacer el cambio y de si debería existir siquiera. Una persona sabe que esta funcionalidad maneja datos regulados, que esta refactorización toca la ruta de pago, que este cambio "pequeño" altera quién puede ver qué. Las personas son lentas, inconsistentes y fáciles de fatigar, que es precisamente por lo que quieres que las máquinas se encarguen del volumen para que las personas gasten su criterio donde cuenta.

Alinéalas y la lógica queda clara. La revisión con IA te da velocidad y amplitud. SAST y SCA te dan cobertura de seguridad determinista y repetible. Las personas te dan contexto e intención. Elimina cualquiera de ellas y tendrás un agujero predecible: sin revisión con IA, las revisiones se ralentizan; sin SAST, las vulnerabilidades estructurales pasan; sin personas, nadie es responsable de si el cambio tenía sentido. El objetivo no es elegir. Es secuenciarlas para que cada una haga aquello en lo que es mejor.

Un flujo de trabajo con gate en el PR que funciona

Aquí tienes una forma práctica de poner las tres en el orden correcto, en el pull request, donde el coste de detectar un problema es el más bajo.

1. La revisión con IA se ejecuta primero, en cada PR. Déjala hacer aquello en lo que es buena: estilo, legibilidad, errores obvios y un resumen en lenguaje sencillo del cambio. Trata su resultado como sugerencias útiles que agilizan al revisor humano, no como un gate de seguridad. Nada de lo que diga debería poder marcar un cambio como "seguro".
2. SAST y SCA se ejecutan como comprobaciones de estado obligatorias. Esta es tu capa de seguridad determinista, y debe bloquear el merge, no solo aconsejar. El análisis estático inspecciona el código modificado en busca de inyección, patrones de autenticación y autorización rotas y flujos de datos inseguros; el análisis de composición comprueba las dependencias nuevas y actualizadas contra vulnerabilidades conocidas. Por ser deterministas, te dan algo que la revisión con IA no puede: un resultado en el que puedes confiar y que puedes aplicar. Ajústalos para que la señal se mantenga alta y los desarrolladores confíen en el gate.
3. La aprobación humana es obligatoria para el merge. Una persona revisa el cambio con el resumen de la IA y los hallazgos de seguridad delante, y toma la decisión que necesita contexto: ¿es este el cambio correcto?, ¿pertenece a esta parte del sistema?, ¿coincide la intención con el diff? Que las comprobaciones de seguridad hayan pasado permite que la persona se concentre en el criterio en lugar de cazar sinks contaminados a mano.
4. Mantén el veredicto de la IA como consultivo y el gate de seguridad como bloqueante. Esta única regla evita que el sesgo de automatización desarme silenciosamente todo el pipeline. La revisión con IA informa. SAST/SCA y las personas deciden.

Este es el arreglo que te permite ir rápido sin fingir que rápido es lo mismo que seguro. La revisión con IA comprime el tiempo que las personas dedican a la superficie legible; las pruebas deterministas garantizan el suelo de seguridad; las personas son dueñas de la decisión.

Ese suelo de seguridad determinista es donde encaja Rainforest. La revisión con IA es una buena primera pasada, pero nunca se construyó para ser la capa que detecta la autorización rota, la inyección o los errores de flujo de datos que se convierten en incidentes. Rainforest es la capa de seguridad que se sitúa sobre tu flujo de trabajo asistido por IA: pruebas deterministas que se ejecutan en el pull request y dan a tus revisores algo en lo que de verdad pueden confiar antes de hacer clic en merge. Combina la velocidad de la revisión con IA con un gate de seguridad que no adivina, y obtienes lo mejor de ambos sin apostar la producción a una probabilidad.