Anthropic enseñó a Claude a construir aplicaciones durante horas: tres agentes y 4 criterios

Anthropic ha publicado un análisis de ingeniería sobre cómo construir un harness para sesiones largas de programación autónoma. Su autor, Prithvi Rajasekaran, del equipo de Labs, dedicó varios meses a dos tareas relacionadas: lograr que Claude haga un diseño de frontend sólido y que construya aplicaciones enteras sin intervención humana. El resultado es una arquitectura de tres agentes, planner–generator–evaluator, que en sesiones de varias horas produce productos full-stack ricos en funciones. El principio está tomado de las redes generativas adversarias (GAN).

Dónde fallan los agentes individuales

La versión anterior del harness usaba un agente inicializador, que descomponía la especificación en tareas, y un agente de código que implementaba una función cada vez. Se topó con un techo por dos motivos.

El primero: en tareas largas, el modelo pierde coherencia a medida que se llena el contexto. Algunos modelos, además, muestran «ansiedad de contexto» y empiezan a cerrar el trabajo antes de tiempo cuando perciben que se acerca el límite. La compactación (resumir in situ la parte antigua de la conversación) no ofrece una hoja en blanco, y la ansiedad persiste. Por eso, con Sonnet 4.5 hicieron falta reinicios completos de contexto con una transferencia de estado estructurada. El precio de esta solución: orquestación más compleja, más tokens y mayor latencia.

El segundo: la autoevaluación. Cuando se le pide a un agente que valore su propio trabajo, lo elogia con seguridad, incluso cuando una persona ve que es mediocre. En diseño se nota especialmente, porque no existe una prueba binaria como un test unitario. Separar al «ejecutor» del «juez» no cura del todo la indulgencia: el evaluador sigue siendo un LLM y favorece los textos escritos por un LLM. Aun así, configurar un evaluador escéptico independiente resulta bastante más sencillo que enseñar al generador a criticarse a sí mismo.

Diseño: cuatro criterios en lugar de «que quede bonito»

La pregunta «¿es bonito el diseño?» produce valoraciones inestables, mientras que «¿sigue nuestros principios de buen diseño?» sí se puede evaluar. Rajasekaran formuló cuatro criterios y se los mostró a ambos agentes:

• Design quality: coherencia del ambiente y de la identidad, no un conjunto de detalles sueltos.
• Originality: decisiones de autor deliberadas en lugar de plantillas, valores por defecto de las bibliotecas y «AI slop», como los degradados morados sobre tarjetas blancas.
• Craft: jerarquía tipográfica, espaciado, contraste. Aquí Claude ya es fuerte de por sí.
• Functionality: usabilidad al margen de la estética.

Los pesos favorecieron la calidad y la originalidad, porque ahí el modelo producía resultados insípidos. El evaluador se calibró con ejemplos few-shot con desglose de puntuaciones, para que las notas no fluctuaran. El ciclo se montó sobre el Claude Agent SDK. El evaluador recibió Playwright MCP, navegaba por la página en vivo, hacía capturas de pantalla y redactaba la crítica. Una ejecución duraba entre 5 y 15 iteraciones y hasta cuatro horas.

Resulta curioso que la redacción de los criterios influyera en el resultado más de lo esperado. La frase «los mejores diseños de nivel de museo» empujaba los trabajos hacia un estilo visual concreto. La mejora no fue estrictamente lineal, y el autor a menudo prefería una iteración intermedia a la final. En el ejemplo del sitio de un museo neerlandés, la novena iteración dio una landing page oscura y pulcra. En la décima, el modelo la descartó y creó una sala 3D con suelo de ajedrez mediante CSS perspective, cuadros en las paredes y navegación a través de vanos de puertas.

Tres agentes para full-stack

En el desarrollo de aplicaciones, el papel del evaluador de diseño pasó a ser el de QA y revisión de código. Opus 4.5 eliminó en gran medida la «ansiedad de contexto», así que se suprimieron los reinicios: la sesión transcurre de forma continua y la compactación automática del SDK gestiona el crecimiento del contexto.

El planner convierte una petición de 1–4 frases en una especificación completa de producto. Se le mantuvo deliberadamente en el nivel de producto y de arquitectura de alto nivel: un error en los detalles técnicos granulares se propagaría en cascada a la implementación. El generator trabaja por sprints, de una función en una, con React, Vite, FastAPI y SQLite (más tarde PostgreSQL), con git y con una autoverificación antes de pasar el trabajo a QA.

El evaluator, mediante Playwright MCP, hace clic en la aplicación en ejecución como lo haría un usuario y comprueba la UI, la API y el estado de la base de datos. Evalúa los bugs y los criterios: profundidad del producto, funcionalidad, diseño y calidad del código. Cada criterio tiene un umbral estricto, y si falla cualquiera, el sprint se da por fallido.

Antes de cada sprint, el generador y el evaluador acuerdan un «contrato»: qué se considera terminado, antes incluso de escribir código. Es el puente entre las historias de usuario de alto nivel y una implementación verificable.

Para los equipos que construyen agentes, las conclusiones son prácticas. Delegue la evaluación en un agente independiente y califíquelo con ejemplos. Traduzca los requisitos subjetivos a criterios explícitos con pesos. Y compruebe, con cada actualización del modelo, si sigue necesitando un andamiaje pesado como los reinicios de contexto: Opus 4.5 demostró que parte de esos parches se queda obsoleta.