Design de harness para desenvolver aplicações de longa execução

• A Anthropic desenvolveu uma arquitetura multiagente inspirada em GAN para resolver simultaneamente dois problemas: melhorar a qualidade do design de frontend e fazer codificação autônoma de longa duração
• Com uma estrutura que separa gerador (generator) e avaliador (evaluator), tornou-se possível pontuar a qualidade subjetiva de design com critérios concretos, resolvendo o problema de viés na autoavaliação dos agentes
• Com uma arquitetura de 3 agentes — planner, gerador e avaliador —, concluiu aplicações full stack em sessões autônomas de codificação de várias horas, incluindo negociação de contrato de sprint e QA com base em Playwright
• Na transição do Opus 4.5 para o Opus 4.6, passou a ser possível codificar de forma consistente por mais de 2 horas sem dividir em sprints, reduzindo a complexidade do harness sem perder desempenho
• Mesmo com a melhora do desempenho dos modelos, o espaço de combinações interessantes de harness não diminui, mas se desloca; a tarefa central do engenheiro de IA é descobrir essas novas combinações

---

Por que a implementação simples esbarra em limites

• Em experimentos anteriores, foi usado um método em que um agente de inicialização decompunha a especificação do produto em uma lista de tarefas, e o agente de codificação implementava uma funcionalidade por vez, passando o contexto entre sessões por meio de artefatos
  • Na comunidade de desenvolvedores, também surgiram abordagens semelhantes, como o método "Ralph Wiggum", que mantém agentes em um loop recorrente persistente com hooks ou scripts
• Em tarefas complexas, o problema de agentes saírem da trajetória ao longo do tempo persistiu, e foram observados dois modos de falha em comum
• Primeiro modo de falha: à medida que a janela de contexto se enche, o modelo perde consistência; em alguns modelos, surge a tendência de encerrar o trabalho cedo ao concluir que chegou ao seu próprio limite de contexto, um fenômeno chamado "ansiedade de contexto (context anxiety)"
  • O reset de contexto (esvaziar completamente a janela de contexto e iniciar um novo agente com um handoff estruturado contendo o estado do agente anterior e os próximos passos) resolve ambos os problemas
  • Isso é diferente da compactação (compaction), em que o mesmo agente continua após resumir partes anteriores da conversa; a compactação mantém continuidade, mas não oferece uma página em branco, então a ansiedade de contexto pode persistir
  • No Claude Sonnet 4.5, a ansiedade de contexto era forte demais para que a compactação sozinha garantisse desempenho em tarefas longas, então o reset de contexto se tornou um elemento central do design do harness
• Segundo modo de falha: o problema de autoavaliação (self-evaluation), em que o agente avalia o próprio resultado e tende a elogiá-lo com confiança mesmo quando a qualidade é claramente mediana
  • Isso é especialmente grave em tarefas subjetivas como design, nas quais não existe uma verificação binária equivalente a testes de software verificáveis
  • Separar o agente executor do agente avaliador é uma alavanca poderosa; ajustar um avaliador independente para ser cético é muito mais fácil do que tornar o gerador autocrítico

Design de frontend: tornando a qualidade subjetiva algo pontuável

• Sem intervenção, o Claude tende a gerar por padrão layouts seguros e previsíveis que funcionam tecnicamente, mas são visualmente comuns
• Dois insights principais guiam o design do harness
  • Não é possível pontuar totalmente a estética, mas dá para melhorar com critérios de avaliação que codificam princípios e preferências de design — “esse design é bonito?” é menos consistente do que “isso segue bons princípios de design?”
  • Separar geração e pontuação no frontend cria um loop de feedback que conduz o gerador a resultados mais fortes
• Quatro critérios de avaliação fornecidos tanto ao gerador quanto ao avaliador:
  • Qualidade de design (Design quality): se cores, tipografia, layout e imagens formam um todo coerente com atmosfera e identidade próprias
  • Originalidade (Originality): se há evidência de decisões personalizadas ou se se trata de layout de template, padrão default de biblioteca ou padrão típico de geração por IA — sinais como cartões brancos sobre gradiente roxo contam como falha
  • Acabamento (Craft): execução técnica como hierarquia tipográfica, consistência de espaçamento, harmonia de cores e taxa de contraste — é um teste de competência, não de criatividade
  • Funcionalidade (Functionality): usabilidade independente da estética — se o usuário entende o que a interface faz e encontra as ações principais
