- Los agentes de IA para escribir código generan código y aplican cambios a una rama mientras el desarrollador duerme, pero es difícil verificar la exactitud y confiabilidad del resultado
- Si la misma IA prueba el código que escribió, se convierte en una máquina de autocomplacencia y no logra detectar malentendidos que se apartan de la intención original
- Tomando prestado el principio central de TDD, se redactan primero los criterios de aceptación antes de escribir el código, y luego el agente implementa con base en ellos y realiza una verificación separada
- Se construyó un pipeline de 4 etapas combinando el modo headless de Claude Code (claude -p) con Playwright MCP como herramienta de verificación, sin necesidad de un backend aparte
- Para confiar en lo que produce un agente, hay que definir claramente qué significa "terminado" antes de empezar; es un proceso más difícil que escribir prompts, pero indispensable
El problema de verificar código de agentes autónomos
- Con herramientas de IA como Gastown, los agentes pueden escribir código durante horas y reflejar cambios en una rama, pero no existe una forma confiable de verificar si el resultado realmente es correcto
- Tras realizar durante los últimos 6 meses talleres de Claude Code para más de 100 ingenieros, se confirmó el mismo problema en todos los equipos
- Los equipos que usan Claude en PR cotidianos vieron aumentar el volumen de PR fusionados de 10 por semana a 40~50, por lo que dedican mucho más tiempo a revisar código
- Cuanto más autónomo se vuelve el sistema, más se agrava el problema: llega un punto en que ya no se revisa el diff, solo se observa el despliegue esperando que no falle, y los errores se descubren recién después de desplegar
Límites de las soluciones existentes
- La opción de contratar más revisores no logra seguir el ritmo, y no es eficiente que ingenieros senior pasen todo el día leyendo código generado por IA
- Si Claude escribe pruebas para el código que él mismo generó, termina validando lo que Claude cree que el usuario quería, no lo que el usuario realmente quería
- Puede detectar bugs de regresión, pero no capta el malentendido (misunderstanding) original
- Si la misma IA hace a la vez la escritura y la verificación, se convierte en una "máquina de autocomplacencia (self-congratulation machine)"
- El propósito original de la revisión de código es tener una segunda mirada distinta de la del autor; la revisión cruzada entre IA proviene de la misma fuente y pasa por alto las mismas cosas
Lo esencial que TDD sí entendió bien
- El principio de TDD: escribir primero las pruebas, luego escribir el código y detenerse cuando las pruebas pasen (sin implementar de más)
- La razón por la que la mayoría de los equipos no hace TDD es que toma tiempo pensar de antemano qué debe hacer el código
- La IA resuelve el problema de la velocidad, así que esa excusa desaparece; ahora la parte lenta es determinar si el código es correcto
- En vez de pruebas unitarias, resulta más fácil describir en lenguaje natural lo que la funcionalidad debe hacer
- Ejemplo: "El usuario se autentica con correo y contraseña. Si las credenciales son incorrectas, se muestra 'Invalid email or password'. Si tiene éxito, se redirige a /dashboard. El token de sesión expira después de 24 horas"
- Estos criterios se pueden escribir antes de abrir el editor, y luego el agente implementa y otra cosa distinta verifica
Casos reales de aplicación
-
Cambios de frontend
- Se generan criterios de aceptación (Acceptance Criteria) a partir de un archivo de especificación
- AC-1: al entrar a /login con credenciales válidas, redirige a /dashboard y establece la cookie de sesión
- AC-2: al ingresar una contraseña incorrecta, muestra exactamente "Invalid email or password" y permanece en la página /login
- AC-3: si hay campos vacíos, el botón de envío queda deshabilitado o se muestra un error inline
- AC-4: después de 5 intentos fallidos, bloquea el login durante 60 segundos y muestra un mensaje con el tiempo de espera
- Cada criterio puede determinarse claramente como aprobado o fallido
- Después de que el agente construye la funcionalidad, un agente de navegador con Playwright ejecuta la verificación para cada AC, toma capturas de pantalla y genera un reporte con el resultado por criterio
- Si falla, se puede ver con precisión qué criterio falló y qué aparecía en el navegador
-
Cambios de backend
- Se aplica el mismo patrón sin navegador
- Se especifica el comportamiento observable de la API (código de estado, headers de respuesta, mensajes de error) y se verifica con comandos curl
-
Limitaciones
- No puede detectar malentendidos en la propia especificación: si la especificación está mal desde el inicio, la verificación puede pasar aunque la funcionalidad siga estando equivocada
- Lo que sí detecta Playwright: fallas de integración, bugs de renderizado y comportamientos que se rompen en un navegador real
- Es una afirmación más acotada que "exactitud verificada", pero aun así captura más cosas de las que la revisión de código solía detectar de forma consistente
-
Resumen del flujo de trabajo
- Escribir criterios de aceptación antes del prompt → el agente implementa según esos criterios → ejecutar verificación → revisar solo lo que falló (revisar fallas, no el diff)
Cómo construirlo: pipeline de 4 etapas
- Implementado como Claude Skill (github.com/opslane/verify), usando claude -p (modo headless de Claude Code) y Playwright MCP
- No se necesita un backend personalizado ni claves API adicionales; solo se usa el token OAuth existente de Claude
-
Etapa 1: Pre-flight
- Bash puro, sin llamadas a LLM
- Verifica si el servidor de desarrollo está corriendo, si la sesión de autenticación es válida y si existe el archivo de especificación
- Falla rápido antes de consumir tokens
-
Etapa 2: Planner
- Una llamada a Opus
- Lee la especificación y los archivos modificados, y decide qué necesita cada verificación y cómo ejecutarla
- Lee el código para encontrar los selectores correctos, así que no adivina nombres de clases
-
Etapa 3: Browser Agents
- Una llamada a Sonnet por cada AC, todas ejecutadas en paralelo
- Si hay 5 AC, 5 agentes navegan de forma independiente y toman capturas de pantalla
- Sonnet es 3~4 veces más barato que Opus y ofrece rendimiento equivalente en tareas basadas en clics
-
Etapa 4: Judge
- Una llamada final a Opus para leer toda la evidencia y devolver un veredicto por criterio: pass, fail o needs-human-review
-
Instalación
- Puede instalarse como plugin de Claude Code:
/plugin marketplace add opslane/verify
- O se puede clonar el repositorio y personalizarlo; cada etapa tiene una sola llamada a claude -p con entradas claras y salida estructurada
- Es posible cambiar el modelo, agregar etapas e integrarlo con CI usando la opción --dangerously-skip-permissions
Lección clave
- La idea central es: "Si no defines por adelantado qué significa terminado, no puedes confiar en el resultado"
- Redactar criterios de aceptación es más difícil que escribir prompts, pero obliga a considerar casos límite desde el inicio y mejora la calidad
- Los ingenieros se resisten por la misma razón por la que rechazaban TDD: al principio se siente más lento
- Sin criterios de aceptación, lo único que queda es leer el resultado y esperar que esté bien
- Este es un procedimiento indispensable para asegurar confiabilidad en entornos de desarrollo impulsados por IA
2 comentarios
Por más que hagas TDD, al nivel actual los LLM manipulan las pruebas para hacerlas pasar, así que la revisión humana sigue siendo indispensable..
Opiniones en Hacker News
Da la impresión de que los frameworks de LLM que están saliendo últimamente en realidad hacen que desarrollar sea más difícil y más caro
Con la configuración básica ya se puede llegar bastante lejos, y en una situación donde los modelos cambian todo el tiempo, me parece ineficiente crear montones de wrappers y harnesses
Este enfoque de dejarlo corriendo toda la noche mientras quema dinero va a quedar después como un chiste, tipo el meme de PHP
Según el artículo, “en los últimos 6 meses dio talleres de Claude Code a más de 100 ingenieros”
Cuando los dejen corriendo día y noche, al final la empresa de IA quiebre y lo único que quede sea un 80% de código espagueti escrito por IA, ya veremos quién se ríe
Siento que lo hecho con PHP hace 15 años era mejor que el entorno actual de full-stack JS/TS
PHP sigue vivo y evolucionando. Al final, el tooling de LLM también va a terminar siendo una herramienta básica de ese estilo
Las fronteras entre BA, PO, QA y SWE se están difuminando. Ahora están apareciendo roles híbridos entre negocio y desarrollo
Siento que hoy la gente usa agentes solo por usarlos
Yo solo corro dos, uno para escribir y otro para revisión, y aun así consigo fácilmente 5 a 7 veces más productividad
Le dedico más tiempo a revisar specs, y el agente termina la codificación en 10 a 30 minutos, así que no hay apuro
Mañana igual va a seguir habiendo trabajo, así que no veo por qué dejarlo toda la noche
Desde el punto de vista del cliente, da casi lo mismo si el bug vino de India, San Francisco o de una IA
Es un enfoque mucho más controlado que la moda actual de la “orquesta de agentes”
Por eso hice yo mismo la skill verify, para comprobar si Claude sigue bien las specs
Si haces que Claude use el patrón red-green-refactor, la calidad de las pruebas sí mejora
Incluso, si creas subagentes de red/green/refactor para que se validen entre sí, funciona bastante bien
La clave es no mezclar el contexto
El reward hacking existe de verdad y es difícil defenderse de eso
Incluso tomando como referencia esta guía, el problema de las malas pruebas sigue siendo grande
Como me dio buenos resultados, publiqué los principios y ejemplos y un starter repo
Es importante separar al autor del validador, y aunque sea el mismo modelo, si separas el contexto la calidad mejora
Con las limitaciones actuales de contexto de los LLM, todavía no son posibles los agentes de verdad
En código de más de 500 líneas los errores aumentan de golpe, y el límite real anda por las 200 líneas
Al final, un LLM no es más que una herramienta que hay que usar de forma repetitiva, como una calculadora
A este fenómeno yo lo llamo “Test Theatre”
Escribí sobre eso aquí. Hay que evitarlo activamente
Las buenas pruebas deberían validar patrones de diseño y dependencias, y ayudar a depurar
Por ejemplo, con Schemathesis se puede validar automáticamente permisos de usuario o si hay respuestas 5xx
Dejé un POC relacionado aquí
Últimamente estoy experimentando con orquestación de agentes
La clave es reducir las llamadas al LLM y conectarlas con un pipeline de scripts determinista
Expliqué más detalles en este artículo
Como en este registro del experimento, los scripts son más importantes que el LLM
Yo corro 6 agentes para operaciones de negocio
Les asigno distintos roles, como investigación de mercado, redacción de contenido y guiones de video
Eso de “dejarlos corriendo toda la noche” es una idea exagerada; en la práctica lo que funciona son objetivos claros y alcance acotado
El verdadero cuello de botella no es la ejecución, sino la gestión del contexto
No me queda claro qué está construyendo realmente esta persona
En LinkedIn solo se ven posts sobre Claude
En un negocio serio, eso sería impensable
Al final el código queda quieto mientras se ponen a pensar cómo venderlo
Es el mismo problema que cuando contratas a alguien que solo escribe pruebas
Al final solo verifica que “el código funciona como dice el código”
Definir specs claras es mucho más importante
Sorprende que en otras ramas de la ingeniería no se repita este error, pero en software sí, y mucho
Aunque la versión inicial esté mal, garantizan que después el comportamiento no cambie
Muchas consultoras trabajan con validación basada en acceptance criteria
La IA actual ya no es una herramienta que ayuda a desarrollar, sino que llegó al punto de reemplazar al desarrollador
Que ya no podamos controlar ni validar el código es un problema serio
Esto no se siente como una nueva forma de desarrollo, sino como una conversión religiosa que depende de la confianza en vez de la comprensión
Aunque tenga menos autonomía, solo hago merge de código que se pueda validar