Cuando la IA tiene que grabar su propia revisión

Cuando se abre una pull request, ya sea mía o la de un compañero que me han pedido revisar, estas son las líneas que le pego al agente:

Ahora vamos a revisar esta: [añade el enlace de GitHub de la PR]

Pero quiero que la ejecutes en local E2E y veas si todo va bien, y que hagas grabaciones con Playwright. Quiero también que la ataques, que intentes romperla Y que la pruebes a fondo [añade aquí más contexto si hace falta, por ejemplo, tanto en el ámbito personal como en el de organización].

Luego lo dejo trabajar: ejecuta el cambio en mi máquina, de principio a fin, con Playwright grabando el navegador sobre la marcha. Playwright es una biblioteca de automatización de navegadores que el agente puede manejar, y puede grabar las páginas que abre. Lo que el agente me devuelve es un informe escrito, acompañado de las grabaciones y de capturas de los momentos que señala.

Han cambiado muchas cosas desde que escribí en julio sobre revisar a ojo el código de IA, entre ellas cómo reviso las pull requests. Esta forma de revisar me ha impresionado últimamente, y creo que a la mayoría de los desarrolladores les sorprendería lo buena que se ha vuelto.

Lo que dije en julio y lo que ha cambiado

Lo que defendía entonces era que, cuando el agente ejecuta el código por ti, la revisión no desaparece. Se traslada a la evidencia, y el remedio que proponía era abrir tú mismo los logs y encontrar lo que el agente decía que había allí.

Ese remedio sigue funcionando, pero la mayoría de las veces ya no me hace falta. En julio también decía que la revisión lenta consistía en ejecutarlo, rastrearlo e intentar romperlo, y en hacer que el agente mostrara su trabajo. Lo nuevo es una forma de pedir todo eso en un solo mensaje y recibir el trabajo de vuelta en un formato que puedo comprobar sin rehacerlo. El agente hace la ejecución, y las grabaciones me enseñan lo que pasó en la pantalla.

Los modelos tienden a la respuesta más rápida. Si les preguntas si un cambio funciona, prefieren decir que sí antes que ir a comprobarlo, y en ocasiones he visto a uno describir logs que no existían. Una respuesta que suena a trabajo terminado es el camino más corto hasta el final del turno.

No es solo mi experiencia. La system card que Anthropic publicó para Claude Opus 4.8 recoge fallos del propio uso interno de la empresa, y uno de ellos encaja casi exactamente con mi caso. El modelo dijo que estaba vigilando las pull requests de un investigador cuando no era así. La misma lista recoge que aseguró haber hecho una verificación que no había hecho.

Decirle a un modelo que tenga más cuidado es una petición, y una petición es lo que se salta cuando va con prisa. Una grabación cambia lo que el modelo tiene que entregar.

Por qué una grabación es más difícil de falsear

Una frase sobre lo que pasó se puede escribir sin que pase nada. Una grabación necesita que algo se haya ejecutado de verdad, y lo que se ejecutó queda en pantalla para que yo lo juzgue.

Cuando el agente tiene que grabarse ejecutando el cambio, la forma más barata de cumplir lo que se le pide es ejecutarlo. En todo lo que sale en cámara, ya no queda un hueco donde un párrafo seguro de sí mismo pueda ocupar el lugar del trabajo. Por sí solo, un informe es el único relato de lo que pasó, y no puedo distinguir una prueba de una frase sobre una prueba salvo rehaciéndola yo mismo. La grabación separa la frase del hecho. Si el agente dice que probó el formulario vacío, el formulario vacío sale en el vídeo o no sale. Todo lo que el informe cuenta y nunca llegó a la cámara vuelve a ser una afirmación.

La grabación muestra lo que intentó, y lo que deja fuera marca aquello de lo que no tengo evidencia: la pantalla que nunca abrió, el formulario que nunca envió con datos incorrectos, la segunda cuenta en la que nunca inició sesión.

Hay un segundo efecto, igual de importante. Delante de la cámara, hacer como si un problema no hubiera pasado, o inventarse uno, deja de ser un atajo seguro para el agente, porque el vídeo está ahí para comprobarlo. Así que, cuando encuentra uno, me lo señala en lugar de enterrarlo en el resumen.

