Anthropic Engineering · Labs
Como a Anthropic projeta o arcabouço em torno do modelo para que agentes autônomos construam aplicações full-stack ao longo de horas, sem perder coerência, sem avaliar o próprio trabalho com lenidade, e sem colapsar à medida que o contexto se enche.
Este estudo replica, em português, o artigo original de Prithvi Rajasekaran (time Anthropic Labs) sobre como inspirar-se em Generative Adversarial Networks (GANs) para separar quem gera do quem avalia, como a arquitetura de três agentes (planner, generator, evaluator) produziu aplicações ricas em sessões autônomas multi-hora, e como a evolução do modelo (Opus 4.5 → 4.6) permitiu enxugar radicalmente o harness sem perder desempenho.
Abertura
Nos últimos meses, o autor trabalhou em dois problemas interligados: fazer Claude produzir frontends de alta qualidade, e fazê-lo construir aplicações completas sem intervenção humana. Essa frente nasceu do esforço anterior com a frontend design skill e com o long-running coding agent harness, onde prompt engineering e harness design elevaram o desempenho acima da baseline — mas ambos acabaram esbarrando em um teto.
Para furar o teto, o autor procurou abordagens que valessem em dois domínios muito diferentes: um definido por gosto subjetivo, o outro por correção verificável e usabilidade. Inspirando-se em Generative Adversarial Networks (GANs), desenhou uma estrutura multi-agente com um agente gerador e outro avaliador. Construir um avaliador que pontuasse de maneira confiável — e com bom gosto — exigiu antes desenvolver um conjunto de critérios que transformasse julgamentos subjetivos do tipo "este design é bom?" em termos concretos e graduáveis.
Depois, essas técnicas foram aplicadas a codificação autônoma de longa duração, trazendo duas lições do harness anterior: decompor o build em pedaços tratáveis e usar artefatos estruturados para passar contexto entre sessões. O resultado final foi uma arquitetura de três agentes — planner, generator e evaluator — que produziu aplicações full-stack ricas ao longo de sessões autônomas de múltiplas horas.
Why naive implementations fall short
Já foi mostrado em trabalho anterior que harness design tem impacto substancial sobre a eficácia de codificação agêntica de longa duração. Naquele experimento, um initializer agent decompunha uma spec de produto em uma lista de tarefas, e um coding agent implementava uma feature por vez, passando artefatos entre sessões. A comunidade dev convergiu para insights parecidos — abordagens como o método "Ralph Wiggum" usam hooks ou scripts para manter o agente em ciclos contínuos de iteração.
Ainda assim, alguns problemas persistiam. Em tarefas mais complexas, o agente tende a sair dos trilhos ao longo do tempo. Ao decompor esse problema, duas failure modes comuns foram observadas.
Modelos tendem a perder coerência em tarefas longas à medida que a janela de contexto enche. Alguns modelos também exibem "context anxiety" — começam a encerrar trabalho prematuramente ao se aproximar do que acreditam ser o limite de contexto.
Context resets — limpar totalmente a janela de contexto e iniciar um agente fresco, combinado com um handoff estruturado que carrega o estado do agente anterior e os próximos passos — resolvem ambos os problemas.
Partes iniciais da conversa são resumidas no lugar, para que o mesmo agente continue trabalhando com um histórico encurtado. Preserva continuidade, mas não entrega ao agente uma lousa limpa — e a context anxiety pode persistir.
Fornece uma lousa totalmente limpa. O custo é que o artefato de handoff precisa carregar estado suficiente para o próximo agente retomar o trabalho de modo limpo. Isso resolve o problema central, mas adiciona complexidade de orquestração, overhead de tokens e latência a cada run do harness.
Em testes anteriores, Claude Sonnet 4.5 exibia context anxiety com força suficiente para que compaction sozinha não bastasse. Assim, context resets tornaram-se essenciais ao design do harness naquele cenário.
Quando pedimos ao agente para avaliar o próprio trabalho, ele tende a responder com elogios confiantes — mesmo quando, para um observador humano, a qualidade é obviamente medíocre. O problema é particularmente agudo em tarefas subjetivas como design, onde não existe um teste binário verificável. Se um layout parece polido ou genérico é uma questão de julgamento, e agentes enviesam-se positivamente ao julgar o próprio trabalho.
Mesmo em tarefas com outcomes verificáveis, agentes exibem por vezes julgamento ruim que atrapalha o desempenho. Separar o agente que faz do agente que julga é uma alavanca forte.
A separação, por si só, não elimina imediatamente a leniência — o avaliador ainda é um LLM, inclinado a ser generoso com outputs de LLM. Mas calibrar um evaluator independente para ser cético é bem mais tratável do que fazer o generator criticar o próprio trabalho. Uma vez que existe feedback externo, o generator tem contra o que iterar concretamente.
Frontend design: making subjective quality gradable
O autor começou experimentando em frontend design, onde a patologia de autoavaliação era mais visível. Sem intervenção, Claude gravita para layouts seguros, previsíveis, tecnicamente funcionais mas visualmente apagados.
Dois insights moldaram o harness construído para frontend design:
Este design parece um todo coeso ou uma coleção de partes? Trabalho forte aqui significa que cores, tipografia, layout, imagens e outros detalhes se combinam para criar um humor e identidade distintos.
Há evidência de decisões autorais, ou trata-se de layouts-template, defaults de biblioteca e padrões típicos de geração por IA? Um designer humano deveria reconhecer escolhas criativas deliberadas. Componentes stock inalterados — ou os sinais reveladores de IA, como gradientes roxos sobre cards brancos — falham neste critério.
Execução técnica: hierarquia tipográfica, consistência de espaçamentos, harmonia cromática, razões de contraste. É um check de competência, não de criatividade. A maioria das implementações razoáveis passa por default; falhar aqui significa fundamentos quebrados.
Usabilidade independente da estética. O usuário entende o que a interface faz, encontra as ações primárias e completa tarefas sem adivinhar?
Design quality e originality foram enfatizados sobre craft e functionality. Por default Claude já pontua bem em craft e functionality — a competência técnica necessária costuma emergir naturalmente. Mas em design/originality o modelo frequentemente produz saídas blandas, no melhor dos casos. Os critérios penalizam explicitamente padrões genéricos de "AI slop"; pesar design/originality mais alto empurra o modelo para maior ousadia estética.
O avaliador foi calibrado com few-shot examples contendo breakdowns detalhados de nota. Isso alinhou o julgamento do avaliador às preferências do autor e reduziu a deriva de pontuação entre iterações.
O loop foi construído sobre o Claude Agent SDK, o que manteve a orquestração direta. Um generator criou um frontend HTML/CSS/JS a partir de um prompt do usuário. O autor deu ao evaluator o Playwright MCP, o que permitiu interagir com a página viva antes de pontuar cada critério e escrever uma crítica detalhada.
Na prática, o evaluator navegava pela página por conta própria, fazia screenshots e estudava a implementação com cuidado antes de produzir sua avaliação. Esse feedback voltava ao generator como insumo da próxima iteração.
5 a 15 iterações por geração; cada iteração tipicamente empurrando o generator em direção mais distintiva conforme ele respondia à crítica. Como o evaluator navegava ativamente — em vez de pontuar um screenshot estático — cada ciclo consumia tempo real de relógio. Runs completos esticaram até quatro horas.
O generator também recebeu instrução para tomar uma decisão estratégica após cada avaliação: refinar a direção atual se as notas estivessem melhorando, ou pivotar para uma estética inteiramente diferente se a abordagem não estivesse funcionando.
O wording dos critérios dirigiu o generator de maneiras não totalmente antecipadas. Incluir frases como "os melhores designs são museum quality" empurrou designs para uma convergência visual particular, sugerindo que o prompting associado aos critérios molda diretamente o caráter do output.
Embora as notas geralmente melhorassem ao longo das iterações, o padrão nem sempre era linearmente limpo. Implementações posteriores tendiam a ser melhores como um todo, mas com alguma frequência o autor preferia uma iteração intermediária à última. A complexidade de implementação também tendia a crescer entre rounds, com o generator buscando soluções mais ambiciosas em resposta ao feedback.
Mesmo na primeira iteração, os outputs eram notavelmente melhores que uma baseline sem prompting — sugerindo que os critérios e a linguagem associada por si mesmos já afastam o modelo dos defaults genéricos, antes de qualquer feedback do avaliador.
Scaling to full-stack coding
Com esses achados em mãos, o autor aplicou o padrão inspirado em GAN a desenvolvimento full-stack. O loop generator-evaluator mapeia naturalmente no ciclo de desenvolvimento de software, onde code review e QA cumprem o mesmo papel estrutural que o design evaluator.
The architecture
No harness long-running anterior, havia sido resolvido o problema de codificação multi-sessão coerente com um initializer agent, um coding agent trabalhando uma feature por vez, e context resets entre sessões. Os resets foram um unlock fundamental: o harness usava Sonnet 4.5, que exibia a tendência de "context anxiety" mencionada antes. Criar um harness que funcionasse bem através de context resets era chave para manter o modelo na tarefa.
Opus 4.5 removeu em grande parte esse comportamento por conta própria. O autor pôde então dropar context resets inteiramente deste harness. Os agentes rodaram como uma sessão contínua através do build inteiro, com a compaction automática do Claude Agent SDK lidando com o crescimento de contexto.
Recebe prompt de 1-4 frases → expande em spec de produto ambiciosa. Foco em contexto de produto e desenho técnico de alto nível; detalhes granulares ficam para o runtime.
Trabalha em sprints, uma feature por vez. Stack:
React · Vite · FastAPI · SQLite (depois PostgreSQL).
Autoavalia ao fim do sprint. Tem git para versionar.
Dirige a aplicação rodando via Playwright MCP. Testa UI, endpoints, banco. Cada critério tem threshold duro: se algum cai abaixo, o sprint falha e o generator recebe feedback detalhado.
Persona
O harness anterior exigia do usuário uma spec detalhada upfront. Aqui, o autor quis automatizar esse passo: criou um planner que, a partir de um prompt curto (1–4 frases), expande em uma spec de produto completa.
Instruções: ser ambicioso de escopo, manter foco em contexto de produto e desenho técnico de alto nível — não em detalhes granulares de implementação. A razão: se o planner tentasse especificar detalhes granulares e errasse algum, os erros cascateariam para a implementação downstream. Melhor restringir os deliverables e deixar os agentes descobrirem o caminho.
O planner também recebeu instrução para encontrar oportunidades de tecer features de IA nas specs. Um exemplo está no Apêndice.
Persona
A abordagem one-feature-at-a-time do harness anterior funcionara bem para gestão de escopo. Aqui ela foi aplicada de modo análogo: o generator trabalha em sprints, pegando uma feature por vez da spec.
Cada sprint implementa a aplicação num stack React · Vite · FastAPI · SQLite
(depois PostgreSQL). O generator recebe instrução para
autoavaliar o trabalho no fim de cada sprint antes de passar ao QA. Também tem
git para controle de versão.
Persona
Aplicações de harnesses anteriores pareciam impressionantes mas continham bugs reais quando alguém realmente tentava usá-las. Para pegá-los, o evaluator usa Playwright MCP e clica pela aplicação como um usuário faria — testando features de UI, endpoints de API, estados de banco.
Gradua cada sprint contra os bugs encontrados + um conjunto de critérios modelado no experimento de frontend, adaptado aqui para cobrir profundidade de produto, funcionalidade, design visual e qualidade de código.
Cada critério tem um hard threshold. Se algum cai abaixo, o sprint falha e o generator recebe feedback detalhado do que deu errado.
Antes de cada sprint, generator e evaluator negociavam um "sprint contract": concordar sobre como se parece "pronto" para aquele pedaço de trabalho antes de qualquer código ser escrito.
A razão: a spec de produto era intencionalmente de alto nível, e o autor queria uma etapa para costurar user stories à implementação testável. O generator propunha o que construiria e como o sucesso seria verificado; o evaluator revisava a proposta para garantir que o generator estava construindo a coisa certa. Os dois iteravam até concordarem.
A comunicação acontecia via arquivos: um agente escrevia um arquivo, outro lia e respondia dentro desse arquivo ou com um novo arquivo que o primeiro lia em seguida. O generator então construía contra o contrato acordado, antes de passar o trabalho ao QA. Isso mantinha o trabalho fiel à spec sem super-especificar a implementação cedo demais.
Running the harness
Para a primeira versão deste harness, o autor usou Claude Opus 4.5, rodando prompts do usuário contra o harness completo e um sistema single-agent, para comparação. Opus 4.5 era o melhor modelo de coding quando os experimentos começaram.
"Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."
Prompt usado para gerar o retro video game maker.
O autor esperava uma interface onde pudesse construir um nível e seus componentes (sprites, entidades, layout de tiles) e então apertar play para jogar. Abrindo o output do run solo, a aplicação inicial parecia em linha com essa expectativa.
Ao clicar, porém, problemas começaram a aparecer:
O run com o harness partiu do mesmo prompt de uma frase, mas o passo do planner expandiu isso em uma spec de 16 features espalhadas em dez sprints. Foi muito além do que o run solo tentou. Além dos editores-core e do play mode, a spec pediu:
O autor deu ao planner acesso à frontend design skill, que ele leu e usou para criar uma linguagem de design visual do app como parte da spec. Para cada sprint, generator e evaluator negociaram um contract definindo os detalhes específicos de implementação e os comportamentos testáveis que seriam usados para verificar a conclusão.
O app imediatamente mostrou mais polimento e fluidez que o run solo: o canvas usava toda a viewport, os painéis tinham dimensões sensatas, e a interface tinha uma identidade visual consistente que seguia a direção de design da spec.
Alguma "clunkiness" do run solo permaneceu — o workflow ainda não deixava claro que sprites e entidades precisavam ser criados antes de tentar popular um nível. O autor classificou isso como gap na intuição-de-produto do modelo base, não algo que o harness estivesse desenhado para resolver — ainda que apontasse um lugar onde uma iteração direcionada dentro do harness poderia ajudar.
Lendo os logs, estava claro que o evaluator mantinha a implementação alinhada à spec. A cada sprint, ele atravessava os critérios de teste do contract e exercitava a aplicação rodando via Playwright, abrindo bugs contra tudo que divergia do comportamento esperado. Os contracts eram granulares — o Sprint 3 sozinho tinha 27 critérios cobrindo o level editor — e os achados do evaluator eram específicos o suficiente para serem acionáveis sem investigação extra.
A tabela abaixo mostra vários exemplos de issues identificadas pelo evaluator:
| Critério do contract | Achado do evaluator |
|---|---|
| Ferramenta de Rectangle fill permite click-drag para preencher área retangular com o tile selecionado. |
FAIL
— Tool apenas coloca tiles nos pontos de início/fim do drag, em vez de preencher a região.
Função fillRectangle existe mas não é disparada corretamente no mouseUp.
|
| Usuário pode selecionar e deletar entity spawn points colocados. |
FAIL
— Handler da tecla Delete em LevelEditor.tsx:892 exige que
selection e selectedEntityId ambos estejam setados,
mas clicar numa entidade só seta selectedEntityId. A condição deveria ser
selection || (selectedEntityId && activeLayer === 'entity').
|
| Usuário pode reordenar frames de animação via API. |
FAIL
— Rota PUT /frames/reorder definida depois das rotas
/{frame_id}. FastAPI interpreta reorder como
frame_id integer e retorna 422:
"unable to parse string as an integer."
|
Chegar ao nível em que o evaluator desempenhava assim deu trabalho. De fábrica, Claude é um QA agent ruim. Em runs iniciais, o autor assistia o modelo identificar problemas legítimos e, em seguida, falar sozinho até concluir que não eram grande coisa — e aprovar o trabalho mesmo assim. Ele também tendia a testar superficialmente, em vez de atacar edge cases, de modo que bugs mais sutis escapavam.
O loop de tuning foi:
Levou várias rodadas desse dev loop até o evaluator estar graduando de um jeito razoável. Mesmo assim, o output do harness mostrava os limites da capacidade de QA do modelo: pequenos problemas de layout, interações que se sentiam pouco intuitivas em alguns pontos, e bugs não descobertos em features mais aninhadas que o evaluator não exercitou completamente. Havia headroom claro.
Mas comparado ao run solo — onde a feature central do app simplesmente não funcionava — o ganho era óbvio.
Iterating on the harness
Os primeiros resultados foram encorajadores, mas o harness era também volumoso, lento e caro. O próximo passo lógico era simplificar sem degradar o desempenho. Isso era em parte bom senso e em parte um princípio mais geral:
Cada componente em um harness codifica uma assunção sobre o que o modelo não consegue fazer sozinho, e essas assunções merecem ser estressadas — porque podem estar incorretas, e porque podem envelhecer rapidamente à medida que os modelos melhoram.
O post Building Effective Agents enuncia a ideia subjacente como "encontre a solução mais simples possível e só aumente a complexidade quando necessário". É um padrão consistente para quem mantém harness de agentes.
Na primeira tentativa de simplificar, o autor cortou o harness radicalmente e testou algumas ideias criativas novas — mas não conseguiu replicar o desempenho do original. Ficou também difícil dizer quais peças do design eram realmente load-bearing, e em que sentidos. Baseando-se nessa experiência, passou a uma abordagem mais metódica: remover um componente por vez e revisar o impacto no resultado final.
Durante os ciclos de iteração, Opus 4.6 foi lançado — o que trouxe motivação adicional para reduzir complexidade do harness. Havia boas razões para esperar que 4.6 precisasse de menos scaffolding que 4.5.
Do blog de lançamento: "[Opus 4.6] plans more carefully, sustains agentic tasks for longer, can operate more reliably in larger codebases, and has better code review and debugging skills to catch its own mistakes." Também melhorou substancialmente em long-context retrieval. Todas essas são capacidades que o harness vinha sendo construído para suplementar.
O primeiro corte foi remover o sprint construct inteiro. A estrutura de sprints ajudara a decompor o trabalho em pedaços para o modelo operar de maneira coerente. Dadas as melhorias do Opus 4.6, havia razão boa para acreditar que o modelo daria conta nativamente sem essa decomposição.
O autor manteve planner e evaluator, pois ambos continuavam agregando valor óbvio:
Com o sprint construct removido, o autor moveu o evaluator para um único pass no fim do run, em vez de graduar por sprint. Como o modelo agora era muito mais capaz, isso mudou o quão load-bearing o evaluator era para certos runs: a utilidade depende de onde a tarefa senta em relação ao que o modelo faz solo de modo confiável.
Results from the updated harness
Para testar o harness atualizado, o autor usou o seguinte prompt para gerar uma DAW (Digital Audio Workstation), programa de produção musical no browser para compor, gravar e mixar canções:
"Build a fully featured DAW in the browser using the Web Audio API."
O run foi ainda longo e caro: cerca de 4 horas e US$ 124 em custo de tokens.
A maior parte do tempo foi para o builder, que rodou coerentemente por mais de duas horas sem a decomposição por sprints que 4.5 precisava.
Como no harness anterior, o planner expandiu o prompt de uma linha em uma spec completa. Pelos logs, o generator fez um bom trabalho planejando o app e o desenho do agent, conectando o agent e testando-o antes de passar ao QA.
Ainda assim, o QA agent continuou pegando gaps reais.
"Este é um app forte com excelente fidelidade de design, um agent de IA sólido e um backend bom. O principal ponto de falha é Feature Completeness — enquanto o app parece impressionante e a integração de IA funciona bem, várias features-core de uma DAW estão em modo display-only, sem profundidade interativa: clips não podem ser arrastados/movidos na timeline, não há painéis de UI de instrumento (knobs de synth, drum pads), e nenhum editor visual de efeitos (curvas de EQ, medidores de compressor). Não são edge cases — são as interações core que tornam uma DAW usável, e a spec chama por elas explicitamente."
Gaps remanescentes:
O generator ainda era propenso a perder detalhes ou deixar features em stub quando entregue a si mesmo, e o QA seguiu agregando valor ao pegar essas issues de último quilômetro para o generator corrigir.
What comes next
Conforme os modelos continuam a melhorar, espera-se, em linhas gerais, que sejam capazes de trabalhar por mais tempo e em tarefas mais complexas. Em alguns casos, isso significará que o scaffold em torno do modelo importa menos ao longo do tempo, e desenvolvedores poderão esperar o próximo modelo e ver certos problemas se resolverem sozinhos.
Por outro lado, quanto melhores os modelos ficam, mais espaço há para desenvolver harnesses que alcançam tarefas complexas além do que o modelo faz em baseline.
Acknowledgements
Agradecimentos especiais a Mike Krieger, Michael Agaby, Justin Young, Jeremy Hadfield, David Hershey, Julius Tarng, Xiaoyi Zhang, Barry Zhang, Orowa Sidker, Michael Tingley, Ibrahim Madha, Martina Long e Canyon Robbins por suas contribuições ao trabalho.
Agradecimentos também a Jake Eaton, Alyssa Leonard e Stef Sequeira pela ajuda em moldar o post.
Appendix
Exemplo de plano gerado pelo planner agent a partir do prompt do retro game maker. O plano foi preservado tal como no artigo original — é o artefato de handoff que vai do planner para o generator/evaluator.
RetroForge - 2D Retro Game Maker
Overview
RetroForge is a web-based creative studio for designing and building 2D retro-style video games.
It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive
editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas
to life without writing traditional code.
The platform provides four integrated creative modules: a tile-based Level Editor for designing
game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system
for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By
weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process
—helping users generate sprites, design levels, and configure behaviors through natural language
interaction.
RetroForge targets creators who love retro gaming aesthetics but want modern conveniences. Whether
recreating the platformers, RPGs, or action games of their childhood, or inventing entirely new
experiences within retro constraints, users can prototype rapidly, iterate visually, and share
their creations with others.
Features
1. Project Dashboard & Management
The Project Dashboard is the home base for all creative work in RetroForge. Users need a clear,
organized way to manage their game projects—creating new ones, returning to works-in-progress,
and understanding what each project contains at a glance.
User Stories: As a user, I want to:
- Create a new game project with a name and description, so that I can begin designing my game
- See all my existing projects displayed as visual cards showing the project name, last modified
date, and a thumbnail preview, so that I can quickly find and continue my work
- Open any project to enter the full game editor workspace, so that I can work on my game
- Delete projects I no longer need, with a confirmation dialog to prevent accidents, so that I
can keep my workspace organized
- Duplicate an existing project as a starting point for a new game, so that I can reuse my
previous work
Project Data Model: Each project contains:
Project metadata (name, description, created/modified timestamps)
Canvas settings (resolution: e.g., 256x224, 320x240, or 160x144)
Tile size configuration (8x8, 16x16, or 32x32 pixels)
Color palette selection
All associated sprites, tilesets, levels, and entity definitions
...Trecho preservado conforme o Apêndice do artigo original. O "…" indica continuação da spec além do que foi publicado.
Conclusão
Os pontos abaixo são extrações diretas das posições defendidas no artigo — não são sínteses livres ou inferências nossas. Cada takeaway aponta de volta à seção que o sustenta.
Separar quem gera de quem avalia é uma alavanca forte — não porque elimina a leniência do avaliador, mas porque torna calibrar um avaliador externo cético bem mais tratável do que treinar o gerador a ser cético consigo mesmo.
Com critérios explícitos (design quality, originality, craft, functionality), com pesos deliberados (design + originality > craft + functionality) e com few-shot calibration, um domínio que parece "gosto puro" vira mensurável.
Compaction preserva continuidade, mas não cura context anxiety; reset dá lousa limpa ao custo de handoff artifact robusto. Em Sonnet 4.5, reset era essencial; em Opus 4.5/4.6, compaction automática bastou.
Evaluator não é decisão fixa sim/não. Vale o custo quando a tarefa senta além do que o modelo corrente faz com confiabilidade solo. A fronteira se move a cada modelo.
A negociação entre generator e evaluator antes de escrever código, comunicada via arquivos, costura user stories a comportamentos testáveis sem super-especificar implementação cedo demais.
Cada componente codifica uma assunção sobre o que o modelo não pode fazer sozinho. Essas assunções envelhecem. Quando um modelo novo pousa, revise o harness: stripe o que deixou de ser load-bearing, adicione onde a nova capacidade abriu teto.
O planner mantém foco em contexto de produto e desenho técnico de alto nível. Se tentar especificar detalhes granulares e errar, os erros cascateiam para a implementação. Restringir deliverables, deixar o caminho aberto.
Dar ao evaluator acesso à página viva — e não a um screenshot — transforma "parece bom" em "funciona quando usado". Custa tempo de relógio (até 4h por run), mas expõe falhas de interação invisíveis em análise estática.
Frases como "os melhores designs são museum quality" empurraram o modelo a uma convergência visual particular. O vocabulário do critério não é etiqueta neutra — é direção autoral que o modelo internaliza.
De fábrica, Claude é um QA ruim. O tuning é: ler logs → achar divergência de julgamento → atualizar prompt do QA. Várias rodadas até convergir. Headroom ainda permanece.
Instruir o planner a weave AI features em cada spec faz com que o app gerado já venha com integrações Claude nativas (ex.: gerador de sprite, level designer) que aceleram o próprio workflow do usuário.
A conclusão do autor: "o espaço de combinações interessantes de harness não encolhe com modelos melhores — ele se desloca, e o trabalho interessante para engenheiros de IA é continuar encontrando a próxima combinação novel".