¿Puede un agente de IA revisar el código de otro agente de IA?

Respuesta corta: puede, y encuentra defectos reales, pero la condición que lo hace funcionar no es la marca del modelo. Son otras tres cosas: el agente revisor tiene que correr en una instancia separada, sin nada del contexto de quien escribió, hay que mandarle cazar un defecto nuevo en vez de confirmar que los viejos ya no están, y una persona sigue siendo dueña del merge. En nuestra propia pipeline de contenido, entre el 12 y el 14 de agosto de 2026, seis artículos técnicos pasaron por un agente revisor de contexto cero y los seis fueron rechazados al menos una vez antes de pasar, a lo largo de 14 rondas de revisión. Ese es nuestro número para revisar artículos que llevan comandos ejecutables, no para pull requests contra código de producción, y la diferencia importa.

¿Por qué la prueba que escribió el agente de IA pasa con el comportamiento equivocado?

Porque el mismo agente que escribió el código escribió la prueba, y una prueba escrita después de la implementación tiende a afirmar lo que la implementación ya hace. Se pone verde con el comportamiento equivocado, y solo se pone roja el día en que intentas arreglar el defecto. Este es el ejemplo honesto más pequeño que pudimos construir, una allowlist de rutas del tipo que un agente de IA de programación necesita cuando le dices en qué directorios puede tocar:

def is_allowed(path, allowed_root):
    """Return True when path is inside allowed_root."""
    return path.startswith(allowed_root)

Y la prueba que vino con él, en la biblioteca estándar de Python, así que no hay nada que instalar:

import unittest
from allowlist import is_allowed

ROOT = "/home/dev/project"

class TestAllowlist(unittest.TestCase):
    def test_file_inside_the_project_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/main.py", ROOT))

    def test_nested_file_is_allowed(self):
        self.assertTrue(is_allowed(ROOT + "/src/deep/util.py", ROOT))

    def test_unrelated_path_is_rejected(self):
        self.assertFalse(is_allowed("/etc/passwd", ROOT))

Ejecútala con python3 -m unittest -v e imprime, en Python 3.14.3, con el tiempo transcurrido dependiendo de tu máquina:

Ran 3 tests in 0.000s

OK

Tres pruebas pasando, y la función está rota. Dos preguntas que la prueba nunca hace:

/home/dev/project-secrets/.env   -> True
/home/dev/project/../other/.env  -> True

Un directorio vecino, cuyo nombre apenas empieza con la misma cadena, está dentro de la allowlist, y también lo está todo lo que se alcanza saliendo por ... La suite verde no es evidencia. Es la opinión del autor, repetida por una máquina.

¿El agente de IA revisor tiene que ser de otra empresa?

Nosotros decíamos que sí, y estamos estrechando esa afirmación. Nuestro artículo anterior sobre cómo revisar código escrito por varios agentes de IA dice que vale que un agente revise a otro con una condición, que sea de otra empresa. Lo que de verdad podemos defender es más débil y más útil: lo que observamos es el efecto de una instancia separada, con contexto limpio e instrucción adversarial. Nunca corrimos la comparación controlada que aislaría la marca, mismo modelo con contexto limpio contra otro modelo con contexto limpio, así que no podemos decir cuánto del beneficio pertenece a la diferencia de proveedor.

El mercado está discutiendo exactamente esto. En el hilo Reviewing AI code has quietly made me the slowest part of my own team, publicado en r/cursor el 11 de agosto de 2026 (post 1vllfe1, 25 comentarios declarados, 20 con cuerpo en la página que leímos), un comentarista describe la falla con todas las letras, que el mismo modelo escribiendo código y pruebas produce una prueba que afirma lo que el código ya hace, y otro responde que el proveedor es irrelevante porque los modelos no tienen ego, y que lo que importa es una instancia separada, sin contaminación de contexto, corriendo bajo instrucciones ajustadas para ser adversariales. Las dos posiciones se sostienen, y ninguno de los dos lados de ese hilo corrió una prueba controlada. Trata la cuestión del proveedor como abierta.

¿Qué hace que un segundo agente de IA discrepe de verdad del primero?

Tres cosas, en el orden que importa. La primera es el contexto. Un agente que tiene la conversación del autor en su ventana hereda las suposiciones del autor, incluida la equivocada que produjo el defecto. Una instancia nueva, que recibe solo el diff y el requisito, no le debe lealtad a nada, y eso es justo lo que busca el ejercicio.

La segunda es la instrucción. Pedirle a un agente que compruebe si el código está bien produce acuerdo, porque el código fluido se lee como correcto. Pedirle que encuentre una clase concreta de defecto produce hallazgos. La instrucción que usamos nombra las clases: algo que el cambio tocó y no debería, una prueba que seguiría pasando si la implementación estuviera mal, y una suposición hecha sin decirse.

La tercera es qué le mandas hacer en la segunda ronda, y es la que más gente falla. Después de una corrección, la instrucción natural es confirmar que los defectos reportados ya no están. Esa instrucción es casi inútil, porque apunta al revisor justamente hacia la parte del código que acaba de recibir toda la atención. Mandar al revisor a buscar un defecto nuevo fue lo que atrapó, en nuestra propia pipeline, tres rondas seguidas en las que la corrección fue la que introdujo el problema siguiente.

¿Qué atrapa de verdad un agente de IA revisor, medido en nuestra pipeline?