Rara vez necesito ver un vídeo entero para que todo esto funcione. La mayor parte del efecto ocurre antes de que abra nada, porque pedir la grabación es lo que obliga al agente a ejecutar el cambio. Lo que sí miro son las capturas de los momentos que importan, y eso incluye los éxitos. Me gusta ver el flujo terminar como debe, en cada ámbito que pedí, tanto como el error en pantalla o una página que se abrió para una cuenta que nunca debería haber llegado a ella. El vídeo queda detrás de ellas para cuando una captura plantee una duda.

El informe se convierte en un índice de la evidencia, un papel que le va mejor a un resumen que el de sustituirla. Sigo preguntándome "¿esto es verdad?", pero ahora lo responde una captura, o en el peor de los casos un fragmento corto de vídeo, y dedico más tiempo a "¿esto importa?".

Cuando importa lo que respondió el servidor, merece la pena pedir la traza de Playwright junto al vídeo. El vídeo son los píxeles. Una traza guarda, para cada acción, una instantánea de la página antes y después, con las peticiones de red, los cuerpos de sus respuestas y la consola del navegador. Si el agente dice que el servidor respondió con un 403, la traza tiene la respuesta.

El Playwright MCP de Microsoft, una de las herramientas que permiten a un agente manejar un navegador, trabaja a través del árbol de accesibilidad de la página, una vista de texto estructurada, y no a través de píxeles. La grabación es para mí, y por eso es útil: el agente actúa sobre una vista de texto de la página, y la grabación me enseña los píxeles que él no estaba mirando, sin nada de su narración por encima. Aun así, puede elegir qué toma me entrega, o repetir un flujo hasta que salga en verde, así que merece la pena pedirle todas las grabaciones que hizo, tomas fallidas incluidas.

Atácala y pruébala

El prompt pide dos cosas que tiran en direcciones distintas, y lo hace a propósito.

Un modelo al que le pides que confirme tiende a confirmar. Pedirle que "vea si todo va bien" lo invita a buscar lo que va bien, así que recorre el camino para el que se construyó la funcionalidad, ve la pantalla esperada e informa de que todo funciona. Merece la pena tener esa ejecución grabada, porque un resultado en verde sin evidencia detrás es justo la afirmación de la que avisaba en julio. Pero solo cubre el caso que el autor ya tenía en mente.

Pídele que lo rompa y tendrá que buscar en otra parte: un campo obligatorio vacío, el botón de enviar pulsado dos veces, la misma página abierta en dos pestañas, el ID de la barra de direcciones cambiado por uno que pertenece a otra persona, el botón de atrás pulsado a mitad de un flujo. Los bugs suelen esconderse en sitios así.

Un agente al que solo le dices que rompa cosas tiene el problema contrario. Puede pasarse toda la sesión con un caso límite ingenioso y no llegar a confirmar nunca que el flujo normal, el que recorre cualquier usuario, sigue funcionando de principio a fin. Quiero el recorrido por el flujo normal y el asalto contra él en la misma ejecución, y por eso la Y va en mayúscula.

Las dos instrucciones también funcionan mejor grabadas que en un informe escrito. Una frase como "intenté romperlo y no pude" no me dice nada de cuánto se esforzó, y la grabación de los intentos me dice mucho. Puedo ver si forzó el formulario una vez y pasó a otra cosa, o si volvió con otra cuenta o con otro orden de pasos. Los ataques que fallaron forman parte de la evidencia de que el cambio aguanta.

La línea que solo puedo escribir yo

La última parte del prompt es un hueco que cambia con cada pull request. Es donde le digo al agente dónde está el riesgo.

Mi propio ejemplo es "tanto en el ámbito personal como en el de organización". Cuando una funcionalidad tiene que comportarse bien en una cuenta personal y dentro de una organización, casi todo lo que puede salir mal está en la costura entre ambas: algo que pertenece a un ámbito y aparece en el otro, o una página que funciona para el propietario y falla para un miembro. El agente puede leer el diff e intuirlo. No sabe qué caminos recorren de verdad los usuarios, ni qué error sería vergonzoso y cuál grave. Yo sí, porque conozco el producto y lo que quiero que haga.

