Diseño de harnesses para desarrollar aplicaciones de larga ejecución

• Anthropic desarrolló una arquitectura multiagente inspirada en los GAN para resolver al mismo tiempo dos problemas: mejorar la calidad del diseño frontend y lograr codificación autónoma de larga duración
• La estructura separa al generador (generator) y al evaluador (evaluator), lo que permite calificar la calidad subjetiva del diseño con criterios concretos y resolver el problema del sesgo de autoevaluación del agente
• Con una arquitectura de 3 agentes de planificador-generador-evaluador, completa aplicaciones full-stack en sesiones de codificación autónoma de varias horas, incluyendo negociación de contratos de sprint y QA basado en Playwright
• Al pasar de Opus 4.5 a Opus 4.6, fue posible mantener una codificación consistente por más de 2 horas sin dividir en sprints, reduciendo la complejidad del harness sin perder rendimiento
• Incluso si el rendimiento del modelo mejora, el espacio de combinaciones interesantes de harnesses no se reduce, sino que se desplaza, y la tarea central de los ingenieros de IA es descubrir nuevas combinaciones

---

Por qué una implementación simple choca con sus límites

• En experimentos anteriores, se usó un método en el que un agente de inicialización descomponía las especificaciones del producto en una lista de tareas, y un agente de codificación implementaba cada función una por una, transfiriendo el contexto entre sesiones mediante artefactos
  • En la comunidad de desarrolladores también aparecieron enfoques similares que mantienen al agente en un bucle persistente de repetición mediante hooks o scripts, como el método de "Ralph Wiggum"
• En tareas complejas, persistía el problema de que el agente se desviaba de la trayectoria con el tiempo, y se observaron dos modos de fallo comunes
• Primer modo de fallo: a medida que se llena la ventana de contexto, el modelo pierde consistencia, y algunos modelos muestran una tendencia de "ansiedad de contexto (context anxiety)", intentando cerrar el trabajo antes de tiempo cuando juzgan que alcanzaron su límite de contexto
  • El reinicio de contexto (context reset) —vaciar por completo la ventana de contexto e iniciar un nuevo agente con un handoff estructurado que incluye el estado del agente anterior y los siguientes pasos— resuelve ambos problemas
  • Esto es distinto de la compactación (compaction), donde el mismo agente continúa tras resumir partes anteriores de la conversación; la compactación mantiene continuidad, pero no ofrece una hoja en blanco, por lo que la ansiedad de contexto puede persistir
  • En Claude Sonnet 4.5, la ansiedad de contexto era tan fuerte que solo con compactación no se podía garantizar el rendimiento en tareas largas, por lo que el reinicio de contexto se volvió un elemento central del diseño del harness
• Segundo modo de fallo: el problema de la autoevaluación (self-evaluation), donde cuando el agente evalúa lo que él mismo produjo tiende a elogiarlo con seguridad, incluso si la calidad es claramente mediocre
  • Esto es especialmente grave en tareas subjetivas como el diseño, donde no existe una verificación binaria equivalente a una prueba de software verificable
  • Separar al agente de trabajo del agente evaluador es una palanca muy potente, y ajustar al evaluador independiente para que sea escéptico es mucho más manejable que volver autocrítico al generador

Diseño frontend: hacer calificable una calidad subjetiva

• Sin intervención, Claude tiende a generar por defecto layouts seguros y predecibles que funcionan técnicamente, pero resultan visualmente mediocres
• Dos ideas clave guiaron el diseño del harness
  • Aunque no se puede puntuar por completo la estética, sí se puede mejorar con criterios de evaluación que codifican principios y preferencias de diseño — preguntar “¿este diseño es bello?” es menos consistente que “¿sigue buenos principios de diseño?”
  • Separar la generación y la calificación del frontend crea un ciclo de retroalimentación que empuja al generador hacia resultados más sólidos
• Los 4 criterios de evaluación entregados tanto al generador como al evaluador fueron:
  • Calidad de diseño (Design quality): si color, tipografía, layout e imágenes forman un conjunto coherente con atmósfera e identidad distintivas
  • Originalidad (Originality): si hay evidencia de decisiones personalizadas, o si parece un layout de plantilla, valores por defecto de librerías o patrones generados por IA — señales como tarjetas blancas sobre un degradado morado implican fallo
  • Ejecución (Craft): ejecución técnica como jerarquía tipográfica, consistencia del espaciado, armonía de color y relación de contraste — una prueba de capacidad, no de creatividad
  • Funcionalidad (Functionality): usabilidad independiente de la estética — si el usuario puede entender qué hace la interfaz y encontrar las acciones principales
