Harness para desarrollo de aplicaciones largas con IA | Keryc
He estado leyendo el experimento técnico de Anthropic sobre cómo diseñaron un harness para que modelos como Claude construyan aplicaciones completas en sesiones largas. ¿El truco? Una arquitectura multiagente inspirada en GANs y mucha ingeniería de prompts y evaluación para mantener calidad y coherencia durante horas.
Qué hicieron (resumen técnico)
Anthropic diseñó un sistema de tres agentes: planner, generator y evaluator. La idea central es separar responsabilidades: el planner transforma un prompt corto en un spec ambicioso; el generator implementa características (stack típico: React, Vite, FastAPI, SQLite/Postgres); y el evaluator prueba la app en ejecución usando Playwright MCP para dar feedback accionable.
Tomaron dos lecciones previas como punto de partida: descomponer el trabajo en trozos manejables y usar artefactos estructurados para pasar contexto entre sesiones. Para romper techos de calidad también aplicaron una estrategia GAN-like: un generador crea y un evaluador juzga. El evaluador fue calibrado con ejemplos few-shot y criterios concretos para convertir juicios subjetivos en métricas gradables.
Problemas clave que abordaron:
La "ansiedad por contexto": modelos que intentan cerrar la tarea cuando creen acercarse al límite de su ventana de contexto. Solución: resets de contexto o compaction según el modelo.
Autoevaluación demasiado indulgente: los agentes tienden a aprobar su propio trabajo. Separar el evaluador y afinar su escepticismo resultó más efectivo.
Experimento en frontend: loop generador-evaluador
Para diseño de interfaces se usó un loop iterativo: el generator produce HTML/CSS/JS, el evaluator lo navega con Playwright, toma screenshots, califica según criterios (p. ej. originalidad, fidelidad a principios de diseño) y devuelve una crítica detallada. Se corrieron entre 5 y 15 iteraciones por generación; algunas corridas duraron hasta 4 horas.
Detalles prácticos:
Se privilegiaron criterios que penalizaban patrones "AI slop" y fomentaban riesgo estético.
El evaluator fue calibrado con ejemplos con desagregación de puntajes para reducir drift.
El wording de los criterios influyó directamente en el carácter de las salidas (frases como "museum quality" empujaron hacia cierto estilo).
Resultado notable: el generador dio saltos creativos (por ejemplo, pasar de una landing clásica a una experiencia 3D en CSS al iterar), algo difícil de lograr en un solo pase.
Aplicación a full-stack y la arquitectura de tres agentes
Cuando escalaron a aplicaciones completas, mapearon el mismo patrón:
Planner: toma un prompt de 1 a 4 frases y genera un spec ambicioso, priorizando alcance de producto y diseño alto nivel sobre detalles de implementación.
Generator: implementa en sprints (o en rondas en la versión simplificada), hace self-evaluation y usa git para control de versiones.
Evaluator: ejecuta tests de integración funcionales con Playwright, prueba UI, endpoints y estado de base de datos, y aplica criterios con umbrales duros; si falla uno, el sprint no pasa.
Comunicación y handoff: los agentes intercambian archivos (uno escribe, otro lee), lo que mantiene contexto estructurado entre sesiones sin sobrecargar la ventana de contexto.
Comparativa de coste y calidad (ejemplo RetroForge):
Solo (single-agent): 20 min, $9, pero fallos funcionales importantes.
Full harness: 6 horas, $200, resultado mucho más pulido y funcional.
El evaluador fue clave para detectar bugs concretos (ejemplos dados: problemas en reorder de frames, handlers de delete mal condicionados, fillRectangle no disparado). Pero ajustar al evaluator exigió iteración para contrarrestar su tendencia inicial a minimizar problemas.
Evolución con modelos: resets, compaction y Opus 4.x
Encontraron dos estrategias para manejar contexto largo:
Compaction: resumir historia para mantener continuidad. Bueno si el agente no sufre "context anxiety".
Reset + handoff: cerrar el contexto y arrancar un agente nuevo, pasando un artefacto con suficiente estado. Soluciona context anxiety, pero añade latencia y complejidad.
Con Sonnet 4.5 necesitaban resets. Con Opus 4.6, el modelo mejoró planificación y manejo de contexto, permitiendo sesiones continuas usando compaction automática y reduciendo la necesidad de algunos scaffolds (p. ej. sprints por fuerza). Aun así, el evaluator sigue aportando valor cuando la tarea está al borde de lo que el modelo hace bien en solitario.
Resultados prácticos: DAW y lecciones de coste
Probando con un prompt para crear un DAW en el navegador (Web Audio API), la versión V2 del harness corrió ~3 h 50 min por unos $125 en tokens. El generator pudo armar vistas principales, transport, mezclador y un agente que genera fragmentos de canción, pero la QA aún detectó faltantes de interactividad (grabación stub, arrastre de clips, visualizadores de efectos).
Lecciones de coste-beneficio:
El harness da un salto de calidad claro, pero es sustancialmente más caro y lento.
Conforme los modelos mejoran, conviene reexaminar qué componentes del harness siguen siendo necesarios; algunos se pueden quitar y otros deben adaptarse.
Recomendaciones prácticas para desarrolladores que quieran replicar esto
Empieza simple: prueba single-agent y añade componentes hasta que notes mejora tangible.
Separa agentes por responsabilidad: planner para alcance, generator para implementación, evaluator para verificación.
Usa artefactos estructurados (archivos, contratos) para handoffs entre sesiones o agentes.
Invierte en un evaluator real que interactúe con la aplicación (Playwright u otra herramienta) y calibra su escepticismo con few-shot y umbrales duros.
Monitoriza trazas y logs: lee los registros del evaluator para ajustar prompts y pruebas.
Reevalúa el harness cuando migres a un modelo nuevo: algunas piezas pueden dejar de ser necesarias y otras te permitirán ampliar capacidades.
Reflexión final
Este trabajo muestra que la ingeniería del harness es tanto arte como ciencia. No basta con un modelo potente: la estructura alrededor del modelo, el tipo de evaluación y cómo se intercambia contexto determinan si una sesión larga produce software usable. Conforme los modelos mejoren, el papel del harness cambia, no desaparece. ¿Quieres que tu agente haga trabajo complejo? Diseña el feedback correcto, y si puedes, haz que otro agente sea quien lo juzgue.
