AI BoutiqueAI Driven Transformation

Vozes

Mitchell Hashimoto: conserte o harness, não o prompt

Mitchell Hashimoto, criador do Terraform, chama de harness engineering o hábito de impedir que o agente repita o mesmo erro. O que isso ensina à operação.

Mitchell Hashimoto não é um comentarista de IA, é um engenheiro que construiu ferramentas que boa parte da indústria usa todo dia. Criou o Vagrant, cofundou a HashiCorp e o Terraform, e mais recentemente tocou sozinho o Ghostty, um emulador de terminal que virou queridinho dos desenvolvedores. Quando alguém com essa folha de serviço, e que começou cético em relação à IA, escreve como passou a trabalhar com agentes, vale ouvir. O texto dele, My AI Adoption Journey, entrega um conceito que resume tudo que separa operar IA por sorte de operar por engenharia: harness engineering.

O que ele disse

O ponto de partida de Hashimoto é honesto: ele era desconfiado. Só mudou de ideia depois de um método próprio de adoção, feito de passos concretos, como reproduzir uma tarefa na mão primeiro e depois pedir ao agente que replicasse o resultado, e reservar os últimos trinta minutos do dia para deixar o agente avançar em algo enquanto ele fazia outra coisa. Nada de fé, tudo de teste.

O conceito central aparece quando ele descreve o que faz sempre que o agente comete um erro. A reação instintiva da maioria é reescrever o prompt: explicar melhor, dar mais contexto, pedir de novo. Hashimoto faz outra coisa. Ele para e engenheira o harness, o arreio, a estrutura em volta do agente. Na prática, isso significa mudar o ambiente para que aquele erro específico não possa acontecer de novo: adicionar uma regra no arquivo AGENTS.md do repositório, escrever um teste que quebra quando o agente faz a besteira, criar uma ferramenta programática que valida a saída antes de ela seguir adiante. Ele mesmo admite não saber se existe termo consagrado para isso, e passou a chamar de harness engineering.

A diferença é sutil e enorme. Consertar o prompt melhora uma conversa. Consertar o harness melhora todas as próximas, para qualquer pessoa do time que rodar aquele agente, saiba ela ou não do problema original. O aprendizado deixa de morar na sua cabeça e passa a morar no sistema.

Por que importa

O argumento de Hashimoto ataca o vício mais comum de quem está começando com agentes: tratar cada erro como um acidente isolado, resolvido na base do jeitinho. Você corrige na mão, o agente acerta daquela vez, e três dias depois o mesmo erro volta, com você ou com o colega. É trabalho que não acumula. Cada correção morre no momento em que é feita.

Harness engineering transforma correção em capital. Cada erro vira uma melhoria permanente do ambiente, um guarda-corpo a mais. Com o tempo, o harness fica tão bom que o agente quase não tem como errar naquelas dimensões, porque o espaço para errar foi fechado por construção. É a mesma lógica de engenharia de confiabilidade que a gente já defendeu ao falar de runtime desacoplado para agentes e de ensinar o agente a se avaliar, com Hamel Husain. O agente não fica confiável porque você reza melhor. Fica porque você construiu o ambiente certo em volta dele.

Há um segundo motivo para levar Hashimoto a sério, e é o tom. Em maio de 2026 ele soltou um alerta duro: acredita que há empresas inteiras em plena psicose de IA, a ponto de ser impossível ter uma conversa racional sobre o tema com elas. Vindo de alguém que adotou agentes a fundo, o recado não é anti-IA, é anti-euforia. Adoção séria e psicose de IA são opostos: uma é feita de teste, medição e guarda-corpo, a outra de fé e slide. O mesmo abismo que separa quem coloca IA em produção de quem só a exibe.

Nossa leitura

Concordamos com Hashimoto e queremos puxar o conceito para além do código, porque é ali que ele fica mais valioso para quem opera IA em qualquer produto. Todo agente em produção erra de formas repetidas e previsíveis: inventa um dado, ignora uma regra de negócio, escolhe a ferramenta errada. A pergunta que o harness engineering ensina a fazer depois de cada erro é sempre a mesma: como eu mudo o ambiente para que esse erro se torne impossível, em vez de só pedir de novo com mais jeitinho?

Na prática, isso vira uma disciplina de operação. Toda vez que um agente falha em produção, o time não fecha o chamado com um remendo. Ele pergunta qual guarda-corpo faltou e o constrói: uma validação de saída, uma checagem de fato antes de responder ao cliente, um limite explícito do que o agente pode e não pode fazer, um exemplo canônico fixado no contexto. Cada incidente vira uma regra a mais no harness. É o equivalente, para agentes, do que a verificação sistemática que Simon Willison prega é para o código: a habilidade não está em confiar, está em construir o ambiente que dispensa a confiança cega.

Há um risco de leitura que vale nomear. Harness engineering não é desculpa para paralisar tudo em processo antes de rodar o primeiro agente. O método de Hashimoto é iterativo: você começa, deixa o agente errar em ambiente controlado, e vai fechando as brechas à medida que elas aparecem. O harness cresce com o uso, não antes dele. Quem espera o guarda-corpo perfeito para começar nunca começa.

A lição de Hashimoto, para quem opera IA no Brasil, cabe numa frase: pare de consertar o prompt e comece a consertar o harness. Prompt é conversa, some quando a janela fecha. Harness é engenharia, fica. O time que trata cada erro de agente como uma oportunidade de fechar uma brecha no ambiente constrói, incidente a incidente, um sistema que erra cada vez menos. O que só ajusta o prompt fica preso repetindo as mesmas correções para sempre.

Se você quer transformar os erros dos seus agentes em guarda-corpos permanentes, e montar o harness que deixa a operação confiável, fale com a gente no WhatsApp.

Fontes

Perguntas frequentes

Qual a diferença entre engenheirar o prompt e engenheirar o harness?

Engenheirar o prompt é ajustar a instrução que você dá ao agente naquela conversa. Ajuda ali, mas o ganho evapora quando a conversa acaba ou quando outra pessoa roda o agente sem saber do truque. Engenheirar o harness é mudar o ambiente ao redor do agente para que o erro não aconteça mais: adicionar uma regra no arquivo de instruções do repositório, escrever um teste que falha quando o agente faz besteira, criar uma ferramenta que valida a saída. O aprendizado passa a morar no sistema e vale para todo mundo, sempre.

Isso vale só para agente de código?

Nasceu no código, mas o princípio é geral. Qualquer agente em produção erra de formas repetidas e previsíveis. Em vez de corrigir na mão toda vez, você constrói guarda-corpos: validação de saída, checagem de fato, limites do que o agente pode fazer, exemplos canônicos no contexto. A pergunta que Hashimoto ensina a fazer depois de cada erro é a mesma em qualquer domínio: como eu mudo o ambiente para que esse erro específico se torne impossível?

← Todos os artigos