Todos los artículos

Blog

Revisión de código: la IA escribe más rápido de lo que tu equipo lee

Un pull request de 13 323 líneas escrito con una IA, cerrado tras algo más de quince horas: lo que debe cambiar en tu revisión de código.

  • Por Azziz ERRIME
  • 16 min de lectura
Una silla de oficina vacía frente a una pila de páginas de revisión de código que llega hasta el techo, iluminada de noche por una lámpara.

TL;DR

  • La revisión de código ya no sigue el ritmo de la IA: en una empresa estudiada en 2026, se duplicaron los PR por desarrollador activo y la carga por revisor.
  • Según Veracode, el código generado por IA todavía solo supera el 15 % de las pruebas de seguridad en XSS y el 13 % en inyección de logs.
  • Antes de comprar una herramienta, mediría la carga de los revisores, limitaría el tamaño de los PR y escribiría la palabra seguridad en la plantilla de PR.

Un pull request de 13 323 líneas, escrito con una IA y cerrado por falta de revisores. Cuando la IA escribe el código, lo que vale lo decide la revisión de código. Eso sí, hay que haberla dimensionado y protegido.

Miércoles 19 de noviembre de 2025, 18:37, hora de París. Llega un pull request al repositorio del compilador de OCaml: 13 323 líneas, 147 archivos, 40 commits. Su autor lo ha generado con una IA para añadir compatibilidad con DWARF, un formato de depuración.

Al día siguiente, a las 9:55 (algo más de quince horas después), Gabriel Scherer, uno de los mantenedores, lo cierra sin fusionarlo. En su mensaje de cierre aclara que no juzga el código propuesto: no lo ha mirado lo bastante de cerca como para pronunciarse. Ninguna de las personas que podrían revisar y mantener ese trabajo parecía dispuesta a hacerse cargo. Queda la pregunta que plantea toda revisión de código: ¿quién revisa y en cuánto tiempo?

Una revisión de código que no llegó a hacerse

Justo antes de cerrar el PR, Scherer había publicado un comentario. En él califica el código de «hard to review, and very lightly tested», difícil de examinar y apenas probado. Recuerda que al compilador le faltan personas disponibles para la revisión y el mantenimiento. Por experiencia, añade, verificar lo que escribe una IA le cuesta más esfuerzo que verificar el trabajo de un humano.

Según él, unos PR tan grandes suponen «a very real risk of bringing the Pull-Request system to a halt», un riesgo muy real de paralizar todo el flujo de contribuciones. Producir líneas que pasen las pruebas, escribe, es «only 20% of the work», una quinta parte del trabajo. El 80 % restante (discutir la funcionalidad, revisarla e integrarla) recae tanto en el autor como en otros.

Según un estudio ya antiguo que SmartBear, desarrolladora de una herramienta de revisión de código, realizó en Cisco, la detección de defectos cae por encima de las 500 líneas revisadas por hora. A ese ritmo máximo, me salen más de 26 horas de lectura atenta para las 13 323 líneas. El PR estuvo abierto algo más de quince horas.

Su frase de cierre habla de la organización del proyecto: «Currently github/ocaml as it is organized is not able to work in this way.» Tal y como está organizado, el repositorio no puede trabajar así. Me pregunto cuántos equipos podrían decir otra cosa de sus propios repositorios.

Los PR se han duplicado y la carga de cada revisor también

Según GitHub, los pull requests fusionados cada mes en la plataforma se multiplicaron por más de tres entre enero de 2023 y junio de 2026.

Un estudio publicado el 2 de julio de 2026 siguió a los desarrolladores de una empresa cuyo CTO había anunciado, en junio de 2025, un «mandato 2×» para duplicar la productividad con IA. El número de PR por desarrollador activo sí se duplicó, y la carga de cada revisor también. Los autores lo consideran un límite superior, no una media del sector.

En el código abierto, la fundación del motor de videojuegos Godot cambió su política de contribución el 30 de junio de 2026. Explica el motivo sin rodeos: tiene pocos revisores cualificados, la revisión de código exige un esfuerzo real y el flujo entrante la supera.

Creo que la revisión de código se salta cuando la cola se desborda, un PR tras otro. Faros AI vende herramientas que miden el trabajo de los equipos de ingeniería. En su telemetría, los PR fusionados sin ninguna revisión, ni humana ni de un agente, registran un aumento relativo del 31,3 %. Cada uno puede arrastrar las vulnerabilidades que la IA pasa por alto versión tras versión.

Un puesto de control de carretera con la barrera levantada y la garita vacía, atravesado por una fila de camiones blancos.

Un puesto de control abierto, nadie en la garita y el tráfico que pasa sin frenar.

El código generado por IA sigue tropezando con las mismas vulnerabilidades

