Harness Engineering está se tornando muito comum em times com agentes autônomos atualmente pela sua capacidade de revisão. Entre o momento em que você aperta o play e o momento em que volta para conferir o resultado, muita coisa pode acontecer. Como garantir que o agente fez exatamente o que deveria, e fez direito? Por isso, neste artigo, baseado no episódio #268 do nosso podcast Entre Chaves, reunimos os principais aprendizados sobre o tema.

O que é Harness Engineering?

O termo nasceu em fevereiro de 2026, quando Mitchell Hashimoto, criador do Terraform, publicou nas redes sociais um hábito simples. Toda vez que seu agente errava, ele projetava uma correção permanente para aquele tipo de erro, batizando o hábito de engineering the harness. Em poucas semanas, OpenAI e Anthropic já publicavam seus próprios estudos sobre o assunto.

Harness, na prática, é tudo o que existe fora do modelo em si. Ou seja, são os guias de contexto, as memórias, as ferramentas, os MCPs, os linters e as suítes de teste. É toda a infraestrutura que cerca a LLM e determina se ela vai produzir um trabalho melhor ou pior do que conseguiria sozinha, respondendo a uma chamada de API crua.

De onde vem esse conceito

Essa não é a primeira tentativa de resolver o problema. Antes de virar pauta corporativa, devs já rodavam variações do Ralph Wiggum. É um loop simples, em que a IA refaz e testa a mesma tarefa repetidas vezes até chegar a um resultado aceitável. Assim, o conceito formaliza essa prática artesanal, transformando-a em processo replicável.

A evolução também acompanha uma linha do tempo conhecida por quem trabalha com IA generativa. Primeiro veio a Engenharia de Prompt, focada em escrever bons comandos. Em seguida, veio a Engenharia de Contexto, para garantir que o modelo tivesse a informação certa. Agora é a vez do Harness Engineering, que resolve a lacuna seguinte. Nesse novo estágio, o desafio é sustentar a execução correta por horas ou dias, sem que o agente perca o rumo.

O experimento que colocou o conceito à prova

Em novembro de 2025, a OpenAI conduziu um teste que se tornou referência no tema. Partiram de um repositório GitHub completamente vazio, sem uma linha de código pré-escrita. A CI, sigla para integração contínua, o processo automatizado que roda testes e checagens a cada mudança de código, foi configurada pela própria IA. O mesmo aconteceu com a estrutura de pastas, as regras de formatação, o gerenciador de pacotes e até o arquivo de instruções para os agentes. Tudo usando o Codex CLI com GPT-5.

Meses depois, o resultado era uma aplicação com mais de um milhão de linhas de código, produzida inteiramente por IA, sem nenhum código base para ancorar as decisões. Além disso, a equipe entregou o projeto em cerca de 10% do tempo estimado originalmente.

As peças que sustentaram o experimento

A infraestrutura que a OpenAI montou combinava guias e sensores. Como guias, um arquivo de instruções para os agentes, uma arquitetura em camadas com direção única de dependência e convenções de nomenclatura já codificadas. Como sensores, linters customizados, testes estruturais e um protocolo de DevTools do Chrome para testes de navegador. Havia também uma stack de observabilidade local, capaz de cruzar logs de execução com o próprio modelo. Por cima disso, LLMs atuando como juízes e um agente dedicado só a revisar código.

O que isso revela

O experimento não prova que revisão humana virou dispensável em qualquer contexto. Mas prova que é possível sustentar produção de código em escala sem intervenção linha a linha. Isso acontece quando a infraestrutura ao redor do agente reúne guias claros, ferramentas de validação e um ciclo de retroalimentação consistente.

Como um harness funciona na prática

Um harness bem projetado combina dois tipos de sensores, e a ordem entre eles importa. Ferramentas computacionais, como linters, análise estática e testes unitários, rodam em CPU e são rápidas e baratas. Já as ferramentas por inferência, como LLMs atuando como juízes, rodam em GPU e custam mais caro, em tempo e em dinheiro.

A lógica é a mesma das pirâmides de teste. Você roda primeiro o que é rápido e barato, e só escala para inferência quando o que é determinístico já não é suficiente. Assim, esse funil evita gastar ciclos caros de GPU em problemas que um linter resolveria em milissegundos.

O problema do validador otimista

Times que tentaram usar um agente para validar o trabalho de outro esbarraram num padrão conhecido. Modelos avaliadores tendem a ser complacentes e aceitam entregas que não cobrem todos os casos. Aliás, a Anthropic descreve esse comportamento como resultado do próprio treinamento por aprendizado por reforço, que empurra o modelo para respostas positivas.

Para lidar com isso, a solução encontrada foi treinar avaliadores adversariais, inspirados em redes GAN (Generative Adversarial Network), desenhados especificamente para contestar a entrega em vez de aprová-la por padrão.

Contratos de teste entre agentes

