Un agente de QA en navegador real revisa cada PR que abre otro agente

El pasado martes 19 de mayo, un desarrollador publicó en Hacker News un proyecto en el que lleva trabajando varios meses en solitario: NotesASM, un tablero kanban donde cada ticket dispara dos agentes encadenados. El primero escribe el código y abre el PR; el segundo espera a que el entorno de preview levante y verifica el resultado conduciendo un navegador real. No es un concepto nuevo, pero la implementación tiene detalles de ingeniería que merecen atención.

Lo que distingue este proyecto de los pipelines de CI más habituales no es tanto la automatización en sí como la separación explícita de responsabilidades entre agente constructor y agente verificador, y sobre todo, la lógica que decide cuándo tiene sentido reintentar.

Cómo funciona el ciclo build → QA

El agente de construcción trabaja en un directorio temporal aislado contra un clon superficial del repositorio del usuario. Cuando termina, empuja una rama y abre un PR. Este agente está construido sobre el Claude Agent SDK.

El agente de QA entra en escena una vez que el deploy de preview está activo. Utiliza Browserbase para controlar un navegador real contra ese entorno efímero y contrasta lo que ve con los criterios de aceptación definidos en el ticket. El resultado se adjunta al PR como capturas y un archivo mp4 de la sesión, lo que hace la verificación auditable.

Si el QA falla, el agente constructor reintenta con el informe de fallos como contexto adicional, hasta un máximo de tres iteraciones. Este límite en sí no es llamativo; lo interesante es lo que ocurre antes de cada reintento.

El clasificador de fallos: la mejora de fiabilidad más relevante

Antes de relanzar el agente de construcción, un clasificador analiza el fallo y decide si fue un error real de código o un problema ambiental: Clerk no cargó, el preview nunca desplegó, la sesión de Browserbase devolvió un 403. Si el problema es ambiental, el bucle se interrumpe en lugar de que el agente intente corregir código que funcionaba bien.

Este punto merece subrayarse. Uno de los problemas más comunes en pipelines de agentes autónomos es que el modelo recibe retroalimentación ruidosa y empieza a "corregir" cosas que no estaban rotas. Filtrar el ruido ambiental antes de pasárselo al agente como contexto de error es, en la práctica, la diferencia entre un sistema que converge y uno que da vueltas. El propio autor lo señala como "el mayor avance de fiabilidad" del proyecto.

La integración con MCP y Claude Code

NotesASM expone un servidor MCP propio, de modo que desde Claude Code o cualquier cliente MCP compatible se puede decir "crea un ticket para X" y el ítem aterriza directamente en el backlog. Esto cierra el ciclo de forma bastante natural: el desarrollador interactúa con lenguaje natural desde su entorno habitual, y la plataforma se encarga de traducir esa intención en un ticket estructurado con criterios de aceptación.

La elección de MCP como interfaz de entrada no es accidental. Al ser el estándar de Anthropic para que los LLM llamen herramientas externas, cualquier cliente que ya lo soporte puede alimentar el backlog sin integraciones adicionales. Para equipos que ya trabajan con Claude Code en su flujo diario, la fricción para adoptar este tipo de herramienta es baja.

Para quién tiene sentido esto

Este enfoque es especialmente útil para equipos pequeños o desarrolladores en solitario con proyectos web que ya tienen deploys de preview automatizados (Vercel, Netlify o similares). El valor no está en sustituir la revisión humana de código compleja, sino en delegar las tareas repetitivas y verificables: cambios de UI, correcciones de copy, ajustes de comportamiento con criterios claros.

Para proyectos con lógica de negocio opaca o sin entornos de preview estables, el sistema pierde parte de su utilidad. El propio clasificador de fallos ambientales existe precisamente porque la infraestructura de preview es un punto de fricción real.

El proyecto está en fase pública temprana y el autor ha pedido expresamente opinión externa. Puede seguirse en notesasm.com y el hilo original está en Hacker News.

---

Desde EP, el detalle del clasificador de fallos ambientales nos parece la aportación más sólida del proyecto: es un patrón que debería estar en cualquier pipeline de agentes que opere sobre infraestructura externa, y que pocas implementaciones públicas abordan de forma explícita.