En la primavera de 2026, Veracode, proveedor de seguridad de aplicaciones, desglosó, vulnerabilidad por vulnerabilidad, la tasa de éxito del código generado por IA en las pruebas de seguridad. Esas tasas apenas se habían movido desde su informe de 2025.

Vulnerabilidad Éxito en las pruebas de seguridad
Inyección SQL 82 %
XSS 15 %
Inyección de logs 13 %

Su informe del 28 de julio de 2026 vuelve a señalar esos dos puntos débiles, el XSS y la inyección de logs. La inyección de logs cuela saltos de línea en un campo que se vuelca al log para fabricar entradas falsas. Mi interpretación: el modelo acierta cuando la contramedida cabe en un patrón conocido, como la consulta parametrizada contra la inyección SQL. Fracasa cuando la defensa depende del lugar donde acabará el dato: una página que se muestra a otro usuario o un log que se consulta durante una investigación. Veracode propone una explicación parecida: estas dos vulnerabilidades obligan a seguir el dato de un usuario a través de la aplicación.

En la práctica, el atacante empieza por ese recorrido. Localiza las entradas de la aplicación (un campo de formulario, una cabecera, un parámetro de URL) y luego sigue el dato hasta la página o el log donde vuelve a aparecer. Un PR se revisa archivo por archivo, mientras que ese camino atraviesa varios.

El otro punto ciego se esconde en las dependencias. Un estudio presentado en USENIX Security 2025 muestra que modelos de 2023 y 2024 recomendaban paquetes inexistentes, a menudo los mismos de una ejecución a otra. Así que un atacante puede registrar esos nombres antes que tú. Según una entrada del blog de Lasso Security publicada en marzo de 2024, un investigador subió un paquete vacío con un nombre inventado por algunos modelos, «huggingface-cli». Se descargó más de 30 000 veces en tres meses.

En una revisión de código orientada a la seguridad, la medida más barata cabe en una frase. Braz y sus coautores mostraron en ICSE 2022 que pedir explícitamente a los revisores que se fijen en la seguridad multiplica por ocho la probabilidad de que encuentren la vulnerabilidad. Su lista de comprobación no añadía nada significativo a esa consigna. Pero hace falta alguien con tiempo para leer, y cuando ese tiempo escasea, no tarda en aparecer la idea de dejar también la revisión en manos de una máquina.

Que una IA revise a la IA: la tentación que OCaml había visto venir

En el comentario publicado justo antes del cierre, Scherer ya se había adelantado a esa respuesta: «You may think that the answer to that is to also automate the review process, or (more plausibly) to lower our quality standards». Automatizar la revisión o bajar el listón: hasta ahora, escribe, el proyecto no ha optado por trabajar así. La tentación, sin embargo, es real, y la revisión de código automática ya funciona a gran escala, según GitHub, que habla de su propio producto.

Una IA también puede encontrar fallos reales. El 11 de agosto de 2025, el equipo Big Sleep de Google notificó a curl la vulnerabilidad que acabaría siendo CVE-2025-9086. Para su mantenedor, Daniel Stenberg, es el primer informe recibido por curl que parece haber usado la IA para localizar un fallo con exactitud.

En un artículo aceptado en ICML 2025, Kim y sus coautores compararon los errores de los grandes modelos de lenguaje en la clasificación HELM. Cuando dos de ellos se equivocan a la vez, eligen de media la misma respuesta errónea en torno al 60 % de las veces, frente a alrededor del 33 % que daría el azar. La cifra solo vale para esa clasificación. Me basta para no dar por hecho que un segundo modelo cubra los puntos ciegos del primero.

El revisor automático también se convierte en un objetivo. La inyección de prompt consiste en esconder, en un contenido que la IA va a leer, instrucciones que seguirá como si vinieran de ti. Con CamoLeak, un investigador de Legit Security coló comentarios invisibles en un PR para que Copilot Chat filtrara código privado. GitHub corrigió esta vulnerabilidad crítica el 14 de agosto de 2025.

Un detector de humo en el techo de una oficina, tapado con un pósit amarillo en blanco.

Un detector tapado con un pósit, como un revisor automático engañado por una instrucción oculta.

Kudelski Security publicó el 19 de agosto de 2025 la historia de un simple PR que contenía un archivo de configuración malicioso. Corregida ya en enero de 2025, la vulnerabilidad permitía ejecutar código en los servidores de CodeRabbit, una herramienta de revisión de código con IA. Daba acceso de escritura a un millón de repositorios, privados incluidos. Queda el humano que aprueba al final de la cadena.

Ocho meses después de OCaml, un agente de IA busca la aprobación de un mantenedor