• Qualidade de design e originalidade receberam peso maior do que acabamento e funcionalidade — porque o Claude já tendia a pontuar bem em acabamento e funcionalidade, mas entregava resultados medianos em design e originalidade
  • Os critérios penalizavam explicitamente padrões muito genéricos de "AI slop", incentivando o modelo a correr mais riscos estéticos
• A orquestração foi construída com o Claude Agent SDK: o gerador criava o frontend em HTML/CSS/JS, e o avaliador usava Playwright MCP para interagir diretamente com a página ao vivo, tirar screenshots, inspecionar a implementação em detalhe, atribuir notas e escrever críticas detalhadas
  • Eram feitas de 5 a 15 iterações por geração, com o gerador respondendo à crítica do avaliador em cada rodada e migrando para direções mais distintas
  • A execução completa podia levar até 4 horas
  • O gerador era instruído a tomar decisões estratégicas após cada avaliação: se a tendência das notas fosse boa, refinava a direção atual; se a abordagem não estivesse funcionando, mudava para uma estética completamente diferente
• A formulação dos critérios afetou o gerador de formas inesperadas — frases como "os melhores designs têm qualidade de museu" induziam uma convergência visual específica, mostrando que os critérios e a linguagem associada moldavam diretamente o caráter do resultado
• As notas geralmente melhoravam ao longo das iterações, mas nem sempre de forma linear; com frequência, iterações intermediárias eram preferidas à última
  • A complexidade de implementação tendia a aumentar ao longo das iterações, à medida que o gerador buscava soluções mais ambiciosas em resposta ao feedback do avaliador
  • Já na primeira iteração, o resultado era visivelmente melhor do que a baseline sem prompting; os próprios critérios e a linguagem relacionada já empurravam o modelo para fora dos padrões genéricos, mesmo antes do feedback do avaliador
• Caso do site de um museu holandês: até a 9ª iteração, foi criada uma landing page clean em tema escuro; na 10ª iteração, a abordagem foi descartada por completo e reimaginada como uma experiência espacial com sala 3D renderizada com perspectiva em CSS, piso xadrez, obras penduradas livremente nas paredes e navegação entre galerias por portas — um salto criativo do tipo que não aparecia em geração de passada única

Expansão para codificação full stack

Arquitetura

• No harness de longa execução anterior, consistência em codificação multi-sessão era obtida com agente de inicialização, agentes de codificação por funcionalidade e resets de contexto entre sessões
  • No Sonnet 4.5, o reset de contexto era crucial por causa da ansiedade de contexto, mas no Opus 4.5 esse comportamento foi em grande parte removido, permitindo fazer o build inteiro em uma única sessão contínua sem reset de contexto
  • A compactação automática do Claude Agent SDK lidava com o crescimento do contexto
• Foi configurado um sistema de 3 agentes:
  • Planner: expande um prompt curto de 1 a 4 frases em uma especificação completa do produto — o prompting foca no contexto do produto e no design técnico de alto nível, em vez da implementação técnica detalhada, porque especificar detalhes com antecedência pode propagar erros downstream
    • Ele também recebe instrução para buscar oportunidades de tecer (weave) funcionalidades de IA na especificação do produto
  • Gerador (Generator): pega uma funcionalidade por vez da especificação, sprint por sprint, e implementa com stack React/Vite/FastAPI/SQLite (depois PostgreSQL); ao fim de cada sprint, faz autoavaliação, entrega para o QA e versiona com git
  • Avaliador (Evaluator): usa Playwright MCP para clicar pela aplicação em execução como um usuário real, testando funcionalidade de UI, endpoints de API e estado do banco de dados — atribui notas segundo critérios de profundidade do produto, funcionalidade, design visual e qualidade de código, e a sprint falha se não atingir limiares rígidos por critério