Nuestra pipeline de contenido publica artículos técnicos que contienen comandos, y cada artículo pasa por un agente revisor que no escribió el texto, corre con contexto vacío y recibe la instrucción de ejecutar los comandos publicados en vez de creerles. Contando las últimas 100 entradas de nuestro diario de automatización, una ventana que cubre los dos días hasta el 14 de agosto de 2026, seis artículos llegaron a esa puerta. Consumieron 14 rondas de revisión: 8 rechazos y 6 aprobaciones. Cada uno de los seis fue rechazado al menos una vez, y uno de ellos necesitó cuatro rondas.

Los defectos no eran de estilo, y estos tres los encontró el agente revisor, no nosotros. Un conteo de comentarios leído del elemento equivocado de una página HTML, que reportó un hilo con 68 comentarios cuando el hilo tiene 15, porque el número pertenecía a otro post de la misma página. Una cita que perdió una sola palabra, convirtiendo ninguna regla de bloqueo blanda en ninguna regla de bloqueo, lo que borró en silencio una clase entera de regla de una fuente citada. Y un comando publicado que no hacía lo que el párrafo a su alrededor afirmaba, sin filtrar nada mientras el texto decía que excluía archivos binarios. Es el tipo de cosa que una lectura fluida nunca atrapa y una máquina instruida para verificar sí.

Di los límites de ese número con honestidad, porque son reales. Es una pipeline, una ventana de dos días, y el artefacto revisado es un artículo técnico que carga comandos ejecutables, no un pull request contra código de producción. Muestra que un agente revisor de contexto cero encuentra, a una tasa alta, defectos que el autor no vio. No muestra que la misma tasa valga para código de aplicación, y eso no lo medimos.

¿Qué no puede atrapar un revisor de IA?

La intención, y la ausencia. Un agente de IA revisor lee lo que el diff contiene, así que puede juzgar si el código hace lo que el código dice. No puede decirte que la funcionalidad resuelve el problema equivocado, que el requisito se leyó mal, o que un caso que debería existir simplemente no está. La ausencia no tiene número de línea, y los agentes revisores están anclados a líneas.

También es mal juez de la consecuencia. Un agente revisor señala una comprobación de nulo que falta y un redondeo de moneda equivocado con el mismo tono, y solo una persona que conoce el producto sabe que uno de los dos es cosmético y el otro es dinero. Por eso el merge sigue siendo humano incluso cuando la lectura se delega: aprobar es un acto de responsabilidad, y la responsabilidad no se transfiere a un proceso que puedes volver a ejecutar.

El reparto realista es que la máquina lee primero y la persona decide. Estrecha el diff que tienes que leer con cuidado, lo que vale muchísimo en un día en que los agentes entregaron más de lo que una persona lee. No acorta la parte en la que alguien tiene que entender lo que se integró.

¿Cómo montar una revisión adversarial para código de agente de IA?

Cuatro reglas, cada una el arreglo de un fallo que sufrimos. Empieza una sesión nueva, sin nada de la conversación de escritura dentro. Dale el diff y el requisito, no la historia de cómo llegó ahí el código, porque la historia es donde la suposición equivocada resulta más convincente. Nombra las clases de defecto a cazar: qué cambió y no debería, una prueba que pasaría con la implementación vacía, una suposición nunca dicha, y un número o una cita que no coincide con su fuente. Exígele que ejecute lo que se pueda ejecutar, ya que un comando que nadie corrió es una afirmación, y una afirmación es lo que estabas intentando verificar.

En la ronda siguiente a una corrección, cambia la instrucción en vez de repetirla: dile al revisor que los defectos reportados ya están corregidos, que no gaste tiempo en ellos, y que su trabajo es encontrar un defecto que antes no estaba. En nuestra pipeline, ese solo cambio es lo que convirtió la segunda y la tercera ronda de formalidad en las rondas que encontraron los problemas más peligrosos.

¿Basta un revisor de IA para aprobar sin leer?

No, y el argumento a favor es más débil de lo que parece. Lo que se dice es que generar es barato, probar es barato, y lo que se mide son resultados, así que una suite verde más una revisión de agente deberían bastar. La allowlist de arriba es el contraejemplo: tres pruebas verdes y una función explotable. Pon un agente revisor con el contexto del autor y estará de acuerdo con el autor. Pon uno con contexto limpio e instrucción adversarial y tiene una posibilidad real de preguntar por qué la comprobación es startswith, que es la pregunta que arregla el defecto.

Lo que cambia con una buena revisión por agente es el orden de tu atención, no la necesidad de ella. Lees un diff que ya fue sondeado, así que gastas tu lectura donde la máquina no pudo ir: en si aquello era lo correcto que construir. Es la parte que nadie automatizó, y también la parte que siempre fue la cara.

En qué se basa esto, y qué no demuestra

Los números de rondas de revisión son nuestros, tomados de nuestro diario de automatización el 14 de agosto de 2026, cubriendo una ventana de dos días y seis entregas, en artículos técnicos con comandos ejecutables y no en pull requests de producción. El ejemplo de la allowlist se escribió para este artículo y se ejecutó en Python 3.14.3 en macOS; la salida mostrada es transcripción de esa ejecución. Las posiciones del mercado vienen de un hilo público de r/cursor fechado el 11 de agosto de 2026, que leímos por la página y no por la API, y que dos de sus propios comentaristas llaman escrito por IA, uno de ellos añadiendo que es caza de interacción, salvedad que transmitimos en vez de esconder.

Lo que nada de esto resuelve es la cuestión del proveedor. Si un agente revisor de otra empresa le gana al mismo modelo corriendo con contexto limpio es una comparación que no hicimos, y mientras nadie la haga, una respuesta en cualquier dirección es una preferencia vestida de hallazgo.