Agentes de IA trabalhando 6 horas sozinhos — o que a Anthropic descobriu sobre harness engineering

Você pediu para o agente construir uma funcionalidade. Ele parou no meio, entregou um botão pela metade, declarou vitória e seguiu em frente. Isso não é falha pontual — é a natureza de como agentes de IA quebram em tarefas longas. A Anthropic publicou um estudo no início de abril de 2026 detalhando exatamente por que isso acontece e, mais importante, como eles resolveram o problema a ponto de construir aplicações inteiras em janelas de 6 horas contínuas sem intervenção humana.

Trabalho com cybersegurança há 18+ anos, hoje como Senior Cybersecurity Lead na Microsoft com foco em IA aplicada, e tenho usado agentes de código em sessões intensivas de desenvolvimento. Esse problema de agentes que "esquecem", que declaram tarefas prontas quando não estão, e que acumulam dívida técnica silenciosamente — eu vivo isso todos os dias. O estudo da Anthropic não é teoria. É a primeira explicação estruturada de como combater cada uma dessas falhas.

Por que agentes de IA falham em tarefas longas?

A Anthropic identificou três razões fundamentais, e nenhuma delas é particularmente surpreendente para quem trabalha com esses sistemas no dia a dia — mas a clareza com que elas foram documentadas é valiosa.

Memória finita — a amnésia programada

A janela de contexto de um modelo é finita. Quando ela acaba, o agente recomeça do zero. É como contratar um engenheiro que apaga toda a memória toda vez que você sai da sala.

Mas existe um problema mais sutil: mesmo antes de atingir o limite, quanto mais fundo você vai na janela de contexto, menos coerente o modelo fica. Ele vai perdendo o fio da meada, começa a tomar decisões estranhas, e quando percebe que está chegando no limite, entra em uma espécie de pânico — tentando fazer tudo às pressas antes que a memória acabe.

Planejamento inexistente

Por padrão, modelos não planejam bem por conta própria. Eles tentam fazer tudo de uma vez, constroem metade de uma funcionalidade e param, ou criam um componente visual sem nenhuma lógica por trás e declaram que terminaram. Do nosso ponto de vista, é um comportamento completamente desalinhado com o que "pronto" realmente significa.

Autoavaliação comprometida — o engenheiro de obra pronta

Essa é a falha mais traiçoeira. Modelos são péssimos em avaliar o próprio trabalho. Se você pedir para o agente verificar o que acabou de fazer, a tendência natural dele é concordar com tudo: "rodei os testes, tá tudo perfeito." Ele olha para uma funcionalidade incompleta e pensa que parece pronto — afinal, visualmente o resultado pode até parecer bonito.

É o fenômeno da sycophancy — o modelo puxa saco, concorda, e segue em frente. A bola de neve de dívida técnica vai crescendo silenciosamente a cada iteração.

A evolução: de 10 minutos para 30 horas

Boris Power, criador do Claude Code, disse algo que coloca essa evolução em perspectiva: há um ano, o Claude mal conseguia escrever comandos básicos sem errar. Era totalmente incapaz de trabalhar de forma autônoma por mais de 10 minutos. Hoje, quase todo o código do Claude Code é escrito pelo próprio Claude Code, em sessões que duram dias.

A linha do tempo de evolução que a Anthropic apresentou:

• Sonnet 3.7 — no máximo 1 hora de trabalho autônomo
• Opus 4.5 — benchmark de 30 horas
• Opus 4.6 — 12 horas no teste padrão, e muito mais com estrutura de apoio

O ponto central: a estrutura de apoio não desaparece quando os modelos ficam melhores. Ela evolui junto com eles. Modelo e estrutura crescem juntos, sempre.

O que é harness engineering?

Essa estrutura de apoio tem nome: harness engineering. É o conceito que está por trás da diferença entre um agente que entrega um botão quebrado e um agente que constrói um jogo funcional em 6 horas.

A ideia é inspirada em redes neurais adversariais (GANs). O conceito base é simples: você tem um agente gerador que cria e um agente crítico que avalia. A tensão entre os dois é o que produz qualidade.

A Anthropic pegou esse conceito e aplicou a agentes de IA de código:

• Construtor — cria o código, programa a funcionalidade, constrói a interface
• Avaliador — não lê apenas as mudanças de código. Ele abre o navegador, entra na página em funcionamento, clica nos botões, testa o que foi construído e emite uma nota

Por que não basta pedir pro agente checar o próprio trabalho?