• Antes de cada sprint, gerador e avaliador negociam um contrato de sprint (sprint contract) — chegam a um acordo sobre a definição de “pronto” daquele bloco de trabalho antes de começar a escrever código
  • Como a especificação do produto era deliberadamente de alto nível, esse passo preenchia a lacuna entre user stories e implementações testáveis
  • A comunicação era feita com base em arquivos — um agente escrevia um arquivo, o outro lia e respondia

Resultado da execução do harness: criador de jogos retrô

• O teste usou o prompt: "Crie um criador de jogos retrô 2D com editor de níveis, editor de sprites, comportamento de entidades e modo de teste jogável"
• Agente solo: 20 minutos / US$ 9 vs harness completo: 6 horas / US$ 200 — o harness custou mais de 20 vezes mais, mas a diferença de qualidade do resultado ficou imediatamente clara
• Resultado da execução solo: a tela inicial correspondia à expectativa, mas os problemas apareciam ao clicar — layout desperdiçando espaço, fluxo de trabalho engessado, necessidade de criar sprites e entidades antes sem que a UI orientasse isso, e o ponto central: o jogo em si não funcionava (as entidades apareciam na tela, mas não respondiam a input; a ligação entre definição de entidades e runtime do jogo estava quebrada)
• Resultado da execução com harness: o planner expandiu o prompt de uma frase em 16 especificações de funcionalidade ao longo de 10 sprints — incluindo sistema de animação de sprites, templates de comportamento, efeitos sonoros e música, gerador de sprites assistido por IA, level designer com IA e exportação de jogos por links compartilháveis
  • Ele também leu as habilidades de design de frontend e gerou a linguagem de design visual do app como parte da especificação
  • O canvas ocupava toda a viewport, os painéis tinham tamanho razoável e havia uma identidade visual coerente seguindo a direção de design da especificação
  • O editor de sprites era mais rico e completo, com paleta de ferramentas mais limpa, seletor de cores melhor e controles de zoom mais usáveis
  • A integração de IA acelerava o fluxo de trabalho, gerando diferentes partes do jogo por prompting
• Diferença central no modo de jogo: na execução solo o jogo não funcionava; na execução com harness, era realmente possível mover entidades e jogar — havia alguma aspereza no motor físico (sobreposição entre plataformas e personagem) e limites na composição de níveis por IA (paredes grandes impossíveis de pular), mas a funcionalidade central existia
• O avaliador manteve a implementação alinhada à especificação — já na Sprint 3 havia um contrato detalhado cobrindo 27 critérios só para o editor de níveis
  • Exemplos de issues encontrados: a ferramenta de preenchimento retangular colocava tiles apenas nos pontos inicial e final do arraste; erro condicional no handler da tecla de exclusão de entidades; problema na ordem de rotas do FastAPI que fazia reorder ser interpretado como inteiro e retornar erro 422
• Foi necessário grande esforço para ajustar o avaliador — no estado padrão, o Claude é um péssimo agente de QA, com tendência a encontrar problemas legítimos e depois convencer a si mesmo de que “não era nada demais”, além de perder bugs sutis por fazer testes superficiais
  • Só depois de várias iterações de um loop de desenvolvimento — lendo logs do avaliador, encontrando casos em que o julgamento divergira e atualizando o prompt de QA — foi possível obter uma pontuação razoável

Melhorias iterativas no harness

• Os resultados iniciais foram animadores, mas como o sistema era grande, lento e caro, o próximo passo foi simplificar o harness sem perder desempenho
  • Cada componente do harness codifica uma hipótese sobre aquilo que o modelo não consegue fazer sozinho, e essas hipóteses merecem ser testadas sob estresse — porque podem envelhecer rapidamente à medida que o modelo melhora
  • O princípio era: "encontrar a solução mais simples possível e só aumentar a complexidade quando necessário"
• Tentativas radicais de simplificação não conseguiram reproduzir o desempenho original; como era difícil identificar quais partes realmente sustentavam a carga, mudou-se para uma abordagem sistemática de remover um componente por vez
• O lançamento do Opus 4.6 deu motivação extra para reduzir a complexidade do harness — o modelo passou a planejar com mais cuidado, sustentar tarefas agênticas por mais tempo, operar de forma estável em codebases maiores, revisar e depurar melhor os próprios erros, e a busca em contexto longo também melhorou bastante

