O que é Harness Engineering e por que ele importa agora?
A camada do fluxo de desenvolvimento que valida o que a AI produz
Um desenvolvedor que abria dois pull requests por dia agora abre cinco. O volume subiu. A entrega pro negócio, não tanto.
A fila de review cresceu, o QA está devolvendo mais, e o tempo que a AI economizou na codificação reapareceu inteiro na validação. O gargalo não sumiu, ele se moveu.
A reação natural é investir numa spec melhor. Faz sentido: quanto mais claro o que precisa ser feito, menos o agente erra. E a spec importa, ela é condição de funcionamento quando você opera com AI.
Mas ela tem um limite. Spec orienta antes. Ela não confere o que foi produzido.
Mesmo com uma spec impecável, sobra a mesma pergunta sem resposta: como você confia no que o agente entregou sem revisar tudo na mão?
Essa é a pergunta que em 2026 virou disciplina. Tem nome: Harness Engineering.
Mas afinal, o que é Harness Engineering?
O termo apareceu em fevereiro de 2026 em dois momentos seguidos.
Mitchell Hashimoto, co-fundador da HashiCorp e criador do Terraform, publicou um post descrevendo um hábito que havia desenvolvido trabalhando com agentes: toda vez que um agente cometia um erro, ele criava uma solução permanente no ambiente para que aquele erro nunca se repetisse. Poucos dias depois, Ryan Lopopolo, engenheiro da OpenAI, publicou “Harness Engineering: leveraging Codex in an agent-first world” com os números de um experimento de 5 meses: um produto inteiro em produção, um milhão de linhas de código, zero escritas por humanos. A síntese do projeto: “Humans steer. Agents execute.”
O que os dois estavam descrevendo tem um nome simples. O Harness é o ambiente que você constrói em volta do modelo.
É o conjunto de sistemas que determina onde o agente opera, o que ele pode fazer, o que você consegue enxergar e o que acontece quando algo dá errado. O motor é o modelo. O Harness é o carro ao redor.
O peso do Harness fica claro quando olhamos o que falta sem ele. Sem um ambiente que valide o trabalho da AI, três problemas aparecem com frequência:
A revisão na mão deixa de escalar, e quem validava output olhando o diff vira o gargalo quando o volume de código dobra.
O agente é um juiz ruim de si mesmo, porque tende a aprovar o próprio trabalho com confiança mesmo quando a qualidade não está lá, o mesmo viés que a gente tem como humano.
O entendimento se perde no caminho, e esse passivo tem nome, débito cognitivo, a noção do que está sendo construído some aos poucos até ninguém conseguir explicar com segurança por que o sistema funciona.
O Harness ataca esses três pontos, e na prática ele se apoia em dois movimentos que trabalham juntos.
Guides, que orientam antes. São os controles de feedforward, que agem antes da AI produzir. Padrões, contratos e referências do projeto.
Sensors, que checam depois. São os controles de feedback, que agem depois que a AI produz. Linters, testes e revisões que conferem o resultado de forma automática.
Esses dois movimentos, guias e sensores, são a base do que um conteúdo publicado no Martin Fowler, onde o Harness é descrito como uma forma específica de engenharia de contexto, voltada justamente pra aumentar a confiança no que o agente entrega.
A parte que mais pesa nesse desenho é separar quem gera de quem valida.
Em vez de pedir pro mesmo agente escrever e aprovar, você coloca um segundo agente, num processo separado, pra avaliar o trabalho do primeiro. Segundo a Anthropic, calibrar um avaliador pra ser cético é mais simples do que tornar o gerador crítico do próprio trabalho, e quando esse avaliador existe, o gerador passa a ter algo concreto pra corrigir a cada rodada.
O detalhe importante pra liderança é pra onde a disciplina migra com o Harness.
O humano para de iterar no código e passa a iterar no ambiente. Quando um erro se repete, você não corrige aquela linha, ajusta o guia ou o sensor pra que ele não volte. A atenção sai do output e vai pra estrutura que produz o output
Tem uma parte disso que não cabe inteira por aqui, que é como decidir até onde dar autonomia pro agente sem perder o controle. Guiei um papo esses dias justamente sobre essa calibração, deixo o acesso do video aqui pra quem quiser se aprofundar: https://share.hsforms.com/1In3fwXpjQNyfet9cpLQAJg348sw
Onde o Harness se encaixa no fluxo de desenvolvimento?
O fluxo de desenvolvimento de software de ponta a ponta, da intenção até a entrega em produção, ganha três camadas quando passa a operar com AI. Elas se acumulam em vez de se substituir, e cada uma responde a uma pergunta diferente.
Juntas formam a escada Spec, Context e Harness.
A primeira camada, Spec First, responde o que precisamos fazer. É onde vivem o PRD, os épicos e as decisões, o conjunto vivo de artefatos de intenção.
A segunda de Context Engineering, que responde como fazemos aqui. Arquivos de referência, padrões do projeto, as skills e o conhecimento que vive no repositório, o que faz a AI operar do jeito daquele time em vez de operar com premissas genéricas.
A terceira é o Harness Engineering, que responde como confiamos no que foi produzido sem revisar cada linha. É a camada menos estruturada na maioria dos times, e é onde mora o problema que a gente abriu.
A maior parte das empresas chegou na primeira ou na segunda camada. Escreveram boas Specs, carregaram contexto, e mesmo assim seguem revisando tudo na mão, porque o Harness nunca foi construído. Faltou redesenhar essa parte do sistema, e é nela que vamos entrar aqui.
O que o teste da Anthropic revela sobre o Harness?
Num teste publicado pela Anthropic, a mesma feature foi construída de dois jeitos.
No primeiro, um agente sozinho, sem Harness. No segundo, com o ambiente completo de geração e validação por trás.
O agente solo terminou em 20 minutos e custou 9 dólares. A versão com Harness levou 6 horas e custou 200 dólares, mais de vinte vezes mais cara.
A versão solo entregou uma aplicação que parecia pronta, mas cuja função central não funcionava quando alguém ia de fato usar. A versão com Harness entregou algo que funcionava.
O barato da versão solo é ilusório, porque o custo que pareceu baixo na hora reaparece depois, em hora humana consertando o que veio quebrado, e esse conserto sai mais caro do que o que se gastou pra gerar o código. A versão com Harness custa mais na geração, mas você não paga a conta do retrabalho na frente.
O que o teste mostra é que o Harness funciona, e funciona onde importa.
A diferença de qualidade veio do sistema de validação conferindo o que o modelo escreveu. Foi esse ambiente que pegou o erro invisível e separou uma entrega que se sustenta de uma que só parecia pronta.
Em qual degrau da escada o seu time parou?
Antes de tentar dar mais autonomia pra AI, vale fazer um diagnóstico honesto.
Se o seu time já escreve boas Specs e carrega contexto, mas ainda revisa cada entrega na mão com receio do que pode ter passado, o degrau que falta é o do Harness. A especificação está resolvida, o contexto também, e o que trava é a confiança no output.
O que no seu fluxo hoje garante que o código gerado está certo sem depender de alguém revisando tudo, linha por linha?
 | Uma publicação convidada por
|