Porque calibrar um crítico severo é muito mais fácil do que calibrar um construtor que faz autocrítica.

A analogia é direta: é mais fácil olhar um quadro e dizer se está bonito do que pintá-lo. É mais fácil provar um prato e avaliar do que cozinhar. O avaliador nunca participou do processo de construção — ele chega com o trabalho feito e avalia sem viés. É o famoso "engenheiro de obra pronta" — mas aqui, pela primeira vez, esse papel é produtivo.

Como a Anthropic mede qualidade subjetiva?

Uma objeção comum: "qualidade visual é abstrata, não dá para medir." A Anthropic discorda. Eles criaram uma tabela de critérios com quatro dimensões:

1. Aparência — como o produto se parece visualmente
2. Originalidade — se foge da estética genérica de IA (aquele visual roxo padrão que todo site gerado por Claude tem)
3. Acabamento — atenção a detalhes, polimento
4. Funcionamento — se faz o que deveria fazer

Os pesos variam conforme o modelo. Para o Opus 4.6, que é tecnicamente avançado, aparência e originalidade recebem peso maior — justamente para combater a estética genérica.

O avaliador é calibrado com exemplos de referência — sites que a equipe considera bons — até que o julgamento do agente converja com o julgamento humano. Essa tabela de critérios se torna parte da estrutura permanente e é reutilizada entre projetos.

Definição de pronto — negociada antes de escrever código

Nas abordagens anteriores, o fluxo era simples: planejar → executar contra o plano. Ninguém questionava o plano.

Na abordagem da Anthropic, antes do construtor escrever uma linha de código, os dois agentes negociam o que "pronto" significa. O conceito de definition of done aplicado a agentes:

• O construtor propõe: "Criei a funcionalidade X. Você testa fazendo Y."
• O avaliador responde: "Esse escopo pode ser grande demais. Esses testes são fracos. Você esqueceu deste caso extremo que pode quebrar."

Os dois agentes lêem e escrevem arquivos salvos em disco — é assim que interagem. Cada um mantém seu contexto limpo enquanto compartilham informação estruturada.

O teste: jogo retrô com e sem harness

Para demonstrar a diferença, a Anthropic usou os dois métodos para construir um jogo retrô estilo Pac-Man com 27 critérios de avaliação bem especificados.

Sem harness engineering (modo padrão):

• Tela de abertura bonita
• Editor do jogo não funcionava
• Modo de jogo não respondia a teclas
• Física inexistente — personagem colidia com paredes e nada acontecia
• O jogo parecia pronto, mas não estava

Com harness engineering (construtor + avaliador):

• O agente nomeou o produto — deu um nome próprio ao jogo
• Paleta de cores cuidadosa, visualmente coerente
• Painel de depuração em tempo real
• Física funcional — personagem se move, colide, interage
• Jogo construído em 6 horas de trabalho autônomo

O modelo de linguagem era o mesmo — Opus 4.6 nos dois casos. A diferença foi inteiramente a estrutura de harness.

O que fazer agora — 5 práticas para aplicar hoje

1. Use um avaliador separado

Crie um agente com papel diferente, prompt diferente, contexto diferente. A separação entre quem constrói e quem avalia é o que diferencia uma demonstração bonita de um sistema que funciona.

2. Compactação de contexto não é coerência

Resumos com perda de informação acumulam erro ao longo do tempo. Passagem estruturada entre agentes com contextos limpos funciona melhor do que um contexto gigante resumido.

3. Qualidade subjetiva é mensurável

Se você tem uma opinião firme sobre como algo deveria ser, escreva e documente. Transforme em critério explícito. A diferença nos resultados é real e visível — o estudo da Anthropic comprova isso com dados.

4. Leia o que o agente realmente faz

Não existe atalho. O mesmo raciocínio que você usa para ler uma pilha de erros em um sistema de produção vale aqui. Confiar cegamente na saída do agente é receita para acumular dívida de compreensão.

5. A estrutura de apoio muda com o modelo

O que era necessário no Opus 4.5 talvez não seja necessário no 4.6. Fique atento: quando você muda de modelo, revise se dá para remover ou ajustar partes do harness. A estrutura evolui junto — não é estática.

Se você trabalha com agentes hoje ou vai trabalhar em breve, essa separação entre construtor e avaliador é o divisor de águas. Não é sobre ter o modelo mais inteligente — é sobre montar a estrutura certa ao redor dele.

Este artigo foi gerado a partir do meu vídeo no YouTube. Assista a versão completa para ver os exemplos visuais e a demonstração do jogo construído pelos agentes.