Probé los 3 agentes de Playwright: escriben los tests, pero no saben qué es "correcto"

Playwright trae tres agentes de IA que exploran tu aplicación, escriben los tests y reparan los que se rompen. Los instalé, los corrí y los enseñé en vivo en una clase.

Funcionan. Ese no es el tema.

El tema son dos frases de la documentación oficial que casi nadie está leyendo con atención, y que cambian por completo cómo tienes que trabajar con ellos.

Estoy en medio de una serie sobre el arnés que sostiene tus tests, y la interrumpo para mostrarte esto. En la parada 07 armamos ese arnés a mano, pieza por pieza; quiero que llegues ahí sabiendo qué parte de ese trabajo ya no vas a hacer tú, y cuál te va a seguir tocando siempre.

Qué son, en treinta segundos

Llegaron en Playwright 1.56 y se instalan con un comando:

npx playwright init-agents --loop=vscode
# también: --loop=claude, --loop=codex, --loop=opencode

Son tres, y cada uno hace una cosa:

Fíjate en el nombre del flag: --loop. No es casualidad, y no es marketing. Un agente es un loop con herramientas y un objetivo. Playwright le puso a su comando exactamente la palabra que venimos usando en la serie.

Lo que cubren de verdad (y es bastante)

Si tomas las seis piezas de un framework —las de la parada 03, Anatomía de un harness— y las pones al lado de los tres agentes, el mapa es honesto y es generoso:

• El planner hace el trabajo de exploración que casi nadie documenta: recorre la app y deja por escrito qué flujos existen.
• El generator te escribe la pieza que más tiempo mecánico consume: los pasos, los selectores, la estructura del archivo.
• El healer ataca el mantenimiento, que es donde muere la mayoría de las suites: el selector que se movió, la espera que quedó corta.

Eso no es poco. Es, literalmente, la parte del trabajo que hace que la gente abandone la automatización a los seis meses. Si alguien te dice que esto es humo, no lo probó.

Frase número uno: el generator valida contra la app

Acá viene lo que cambia todo. La documentación oficial describe al generator diciendo que verifica selectores y assertions en vivo, mientras ejecuta el escenario.

Léelo otra vez, despacio, y piensa qué significa para las assertions.

Verificar un selector contra la app corriendo es exactamente lo que quieres: te confirma que el botón existe y que el localizador lo encuentra. Perfecto.

Verificar una assertion contra la app corriendo es otra cosa. Significa que el valor esperado se confirma preguntándole al sistema que estás probando.

Si la app hoy muestra un saldo mal calculado, el generator ve ese número, comprueba que efectivamente aparece, y escribe una assertion que lo da por bueno. El test nace en verde y nace defendiendo el bug.

Es la trampa del baseline, que desarmé entera en la parada 06 de la serie, El goal verificable: el problema del oráculo: un test que compara el sistema contra sí mismo no verifica, memoriza. La diferencia es que antes ese error tardaba semanas de copiar y pegar, y ahora se produce a escala en un minuto.

Frase número dos: el healer repara hasta que pase

La documentación del healer es igual de explícita: reejecuta el test hasta que pasa, o hasta que las barreras de seguridad detienen el loop.

Ahí está la condición de parada. Y la condición de parada de un loop es su objetivo.

El objetivo del healer, escrito en su propia documentación, no es “que el test sea correcto”. Es que el test se ponga verde.

La mayoría de las veces eso coincide con lo que quieres: el botón cambió de id, el healer actualiza el localizador, todos contentos. Pero mira los dos caminos posibles cuando un test se pone rojo:

Distinguir uno de otro no es un problema técnico. Es criterio. Es saber qué debía pasar, que es justo lo que ningún agente puede sacar de mirar la pantalla — porque la pantalla te muestra lo que hay, nunca lo que debería haber.

Entonces, ¿cinco de seis?

Sí, y esa es la buena noticia, no la mala.

Te automatizan la exploración, la escritura mecánica y el mantenimiento. Lo que no te automatizan —lo que por diseño no pueden— es el criterio de qué está bien. Esa pieza no se les escapó por falta de madurez del modelo: no está adentro de la aplicación, así que no hay forma de leerla de ahí. Está en la regla de negocio, en el criterio de aceptación, en la cabeza del que sabe qué debía pasar.

Que hoy suele ser la tuya.

Cómo trabajar con ellos sin perder el oráculo

Tres reglas que salieron de usarlos de verdad, no de leer la documentación:

1. Dale al planner el criterio, no solo la URL. Si lo sueltas contra la app, te va a describir lo que la app hace. Si le pasas los criterios de aceptación, la historia de usuario o la regla de negocio, el plan deja de ser un inventario de pantallas y pasa a ser un plan de pruebas.

2. Revisa las assertions antes que los pasos. El instinto es leer el test de arriba abajo. Hazlo al revés: ve directo a los expect y pregúntate de dónde salió cada valor esperado. Los pasos, si están mal, fallan solos y te avisan. Una assertion mal puesta no falla nunca — ese es todo el problema.

3. Ningún patch del healer entra sin diagnóstico. Aceptar reparaciones en lote es como aprobar un pull request por el color del check. Uno por uno, con la pregunta de arriba.

Lo que quiero que te lleves

Estos tres agentes son la mejor noticia que le pasó a la automatización de UI en años, y al mismo tiempo son la mejor demostración de por qué sigues haciendo falta.

Automatizan el arnés: lo que explora, lo que escribe, lo que repara. Dejan intacto el criterio que decide si lo que salió sirve. Y como ahora producen tests mucho más rápido de lo que los producías tú, ese criterio pasó de ser una parte de tu trabajo a ser el trabajo.

La serie sigue justo donde la dejé, en la parada 07: armar un harness de UI a mano, del cero al primer flujo verde. Vas a construir una por una las piezas que estos tres agentes te escriben solos — y vas a ver, con las manos, cuál es la que no te van a escribir nunca.