La arquitectura de agentes de IA debe separar fase y verificación

Olvidad la idea de que pedirle al modelo que sea más crítico arregla el problema. Un desarrollador ha publicado en GitHub una implementación práctica para el problema más gordo de los agentes de IA: la autocorrección que no corrige nada. El punto de partida no es teórico, es una anécdota de un test harness roto. Durante semanas, el script mostraba cero fallos y salida limpia. El problema no era el código bajo prueba, sino que el test no encontraba los casos de referencia. Al no comparar nada, no podía fallar. Todo se desplegaba con una confianza que la ausencia de control nunca habría dado.

Esa misma dinámica se repite con los agentes de agentes de generación de código. Cuando un agente planifica, escribe código y luego revisa su propio diff, suele aprobar el trabajo. El modelo guarda en el contexto por qué cada atajo parece razonable. Al revisar el diff, lee la intención, no el comportamiento. Ya se convenció en la primera pasada, la segunda es gratuita.

El autor del proyecto, IanitaAC, define la solución como una necesidad estructural. El componente que verifica no puede heredar las suposiciones del que construye. Al implementar la verificación en el mismo prompt donde se explicaron las decisiones de diseño, la independencia se pierde. Si una fase explica lo que hizo a la siguiente, una ejecución defectuosa parecerá correcta. El remedio que ha aplicado es físico: aislar los contextos. El rol de verificación no recibe un resumen de lo que hizo el codificador, solo la ruta del archivo. El momento en que un rol transmite su razonamiento al siguiente, la validación se convierte en una repetición del sesgo original. Añadir un control que falle deliberadamente en el test harness evita que cero casos recogidos se interprete como éxito.

En el repositorio de claude-subagent-dev-pipeline comparte una implementación para Claude Code bajo licencia MIT. El pipeline divide el flujo en cuatro roles: Arquitecto, Codificador, Tester y Manager. Cada uno actúa en su ámbito y el Manager gestiona las transiciones. El Tester, en particular, escribe y ejecuta pruebas reales sin haber visto nunca el razonamiento del Codificador. Esta separación es lo que ha hecho que los resultados mejoren en su entorno.

El coste de la separación

Esta arquitectura tiene un precio claro. Ejecutar cuatro roles cuesta aproximadamente cuatro veces lo que cuesta uno solo. El sistema rechaza por diseño las correcciones de una sola línea. Si el proceso de orquestación es más caro que ahorrar el tiempo de depuración, no tiene sentido activarlo. No es una solución para todo, sino para ese tramo donde la complejidad del agente supera el beneficio de la automación rápida.

Lo que aporta el ejemplo es concreto y aplicable fuera del ecosistema de Claude. La lección no es solo para quien use agentes de IA, sino para cualquier pipeline de CI/CD. Un test que no prueba nada es más peligroso que la falta de test. Y un revisor que conoce el diseño no es un revisor, es un testigo. Separar el contexto de ejecución del de validación es el único camino que ha mostrado resultados reales para este autor. El precio computacional es alto, pero es un coste medible frente al riesgo de confiar en un sistema que se valida a sí mismo.