Remoção da estrutura de sprints

• A estrutura de sprints foi removida por completo — com as capacidades melhoradas do Opus 4.6, o modelo passou a lidar com o trabalho de forma consistente sem decomposição
• Planner e avaliador foram mantidos — sem o planner, o gerador sofria com escopo insuficiente, começando o build só com o prompt bruto e sem especificação, o que resultava em aplicações com poucas funcionalidades
• O avaliador foi movido de pontuação por sprint para uma única passada no fim da execução
  • Quando a tarefa está dentro da faixa de capacidade solo do modelo, o avaliador vira overhead desnecessário; mas em tarefas na fronteira da capacidade do modelo, ele ainda traz melhora real
  • Portanto, o avaliador não é um “sim” ou “não” fixo: ele vale o custo quando se quer ultrapassar a faixa que o modelo já executa com confiabilidade sozinho
• Também foi adicionado prompting para melhorar a construção de funcionalidades de IA — foram necessárias muitas iterações para fazer o gerador construir agentes adequados que operassem por ferramentas como funcionalidade do próprio app, porque esse conhecimento é recente e a cobertura nos dados de treinamento do Claude ainda é limitada

Resultado do harness atualizado: DAW no navegador

• O teste usou o prompt: "Construa uma DAW completa no navegador usando Web Audio API"
• O total foi de cerca de 4 horas e US$ 124,70
  • Planner 4,7 min / US$ 0,46, build rodada 1 2h07 / US$ 71,08, QA rodada 1 8,8 min / US$ 3,24, build rodada 2 1h02 / US$ 36,89, QA rodada 2 6,8 min / US$ 3,09, build rodada 3 10,9 min / US$ 5,88, QA rodada 3 9,6 min / US$ 4,06
• O builder executou de forma consistente por mais de 2 horas sem decomposição em sprints
• Feedback inicial do agente de QA: a fidelidade de design, os agentes de IA e o backend estavam bons, mas a completude funcional era o principal ponto de falha — não era possível arrastar ou mover clipes na timeline, não havia painel de UI de instrumentos (knobs de synth, pads de bateria), nem editor visual de efeitos (curva de EQ, medidor de compressor)
• Feedback de QA na segunda rodada: gravação de áudio ainda em estado de stub, redimensionamento e divisão de clipes não implementados, e visualização de efeitos reduzida a sliders numéricos em vez de gráficos
• App final: ainda fica abaixo de um programa profissional de produção musical, e a capacidade do agente de compor músicas precisa melhorar; como o Claude não consegue realmente ouvir som, o loop de feedback de QA é menos eficaz em termos de gosto musical
  • Ainda assim, ele tem os elementos centrais de um programa funcional de produção musical, incluindo arrangement view, mixer e transport em funcionamento
  • Foi possível produzir pequenos trechos de música apenas com prompting — o agente definiu andamento e tonalidade, colocou melodias, criou faixa de bateria, ajustou níveis do mixer e adicionou reverb

Perspectivas futuras

• À medida que os modelos melhoram, espera-se que consigam executar tarefas mais longas e complexas; em alguns casos, a importância do scaffold em torno do modelo diminui, de modo que certos problemas podem se resolver naturalmente ao esperar o próximo modelo
• Por outro lado, quanto melhores os modelos, maior também o espaço para desenvolver harnesses capazes de atingir tarefas mais complexas do que a baseline
• Lições principais:
  • Experimentar com o modelo que será usado para build, ler traces em problemas reais e ajustar o desempenho em direção ao resultado desejado são sempre boas práticas
  • Em tarefas mais complexas, decompor o trabalho e aplicar agentes especializados a cada aspecto pode abrir espaço adicional de desempenho
  • Quando um novo modelo é lançado, é boa prática revisar o harness para remover partes que já não sustentam carga de desempenho e adicionar novas partes para alcançar capacidades maiores que antes eram impossíveis
• Mesmo com a melhora dos modelos, o espaço de combinações interessantes de harness não diminui, ele se desloca; o desafio do engenheiro de IA é continuar encontrando a próxima nova combinação