Ese corchete es mi parte de la revisión. Aparta al agente de lo que sugiere el diff y lo lleva a lo que sé que se puede dañar, y la grabación me enseña si de verdad fue allí.

Lo que la grabación no muestra

La grabación tiene límites.

El agente elige qué graba: los caminos que recorre y, según las herramientas, cuándo empieza y cuándo termina la grabación. Si el ámbito de organización que pedí no sale en lo grabado, no tengo evidencia de que se probara, diga lo que diga el informe.

Todo lo que graba Playwright ocurre en el navegador. Los logs del servidor, las filas de la base de datos y la tarea en segundo plano que se ejecuta un minuto después no están ni en el vídeo ni en la traza. Una pantalla puede ponerse en verde encima de una fila escrita en la cuenta equivocada. Puede faltar una comprobación de autorización en el servidor mientras la interfaz oculta el botón a la perfección delante de la cámara, y la API que hay detrás seguiría aceptando la petición de cualquiera que la enviara directamente.

Aquí es donde se amortiza la mitad del prompt que pide el ataque. Una grabación del caso feliz nunca toca esa comprobación, y una del agente abriendo un registro que pertenece a otra cuenta, o enviando la petición con el botón oculto, sí. En todo lo que toque accesos, merece la pena nombrar ese ataque en la línea de contexto. Cuando el cambio llega a la base de datos o al servidor, las consultas y los logs de esa misma ejecución tienen que ir junto a la grabación, guardados donde el informe pueda remitir a ellos.

Una grabación también puede parecer correcta por el motivo equivocado. Si el agente sustituyó el backend por un stub para que la página cargara, lo que tienes es una grabación del stub. El prompt pide que sea en local y de principio a fin, y, antes que cualquier cosa que mostrara, importa con qué estaba hablando realmente la aplicación. Las peticiones de red de la traza responden a eso.

Una nota práctica: un vídeo de Playwright solo se escribe en disco cuando se cierra el contexto del navegador. Si el agente dice que grabó la ejecución y el archivo no está o está vacío, eso también es evidencia.

Dentro de esos límites, la grabación es la revisión lenta de julio, con el agente encargado de ejecutar y el juicio en mis manos.

La decisión sigue siendo mía

Los modelos han mejorado mucho desde que escribí el artículo de julio, y mi evidencia de eso son mis propias revisiones. Lo que noto es que, cuando el agente tiene que ejecutar la cosa y grabarla, y algo se rompe, lo dice, y puedo verlo yo mismo. Tampoco me creo la mejora solo porque él lo diga.

Los desarrolladores que solo conocen la revisión con IA como un bot que deja comentarios en un diff han visto su versión más pequeña. Esto se parece más a un tester que trabaja en mi máquina y que se saltaría pasos si le dejara: usa el cambio como lo usaría un usuario, intenta romperlo y deja la grabación para que yo vea qué pasos se saltó.

Leer el código sigue importando, y la grabación cubre lo que la lectura no alcanza: cómo se comporta la cosa una vez que se ejecuta. No sale gratis. Una ejecución tarda más que una lectura, la aplicación necesita datos con los que merezca la pena probar, y alguien sigue teniendo que mirar lo que entrega el agente.

Nada de eso convierte al agente en quien revisa. Él hace el trabajo pesado. Sigo siendo yo quien, al final, decide qué está bien y qué quiero. Cuando la grabación muestra un flujo que funciona pero no es lo que el producto debería hacer, el agente no puede saberlo, y cuando marca como bug un comportamiento intencionado, soy yo quien lo dice.

El artículo de julio terminaba en la línea entre el diff que has entendido y el diff que solo has visto. Las grabaciones hacen más barato llegar al lado entendido de esa línea. No necesito tragarme todas las ejecuciones, solo ver los momentos que importan y saber qué caminos cubre la grabación. Lo que ha cambiado es que ahora hago que la máquina grabe su trabajo, así que dedico menos atención a si hizo lo que dijo y más a si miró donde tenía que mirar. Solo puedo juzgar eso porque sé para qué sirve el producto, y cuando mira donde no debe, le mando una línea más de contexto y hago que lo vuelva a ejecutar.