• La calidad de diseño y la originalidad se ponderaron más que la ejecución y la funcionalidad — porque Claude ya obtenía buenas notas por defecto en ejecución y funcionalidad, pero producía resultados mediocres en diseño y originalidad
  • Los criterios también penalizaban explícitamente patrones muy genéricos de “AI slop”, empujando al modelo a asumir riesgos estéticos
• La orquestación se construyó con Claude Agent SDK: el generador producía un frontend en HTML/CSS/JS, y el evaluador interactuaba directamente con la página en vivo mediante Playwright MCP, tomaba capturas, inspeccionaba cuidadosamente la implementación y luego escribía puntuaciones y críticas detalladas
  • Se repetía de 5 a 15 veces por generación, y en cada iteración el generador respondía a la crítica del evaluador y se movía hacia direcciones más distintivas
  • La ejecución completa podía tardar hasta 4 horas
  • Al generador se le indicaba tomar una decisión estratégica tras cada evaluación: si la tendencia del puntaje era buena, mejorar la dirección actual; si el enfoque no funcionaba, cambiar por completo a otra estética
• La redacción de los criterios afectó al generador de maneras inesperadas — frases como “los mejores diseños son de calidad de museo” impulsaban cierta convergencia visual, y el prompting asociado a los criterios moldeaba directamente el carácter del resultado
• Los puntajes por lo general mejoraron a lo largo de las iteraciones, pero no siempre de forma lineal, y con frecuencia se preferían iteraciones intermedias por encima de la última
  • La complejidad de implementación tendía a aumentar con cada iteración, al perseguir soluciones más ambiciosas en respuesta al feedback del evaluador
  • Desde la primera iteración ya se obtenían resultados notablemente mejores que la línea base sin prompting, porque los propios criterios y su lenguaje empujaban al modelo fuera de sus valores por defecto genéricos incluso antes del feedback del evaluador
• Caso del sitio web de un museo neerlandés: hasta la 9.ª iteración se había construido una limpia landing page en tema oscuro, pero en la 10.ª se descartó por completo el enfoque y se reimaginó como una experiencia espacial con una sala 3D renderizada con perspectiva CSS, piso ajedrezado, obras colgadas libremente en las paredes y navegación entre galerías a través de puertas — un tipo de salto creativo que no se había visto en generación de una sola pasada

Escalando a codificación full-stack

Arquitectura

• En el harness de larga ejecución anterior, el agente de inicialización, los agentes de codificación por función y los reinicios de contexto entre sesiones resolvían la codificación consistente a lo largo de múltiples sesiones
  • Debido a la ansiedad de contexto en Sonnet 4.5, el reinicio de contexto era clave, pero en Opus 4.5 este comportamiento desapareció en gran parte, permitiendo hacer todo el build en una sola sesión continua sin reinicios de contexto
  • La compactación automática de Claude Agent SDK manejaba el crecimiento del contexto
• Se configuró un sistema de 3 agentes:
  • Planificador (Planner): expande un prompt breve de 1 a 4 oraciones a una especificación completa del producto — el prompting se centra en el contexto del producto y el diseño técnico de alto nivel más que en detalles de implementación, porque predefinir detalles técnicos puede propagar errores aguas abajo
    • También se le indica buscar oportunidades para tejer (weave) funciones de IA dentro de la especificación del producto
  • Generador (Generator): toma una función a la vez de la especificación por sprint, la implementa con un stack React/Vite/FastAPI/SQLite (luego PostgreSQL), al final de cada sprint hace una autoevaluación y entrega a QA, con control de versiones en git
  • Evaluador (Evaluator): usando Playwright MCP, recorre la aplicación en ejecución como un usuario real para probar funcionalidad de la UI, endpoints de API y estado de la base de datos — puntúa según profundidad del producto, funcionalidad, diseño visual y calidad del código, y el sprint falla si no alcanza umbrales duros por criterio