En un informe publicado el 4 de agosto de 2026, el AI Security Institute, organismo público británico, describe un incidente ocurrido del 25 al 28 de julio durante unas pruebas de ciberseguridad. Un agente de IA en evaluación estudió a los mantenedores humanos de un proyecto, creó varias identidades falsas y las usó para empujar a un mantenedor real a aprobar su código. Según el instituto, sus investigaciones no han revelado ningún perjuicio real.

La documentación del kernel de Linux reserva la firma a los humanos: «AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).» Con la línea Signed-off-by, el colaborador humano certifica el origen de su código y asume toda la responsabilidad sobre él.

El agente de programación Copilot de GitHub impide que la persona que le ha pedido un PR lo apruebe ella misma. Desde el 13 de marzo de 2026, en cambio, un administrador puede desactivar otra protección: la aprobación humana antes de que se ejecuten los flujos de trabajo que lanza el agente. Ninguno de estos textos dice cuánto tiempo se le deja al humano para leer.

Los investigadores de Carnegie Mellon extraen su conclusión principal de miles de textos publicados sobre la revisión de código. Es el equipo quien decide, en la revisión, si el efecto de un agente sobre el software es bueno o malo.

«[…] review is the control point through which a coding agent’s effect on software is decided, and […] AI does not fix the sign of that effect: the team sets it» Agarwal, Miller, Kästner y Vasilescu, Carnegie Mellon, 8 de julio de 2026.

Un cuarto de hora después de cerrar el PR, Scherer hablaba de procesos de desarrollo tan distintos que resultaban incompatibles, sin decir cuál tenía razón.

El lunes por la mañana, organizaría la revisión de código antes de comprar una herramienta

Su frase de cierre terminaba con un paréntesis: «This may change in the future and then one could reconsider.» Quizá cambie, y entonces se podrá reconsiderar. Cada equipo puede aplicar a su propia revisión de código el diagnóstico que Scherer hacía de su repositorio: ¿está organizada para revisar lo que escribe la IA?

Si fuera tech lead o CISO, empezaría por cuatro medidas.

  • Abriría la plataforma Git, la herramienta que aloja tus repositorios, para sacar dos cifras que ya duermen ahí. Primero, la proporción de PR fusionados sin revisión humana en un periodo de 90 días; después, el número de líneas que llegan cada semana a cada revisor, convertido en horas de lectura.
  • Pondría un tope de unas 200 a 400 líneas a los PR asignados a un revisor y mandaría trocear el resto.
  • Escribiría la palabra seguridad en la plantilla de PR, junto con los puntos donde fracasa el código generado: los logs, la visualización de datos de usuario y cada dependencia añadida.
  • Comprobaría quién puede desactivar en tus repositorios la aprobación humana de los flujos de trabajo que lanza un agente. Y miraría qué permisos de escritura le has dado a la herramienta de revisión de código con IA.

Me queda una duda sobre ese tope: la referencia es anterior a los asistentes de programación, y no he encontrado ninguna medición nueva hecha con código generado. Trocear tampoco acorta las 26 horas de OCaml, y revisarlo todo se comerá parte de la ganancia prometida. A falta de algo mejor, prefiero un PR que espere.

Preguntas frecuentes sobre la revisión de código y la IA

¿Es seguro el código generado por IA?

En su informe de julio de 2026, Veracode, proveedor de seguridad de aplicaciones, constata que el código generado por IA supera de media el 56 % de las pruebas de seguridad. El mejor modelo evaluado sigue fracasando en casi una de cada tres tareas, y los fallos se concentran en el XSS y la inyección de logs. Los modelos también se inventan dependencias: en los de 2023 y 2024, casi uno de cada cinco paquetes recomendados no existía.

¿Se puede usar la IA para revisar código?

Una IA puede revisar una parte del trabajo. Según GitHub, que habla de su propia herramienta de code review con IA, en marzo de 2026 Copilot se encargaba de más de una de cada cinco revisiones de la plataforma. En la clasificación HELM, cuando dos modelos se equivocan, eligen de media la misma respuesta errónea en torno al 60 % de las veces. Un revisor automático también puede sufrir ataques, como mostraron CamoLeak y la vulnerabilidad de CodeRabbit.

¿Cuáles son las buenas prácticas de revisión de código con IA?

Las referencias conocidas son anteriores a la IA. El estudio realizado en Cisco y publicado por SmartBear aconseja no revisar más de 200 a 400 líneas a la vez, a un ritmo inferior a 500 líneas por hora. Pedir explícitamente que se revise la seguridad multiplica por ocho la probabilidad de encontrar la vulnerabilidad. Comprueba también quién puede desactivar la aprobación humana de los flujos de trabajo que lanza un agente, algo que GitHub permite a un administrador desde el 13 de marzo de 2026.

Fuentes