Los agentes de código pueden escribir miles de líneas en minutos. El problema es que ningún test automatizado garantiza que el resultado sea visualmente correcto, no crashee al arrancar, o haga exactamente lo que pediste. Simon Willison, uno de los ingenieros más influyentes en el ecosistema de LLMs, acaba de lanzar dos herramientas que abordan este problema de raíz: Showboat y Rodney.
La premisa es simple pero ignorada con frecuencia: que el código pase los tests no significa que funcione. Y si tu agente no puede demostrarte que lo que construyó realmente sirve, estás volando a ciegas.
¿Por qué el testing manual sigue siendo insustituible?
Willison lo resume así en su guía de patrones de ingeniería agéntica: el atributo definitorio de un agente de código es que puede ejecutar el código que escribe. Eso le permite confirmar que funciona —o iterar hasta que lo haga. Pero los tests automatizados tienen un límite claro: “Cualquiera que haya trabajado con tests automatizados ha visto casos donde todos pasan pero el código falla de forma obvia. Puede crashear el servidor al arrancar, no mostrar un elemento de UI crucial, o perderse algún detalle que los tests no cubren.”
Su solución no es contratar más QA humano ni pagar caro por swarms de agentes (como hace StrongDM con su “software factory” donde el código nunca es revisado por humanos). Su solución es enseñarle al agente a testearse a sí mismo —y documentar ese proceso de forma verificable.
Las técnicas de testing manual agéntico
Dependiendo del tipo de proyecto, hay diferentes enfoques que Willison recomienda:
- Python -c para librerías: Pasar código directamente al intérprete de Python con
python -c "..."es el truco más simple. Los agentes ya lo conocen y muchas veces lo usan solos si se los recuerdas. - curl para APIs JSON: Para proyectos con endpoints web, decirle al agente “explora la API con curl” suele resultar en pruebas rápidas y amplias de múltiples aspectos de la interfaz.
- Playwright para UIs web: Cuando hay una interfaz visual, la opción más poderosa es automatizar un browser real. Playwright —open source de Microsoft, con bindings en múltiples lenguajes— es el referente. Basta con decirle al agente “testea eso con Playwright” y él elige el binding apropiado.
Rodney: un browser para que tus agentes “vean”
Willison construyó Rodney como wrapper especializado sobre el Chrome DevTools Protocol, diseñado específicamente para ser usado por agentes de código. El trick principal está en el prompt:
“Usa
uvx rodney --helppara ver cómo funciona, luego mira los screenshots.”
Tres técnicas en una frase: uvx instala Rodney automáticamente si no está, el comando --help está diseñado para darle al agente todo lo que necesita saber de una vez, y la mención de “screenshots” activa las capacidades de visión del modelo para evaluar cómo se ve visualmente la página.
Rodney puede tomar screenshots, correr JavaScript sobre la página cargada, hacer scroll, hacer click, tipear, y leer el árbol de accesibilidad. Es un browser controlable por texto, para agentes que no tienen display.
Showboat: los agentes que muestran su trabajo
Showboat resuelve otro problema distinto: ¿cómo sabes que el agente realmente hizo lo que dice que hizo? La respuesta es pedirle que construya un documento de evidencia mientras trabaja.
Es un CLI (binario Go, instalable también como wrapper Python) con tres comandos clave:
showboat note: Agrega una nota Markdown al documento de demo.showboat exec: Registra un comando, lo ejecuta, y captura el output en el documento. El agente no puede falsear lo que pasó —el output real queda registrado.showboat image: Ejecuta un comando que genera una imagen (como un screenshot de Rodney) y la incrusta en el documento.
El resultado es un archivo Markdown que documenta exactamente qué hizo el agente, con los comandos y sus outputs reales. Willison lo describe como “una forma de hacer que los agentes muestren su trabajo” —lo opuesto al agente que dice “¡listo, funcionó!” sin ningún respaldo.
El workflow completo en la práctica
La combinación Rodney + Showboat permite prompts así:
- El agente construye la feature
- Usa Rodney para abrir el browser y navegar la UI real
- Usa Showboat exec para registrar los comandos y outputs
- Usa Showboat image para capturar screenshots con Rodney
- El resultado es un documento de demo que puedes revisar en 2 minutos para saber qué pasó
Y si algo falla en el testing manual, el workflow recomendado es: arreglar con TDD red/green para que ese caso nuevo quede cubierto en los tests permanentes.
Por qué importa
Estamos en el momento donde los agentes generan código más rápido de lo que los humanos pueden revisarlo. La respuesta instintiva es “más tests automatizados”, pero los tests solo cubren lo que ya sabías que querías probar. El testing manual —aunque sea realizado por el mismo agente— captura lo que los tests no ven: el crasheo al arrancar, el botón que no aparece, el caso de borde que nadie anticipó.
Lo más interesante de Showboat y Rodney no es la tecnología en sí —es el patrón que representan. Willison llegó a construir ambas herramientas en su teléfono, con un agente. Es recursivo y es deliberado: estas son herramientas que los agentes construyen y usan para demostrarte que funcionan. Cuanto más código automatizado producimos, más valiosos son los mecanismos que reducen el tiempo que necesitas invertir en QA manual.
Si usas Cursor, Claude Code, o cualquier agente de código en tu día a día, vale la pena tener estos patrones en el toolbox. No para cada tarea trivial, sino para el momento donde el agente dice “listo” y tú necesitas saber si de verdad lo está.
→ Ver también: Cursor Automations: agentes que ejecutan tareas de código de forma autónoma y Karpathy sobre programar con IA: el cambio que viene.