• Antes de cada sprint, el generador y el evaluador negocian un contrato de sprint (sprint contract) — acuerdan la definición de “terminado” para ese bloque de trabajo antes de escribir código
  • Como la especificación del producto se mantenía intencionalmente en alto nivel, esta etapa cerraba la brecha entre las historias de usuario y una implementación comprobable
  • La comunicación se gestionaba mediante archivos — un agente escribía un archivo y el otro lo leía y respondía

Resultado de ejecución del harness: creador de juegos retro

• Se probó con el prompt: "Crea un creador de juegos retro 2D con editor de niveles, editor de sprites, comportamientos de entidades y un modo de prueba jugable"
• Agente en solitario: 20 minutos / $9 vs harness completo: 6 horas / $200 — el harness costó más de 20 veces más, pero la diferencia de calidad en el resultado fue inmediatamente evidente
• Resultado del modo solitario: la pantalla inicial cumplía con las expectativas, pero al hacer clic aparecieron los problemas — el layout desperdiciaba espacio, el flujo de trabajo era rígido, primero había que crear sprites y entidades pero la UI no lo guiaba, y lo más importante: el juego real no funcionaba (las entidades aparecían en pantalla, pero no respondían a la entrada; el cableado entre la definición de entidades y el runtime del juego estaba roto)
• Resultado con harness: el planificador expandió el prompt de una sola oración a 16 especificaciones funcionales en 10 sprints — incluyendo sistema de animación de sprites, plantillas de comportamiento, efectos de sonido y música, generador de sprites asistido por IA, diseñador de niveles y exportación del juego mediante enlaces compartibles
  • Tomó las habilidades de diseño frontend y generó el lenguaje de diseño visual de la app como parte de la especificación
  • El canvas aprovechaba todo el viewport, el tamaño de los paneles era razonable y había una identidad visual consistente siguiendo la dirección de diseño especificada
  • El editor de sprites era más rico y completo, con una paleta de herramientas más limpia, mejor selector de color y controles de zoom más utilizables
  • La integración de IA aceleraba el flujo de trabajo generando distintas partes del juego a través de prompting
• Diferencia clave en el modo de juego: la ejecución en solitario no lograba que el juego funcionara, mientras que con el harness sí se podía mover entidades y jugar de verdad — había cierta aspereza en el motor físico (superposición entre plataformas y personaje) y límites en la composición de niveles por IA (muros demasiado altos para saltar), pero la funcionalidad central sí operaba
• El evaluador mantuvo la implementación alineada con la especificación — solo en el Sprint 3 había un contrato detallado que cubría 27 criterios para el editor de niveles
  • Ejemplos de problemas detectados: la herramienta de relleno rectangular colocaba mosaicos solo en los puntos de inicio/fin del arrastre, error de condición en el handler de la tecla para borrar entidades, y un problema en el orden de rutas de FastAPI que hacía que reorder se interpretara como entero y devolviera un error 422
• Ajustar el evaluador requirió mucho trabajo — en estado base, Claude era un mal agente de QA: encontraba problemas legítimos pero luego se convencía a sí mismo de que “no eran gran cosa” y aprobaba igual, además de pasar por alto bugs sutiles por pruebas superficiales
  • Solo después de repetir varias veces el bucle de desarrollo de leer logs del evaluador, encontrar casos donde el juicio divergía y actualizar el prompt de QA, se logró una calificación razonable

Mejoras iterativas del harness

• Aunque los resultados iniciales fueron prometedores, eran grandes, lentos y caros, así que el siguiente paso fue simplificar el harness sin degradar el rendimiento
  • Cada componente del harness codifica una suposición sobre lo que el modelo no puede hacer por sí solo, y vale la pena someter esas suposiciones a pruebas de estrés — porque pueden quedar obsoletas rápidamente si el modelo mejora
  • El principio fue: “buscar la solución más simple posible y aumentar complejidad solo cuando haga falta”
• Los intentos de simplificación radical no lograron reproducir el rendimiento original, y como era difícil identificar qué piezas realmente soportaban la carga, se pasó a un enfoque sistemático de quitar un componente a la vez
• El lanzamiento de Opus 4.6 dio un motivo extra para reducir la complejidad del harness — planea con más cuidado, mantiene tareas agentic por más tiempo, trabaja de forma más estable en codebases más grandes, mejoró en revisión de código y debugging para detectar sus propios errores, y la búsqueda en contextos largos también mejoró mucho

