¿Cómo se revisa el código generado por IA?

Los agentes de programación generan más código y la revisión tarda más

Estas cuatro cifras salen de un solo estudio. Dos investigadores de la Universidad de Harvard siguieron a 718 empresas de enero de 2021 a marzo de 2026 con los datos de una plataforma de analítica de ingeniería (versión de agosto de 2026 del estudio). Un agente de programación es una herramienta que recibe una tarea, escribe código en varios archivos, ejecuta los tests y repite hasta terminar el trabajo. En las empresas que adoptaron estas herramientas, las líneas de código añadidas subieron un 30 %, los commits un 20 % y los pull requests un 23 %.

El trabajo terminado no creció al mismo ritmo: el aumento de tareas cerradas es pequeño y no es estadísticamente significativo. El mismo estudio explica la diferencia. El tiempo que pasa desde que se abre un pull request hasta que se hace merge aumentó un 49 %, la proporción de pull requests a los que se les piden cambios casi se duplicó y los comentarios de revisión por pull request subieron un 35 %. La conclusión de los autores: el cuello de botella es la revisión de código.

Otras mediciones apuntan al mismo sitio. En el informe de 2026 de LinearB (más de 8,1 millones de pull requests), los pull requests generados por IA esperan 4,6 veces más antes de que empiece su revisión, y cuando alguien los toma se revisan el doble de rápido. En la encuesta de Sonar a más de 1.100 desarrolladores, el 96 % no confía del todo en que el código generado por IA sea correcto; los que dicen comprobarlo siempre antes de hacer commit son el 48 %.

Nosotros hacemos diffox, una herramienta que revisa pull requests. La lista de abajo sale de ese trabajo y de las reglas de nuestro propio repositorio, y se puede aplicar a mano, sin ninguna herramienta.

El código generado por IA suena igual de seguro en cada línea

Cuando revisas el código de un compañero, conoces a quien lo escribió: intuyes qué domina y dónde fue con prisa, y le preguntas lo que no tienes claro. Cuando el autor es un modelo de lenguaje, no tienes nada de eso.

El estudio que JetBrains Research publicó en octubre de 2026 describe así el problema. El modelo presenta cada línea que genera con la misma seguridad; ninguna señal te dice que la lógica de autenticación era fácil y la migración de la base de datos, difícil. Leer cada línea no escala a medida que crecen los cambios que generan los agentes. Para los investigadores, el problema no es leer el diff, sino calibrar la confianza: repartir el esfuerzo de revisión en proporción al riesgo de cada parte. El estudio se basa en cuatro talleres con 17 profesionales y en una encuesta a 43 desarrolladores.

Las señales de alarma de siempre tampoco funcionan. En el código que escribe una persona, una función desordenada o un comentario a medias te dicen «ojo aquí». El código generado por IA suele compilar, tiene nombres correctos y viene con su comentario y su test. En la encuesta de Sonar, el 53 % de los desarrolladores cita justo eso entre los efectos negativos de la IA en la deuda técnica: código que parece correcto pero no es fiable.

¿Cómo debe ser una lista de comprobación para revisar código?

La lista propone un orden. Las dos primeras preguntas se empiezan a responder antes de entrar en el código y te dicen dónde mirar; la tercera pone a prueba la evidencia; las dos últimas piden una lectura aparte cada una. El estudio de JetBrains propone el mismo recorrido: primero la visión general, luego los archivos y al final las líneas.

Lista elaborada para este artículo. Se basa en la guía «Review AI-generated code» de GitHub, en la guía de revisión de código de Google y en las reglas que aplicamos en nuestro propio repositorio.

Lee la descripción, los comentarios y la lista de archivos antes que el código

Para la primera pregunta, lee la descripción del pull request como una lista de afirmaciones. Si dice «reintenta tres veces la petición que falla», busca los tres intentos en el diff. Lee los comentarios de la misma forma: puede que un comentario cuente lo que el código debería hacer y no lo que hace. Un ejemplo:

def fetch_prices(symbols):
    """Obtiene los precios; si hay un error de red, reintenta tres veces."""
    try:
        return client.get_prices(symbols)
    except Exception:
        return []

Esta función compila y pasa el test que prueba el caso en que todo va bien. Tiene dos problemas. El docstring habla de tres intentos y el código lo intenta una sola vez. Además, el error se traga: aunque el servicio esté caído, quien llama recibe una lista vacía y la interpreta como «no hay precios».

Para la segunda pregunta, mira la lista de archivos antes de entrar en el código. Si la tarea es añadir un campo a un endpoint, la descripción tiene que explicar por qué cambió un módulo que no tiene nada que ver. Después lee las líneas borradas: una línea añadida llama la atención; una validación o una línea de log que desaparece, no. Por cada comportamiento que se borra, busca si queda algún sitio que todavía dependa de él.

La tercera comprobación es el camino que sigue el error. La regla que mantenemos en nuestro repositorio es esta: el error que se captura tiene que llegar a quien hizo la llamada. Un except demasiado amplio, un camino alternativo que devuelve un valor por defecto o un valor de retorno que nadie mira no arreglan el error; lo vuelven invisible.

Que un test pase no significa que pruebe algo