Um padrão vem se repetindo em implementações reais. Antes de o agente de implementação escrever qualquer código, ele negocia com um agente de QA separado um contrato de teste, documentado em Markdown. Só depois de os dois concordarem com os critérios é que a implementação começa.

Como o agente de QA opera em outro contexto, sem histórico da implementação, ele testa com isenção, sem o viés de quem escreveu o código. Se algum item do contrato falha, a tarefa volta para o agente implementador com o motivo específico da falha.

As três camadas de validação do harness

Um harness maduro costuma cobrir três frentes complementares. A primeira é a manutenibilidade do código. A análise estática resolve duplicações óbvias, mas duplicações mais sutis exigem um code review feito por LLM.

A segunda é a validação arquitetural, que checa se uma camada está sendo furada ou se a camada de apresentação está acessando dados diretamente. Aqui entram as fitness functions, complementadas por uma segunda camada de análise via modelo.

A terceira é o comportamento do código gerado, o equivalente ao antigo QA manual. Nessa camada, o que importa é verificar se o app responde como esperado, se a mensagem certa aparece na tela e se o fluxo se comporta como especificado.

Controlando o custo de tokens com progresso persistido

Um desafio recorrente em harnesses com múltiplos agentes conversando entre si é o consumo de tokens. Ele cresce rápido quando cada rodada de teste e correção reprocessa todo o contexto do zero. Para reduzir esse custo, uma solução observada em implementações reais foi criar um arquivo de progresso por tarefa. Esse arquivo era atualizado continuamente pelo agente de implementação, registrando o que foi feito e qual foi o raciocínio aplicado.

Quando uma tarefa volta do QA com uma falha, o agente implementador consulta esse histórico de progresso em vez de reconstruir o contexto inteiro. Ele localiza rapidamente em qual etapa do raciocínio o problema provavelmente está, corrige e segue. O ganho em tokens economizados é direto, porque elimina a necessidade de reabsorver contexto repetidamente.

O que muda no papel do engenheiro

A função do engenheiro se desloca de revisar cada linha de código para garantir que a infraestrutura em si produza qualidade de forma consistente. Em vez de corrigir um bug pontual direto no código, o movimento passa a ser outro. É identificar por que o agente errou e ajustar o harness para que aquele tipo de erro não se repita. É a mesma lógica do post que deu origem ao termo.

A métrica substitui a leitura linha a linha

Uncle Bob, criador do conceito de Clean Code, resumiu essa mudança de forma direta em um post recente. Ele afirma que não revisa mais o código escrito por seus agentes. Em vez disso, mede cobertura de código, complexidade ciclomática, tamanho de módulos e testes de mutação para inferir qualidade. A leitura linha a linha fica de lado, em nome de produtividade. Faz sentido dentro dessa lógica. Se as métricas certas estão instrumentadas e falham quando deveriam falhar, ler cada linha deixa de ser o único jeito de confiar no resultado.

Escrever para o agente, não para o humano

Isso exige uma mudança de hábito real. Então, especificações deixam de ser escritas pensando em quem vai ler o código depois, um humano. Passam a ser escritas pensando em quem vai executar e dar manutenção nele, o agente. A forma de descrever requisitos, contratos de teste e critérios de aceite muda quando o leitor principal da especificação não é mais uma pessoa. Um Spec Driven bem escrito para humanos pode ser ambíguo demais para um agente decidir sozinho o que testar, e é aí que boa parte das infraestruturas mal projetadas falha.

Quanto custa construir um harness robusto

Um harness completo tem um custo real, e não é pequeno. De fato, testes internos da Anthropic mostraram um aumento de até 20 vezes no custo computacional de uma tarefa. A comparação foi feita com um agente rodando de forma totalmente autônoma, sem as camadas de validação.

A conta, porém, precisa considerar o custo de não ter esse tipo de estrutura. Retrabalho, código descartado e vulnerabilidades que chegam à produção também custam caro. A Stripe descreve essa equação de um jeito direto. Enquanto a atenção do desenvolvedor continuar sendo o recurso mais escasso, a conta favorece a automação. Vale mais a pena pagar por computação do que consumir tempo humano em tarefas que podem ser paralelizadas por agentes desatendidos.

Harness Engineering é o próximo passo, não o fim da revisão

Harness Engineering não elimina a necessidade de qualidade. Na verdade, desloca onde ela é garantida. O trabalho deixa de ser revisar cada entrega no final. Logo, passa a ser instrumentar o ambiente inteiro, os guias, os contratos, as ferramentas computacionais e os avaliadores adversariais que sustentam o ciclo.

Times como OpenAI, Anthropic e Stripe relatam ganhos de produtividade expressivos com essa abordagem. Isso porque, o investimento é proporcional à complexidade do sistema, e projetos legados exigem mais iteração do que aplicações greenfield para chegar a um harness confiável.

Enfim, a pergunta que vale levar para o seu time não é se vale a pena investir em Harness Engineering. É o que você faz quando o seu agente errar de novo. Você vai corrigir a linha de código, ou vai corrigir o harness que deixou aquele erro passar?