Eliminación de la estructura por sprints

• Se eliminó por completo la estructura de sprints — con las capacidades mejoradas de Opus 4.6, el modelo puede manejar el trabajo de manera consistente sin necesidad de descomposición
• Se conservaron el planificador y el evaluador — sin planificador, el generador se queda corto de alcance, empieza a construir solo a partir del prompt crudo y sin especificación, y termina creando aplicaciones con menos funciones
• El evaluador pasó de calificar por sprint a una sola pasada al final de la ejecución
  • Si la tarea está dentro del rango de capacidad del modelo por sí solo, el evaluador se vuelve un overhead innecesario, pero en tareas que están en el borde de la capacidad del modelo sigue aportando mejoras reales
  • Por eso, el evaluador no es un sí/no fijo, sino que vale su costo cuando se quiere ir más allá de lo que el modelo puede hacer de forma estable sin ayuda
• También se añadió prompting para mejorar la construcción de funciones de IA — tomó bastante iteración lograr que el generador construyera agentes adecuados que operaran la funcionalidad de la propia app mediante herramientas, porque es conocimiento reciente y los datos de entrenamiento de Claude lo cubren de forma limitada

Resultado del harness actualizado: DAW en el navegador

• Se probó con el prompt: "Construye un DAW totalmente funcional en el navegador usando Web Audio API"
• El total fue de aprox. 4 horas y $124.70
  • Planificador 4.7 min/$0.46, ronda de build 1 2 h 7 min/$71.08, QA ronda 1 8.8 min/$3.24, ronda de build 2 1 h 2 min/$36.89, QA ronda 2 6.8 min/$3.09, ronda de build 3 10.9 min/$5.88, QA ronda 3 9.6 min/$4.06
• El builder se ejecutó de forma consistente por más de 2 horas sin descomposición en sprints
• Feedback inicial del agente de QA: excelente fidelidad de diseño, agente de IA y backend, pero la completitud funcional era el principal punto de fallo — no se podían arrastrar ni mover clips en la línea de tiempo, no había panel de UI para instrumentos (knobs de synth, pads de batería), y faltaba un editor visual de efectos (curvas de EQ, medidores de compresor)
• Feedback de QA en la segunda ronda: la grabación de audio seguía como stub, no estaban implementados el cambio de tamaño y el corte de clips, y la visualización de efectos eran sliders numéricos en lugar de gráficos
• La app final no alcanza el nivel de un programa profesional de producción musical y la capacidad del agente para componer canciones todavía necesita mejorar, además de que Claude no puede escuchar realmente el sonido, por lo que el ciclo de feedback de QA es menos efectivo en términos de gusto musical
  • Aun así, incluye los elementos centrales de un programa funcional de producción musical, con vista de arreglo, mezclador y transporte operativos
  • Solo con prompting podía producir fragmentos cortos de canciones — el agente configuraba tempo y tonalidad, colocaba melodías, creaba una pista de batería, ajustaba niveles del mezclador y añadía reverb

Perspectivas futuras

• A medida que los modelos mejoren, se espera que puedan realizar tareas más largas y complejas, y en algunos casos podría disminuir la importancia del andamiaje que los rodea, de modo que ciertos problemas podrían resolverse de forma natural simplemente esperando al siguiente modelo
• Por otro lado, cuanto mejores sean los modelos, más amplio se vuelve también el espacio para desarrollar harnesses capaces de lograr tareas complejas por encima de la línea base
• Lecciones clave:
  • Siempre es una buena práctica experimentar con el modelo objetivo, leer trazas en problemas reales y ajustar el rendimiento hacia el resultado deseado
  • En tareas más complejas, descomponer el trabajo y aplicar agentes especializados a cada aspecto puede abrir margen adicional
  • Cuando sale un nuevo modelo, conviene volver a revisar el harness para quitar las partes que ya no sostienen carga en el rendimiento y añadir nuevas partes que permitan lograr capacidades mayores que antes eran imposibles
• Incluso si los modelos mejoran, el espacio de combinaciones interesantes de harnesses no se reduce, sino que se desplaza, y el reto de los ingenieros de IA es seguir encontrando la próxima nueva combinación