Un agente de programación ejecuta los tests por su cuenta y repite hasta que pasan. Por eso, en el pull request de un agente, «los tests pasan» es el punto de partida, no una evidencia por sí sola. La guía de revisión de código de Google hace la misma pregunta: ¿fallarán de verdad los tests cuando el código se rompa? Un ejemplo:

def test_discount_is_applied():
    order = make_order(total=100)
    apply_discount(order, code="WELCOME10")
    assert order is not None

Este test pasa aunque el descuento no se aplique nunca. Su nombre habla del descuento; su aserción solo comprueba que el pedido existe. Se arregla con una línea: assert order.total == 90.

La primera comprobación se llama verificación por mutación: deshaces la corrección y ves que el test falla. En la segunda ayuda una distinción: buscar no es comprobar. Un test que dice «el mensaje de error no está en la salida» también pasa si el mensaje no se genera nunca; necesita un contraejemplo que demuestre que la búsqueda sí puede encontrar el mensaje.

Los datos de prueba forman parte del mismo problema. Un ejemplo inventado a mano pone a prueba cómo se imagina el autor los datos. Saca el ejemplo de un registro real o compáralo con uno.

La seguridad se revisa aparte, aunque el código compile

Según el informe de julio de 2026 de Veracode, el código generado sin indicaciones de seguridad casi siempre compila, pero pasa las pruebas de seguridad de media un 56 % de las veces en más de 100 modelos. La tasa cambia según el lenguaje: un 63 % en Python y un 30 % en Java. El informe prueba los modelos tal cual, no un agente con herramientas, protecciones o revisión humana a su alrededor. Aun así, la conclusión está clara: la seguridad pide una lectura aparte.

En esa lectura, mira tres sitios. ¿La entrada que llega de fuera alcanza sin filtrar una consulta, un comando de shell o una ruta de archivo? ¿El nuevo endpoint lleva el mismo control de autorización que los de al lado, y hay algún secreto escrito en el código o en los logs? Por último, abre una por una cada dependencia nueva.

Un estudio aceptado en USENIX Security 2025 analizó 576.000 muestras de código generadas con 16 modelos y encontró que, de media, al menos el 5,2 % de los paquetes que sugerían los modelos comerciales y el 21,7 % de los que sugerían los modelos de código abierto no existían. Por eso la guía de GitHub recomienda comprobar si la dependencia sugerida existe, si se sigue manteniendo y qué licencia tiene.

Compara el cambio con las reglas escritas del repositorio

La quinta pregunta no busca saber si el código es correcto, sino si encaja en este repositorio. Si tus reglas están escritas en un archivo (AGENTS.md, CLAUDE.md o CONTRIBUTING.md), tenlo abierto durante la revisión y lee el cambio comparándolo con él.

De las otras dos comprobaciones, la primera es la duplicación: puede que se haya escrito una función auxiliar nueva cuando en el repositorio ya había una que hacía lo mismo. En la encuesta de Sonar, el 40 % de los desarrolladores también cita el código innecesario y duplicado entre los efectos negativos. Cuando veas una función auxiliar nueva, busca en el repositorio si ya existe.

La segunda es que las dos mitades de una operación salgan del mismo valor. Si una función comprueba la validez con una lista y opera con otra, o lee la hora dos veces en dos sitios distintos, cada mitad parece correcta por separado; el error está en la relación entre ellas. Nuestra regla: el valor se resuelve una vez y se les pasa a las dos mitades.

La lista se puede aplicar con pull requests pequeños y atención según el riesgo

Aplicar quince comprobaciones a un pull request de mil líneas es difícil. La guía de Google considera razonable un cambio de unas 100 líneas y, a menudo, demasiado grande uno de 1.000, y le da a quien revisa el derecho a rechazar un cambio solo por su tamaño. El estudio de Harvard no encontró ningún cambio significativo en el tamaño de los pull requests después de la llegada de los agentes de programación; la media de partida era de unas 1.168 líneas añadidas por pull request. Pedirle al agente pull requests pequeños, que hagan una sola cosa, es el primer paso de la revisión.

Incluso en un pull request pequeño, no todos los archivos piden la misma atención. El orden que propone el estudio de JetBrains es clasificar los archivos por riesgo antes de leer una sola línea.

Una parte de la lista se puede dejar en manos de una herramienta, y otra no:

• Déjaselo a la herramienta. La compilación, los tests, el linter, el análisis estático, la búsqueda de secretos y la revisión de dependencias y licencias.
• Que la herramienta avise y tú decidas. La contradicción entre un comentario y el código, el error que se traga, el test vacío, la línea que va contra el archivo de reglas. Si lo que encontró es de verdad un error lo decide quien conoce el contexto.
• Que siga siendo cosa tuya. Si el cambio resuelve el problema correcto, si el diseño encaja en el repositorio y la decisión de hacer merge.

diffox está en el segundo de estos tres escalones. Pone a leer el pull request a agentes especializados que buscan una sola cosa cada uno; cuatro puntos de la lista aparecen en los comentarios con el nombre de cuatro agentes: Broken Promise Agent para el comentario que dice algo que el código no hace, Silent Failure Agent para el error que se traga, Empty Test Agent para el test que pasa haga lo que haga el código y House Rules Agent para la línea que va contra tu archivo de reglas. diffox no bloquea el merge; hacer merge o no lo decide tu equipo (cómo funciona, en otro artículo).