Anthropic ensinou o Claude a criar aplicativos por horas: três agentes e 4 critérios

A Anthropic publicou uma análise de engenharia sobre como construir um harness para sessões longas e autônomas de programação. O autor, Prithvi Rajasekaran, da equipe Labs, passou vários meses trabalhando em dois problemas relacionados: fazer o Claude produzir design de frontend de alto nível e montar aplicativos inteiros sem participação humana. O resultado é uma arquitetura de três agentes, planner–generator–evaluator, que entrega produtos full-stack ricos em sessões de várias horas. O princípio foi emprestado das redes generativas adversariais (GANs).

Onde os agentes isolados quebram

A versão anterior do harness usava um agente inicializador, que dividia a especificação em tarefas, e um agente de codificação, que implementava uma feature por vez. Ela esbarrou em um teto por dois motivos.

O primeiro: em tarefas longas, o modelo perde a coerência à medida que o contexto se enche. Alguns modelos também apresentam «ansiedade de contexto» e começam a encerrar o trabalho antes da hora quando sentem que o limite está perto. A compactação (um resumo da parte antiga da conversa, feito no próprio contexto) não entrega uma folha em branco, e a ansiedade continua. Por isso, o Sonnet 4.5 exigiu resets completos de contexto, com passagem estruturada de estado. O preço dessa solução: orquestração mais complexa, mais tokens e maior latência.

O segundo: a autoavaliação. Quando pedem a um agente que avalie o próprio trabalho, ele o elogia com confiança, mesmo quando uma pessoa enxerga um resultado medíocre. Em design isso é ainda mais evidente, porque não existe um teste binário como o teste unitário. Separar o «executor» do «juiz» não cura totalmente a condescendência: o avaliador continua sendo um LLM e tende a favorecer textos produzidos por LLMs. Mesmo assim, ajustar um avaliador cético separado é bem mais fácil do que ensinar o gerador a criticar a si mesmo.

Design: quatro critérios em vez de «bonito»

A pergunta «o design é bonito?» gera notas instáveis, enquanto «ele segue os nossos princípios de bom design?» já pode ser avaliada. Rajasekaran formulou quatro critérios e os apresentou aos dois agentes:

• Design quality: coerência de clima e identidade, e não um conjunto de detalhes soltos.
• Originality: decisões autorais conscientes, em vez de templates, padrões de bibliotecas e «AI slop», como gradientes roxos sobre cartões brancos.
• Craft: hierarquia tipográfica, espaçamentos, contraste. Aqui o Claude já é forte por natureza.
• Functionality: usabilidade, independentemente da estética.

Os pesos favoreceram qualidade e originalidade, porque era ali que o modelo entregava resultados insossos. O avaliador foi calibrado com exemplos few-shot, com detalhamento das notas, para que as avaliações não oscilassem. O ciclo foi montado com o Claude Agent SDK. O avaliador recebeu o Playwright MCP, navegava sozinho pela página em execução, tirava screenshots e escrevia a crítica. Cada execução levava de 5 a 15 iterações e até quatro horas.

Curiosamente, a redação dos critérios influenciou o resultado mais do que o esperado. A expressão «os melhores designs de nível de museu» empurrava os trabalhos para um estilo visual específico. A melhora não foi estritamente linear, e o autor muitas vezes preferia uma iteração intermediária à final. No exemplo do site de um museu holandês, a nona iteração resultou em uma landing page escura e bem acabada. Na décima, o modelo abandonou essa versão e criou uma sala 3D com piso xadrez em CSS perspective, quadros nas paredes e navegação por portas.

Três agentes para full-stack

No desenvolvimento de aplicativos, o papel do avaliador de design passou para o QA e o code review. O Opus 4.5 eliminou em boa parte a «ansiedade de contexto», então os resets foram removidos: a sessão corre de forma contínua, e o crescimento do contexto é contido pela compactação automática do SDK.

O planner transforma um pedido de 1–4 frases em uma especificação completa de produto. Ele foi mantido de propósito no nível do produto e da arquitetura de alto nível: um erro em detalhes técnicos granulares se propagaria em cascata para a implementação. O generator trabalha em sprints, uma feature por vez, com React, Vite, FastAPI e SQLite (depois PostgreSQL), com git e autoverificação antes de passar o trabalho ao QA.

O evaluator, via Playwright MCP, clica no aplicativo em execução como um usuário e verifica a UI, a API e o estado do banco de dados. Ele avalia bugs e os critérios: profundidade do produto, funcionalidade, design e qualidade do código. Cada critério tem um limite rígido, e a reprovação em qualquer um deles reprova o sprint.

Antes de cada sprint, o gerador e o avaliador combinam um «contrato»: o que será considerado concluído, antes mesmo de o código ser escrito. Ele funciona como uma ponte entre as histórias de usuário de alto nível e uma implementação verificável.

Para quem constrói agentes, as conclusões são práticas. Leve a avaliação para um agente separado e calibre-o com exemplos. Traduza requisitos subjetivos em critérios explícitos, com pesos. A cada upgrade de modelo, verifique se você ainda precisa de uma estrutura pesada, como os resets de contexto: o Opus 4.5 mostrou que parte das gambiarras se torna obsoleta.