Você Não Governa o Que Não Consegue Ler: o Harness É a Superfície de Controle

Dezenove. Esse é o número de regressões pós-merge que a Anthropic relatou depois de mover cerca de um milhão de linhas de Zig para Rust em menos de duas semanas, com 100% dos testes existentes passando antes do merge. O mesmo modelo que produziu essas 19 regressões havia, numa migração interna anterior, produzido zero. Nada mudou no modelo entre as duas execuções. O que mudou foi o processo ao redor dele: os prompts, as ferramentas, as verificações que um trecho de código precisa passar antes de um humano vê-lo. Esse processo é o harness, e é ele que vale a pena governar.

Dois artefatos surgiram na mesma semana e, lidos juntos, tornam o argumento concreto. A Anthropic publicou um kit testado em campo para rodar migrações de código em larga escala com Claude Code, seis passos que transformam “peça ao modelo para reescrever isso” em um pipeline repetível e inspecionável. Separadamente, pesquisadores da Indiana University e da Tencent publicaram o Harness Handbook, um projeto que mapeia o comportamento documentado de um harness de agentes à sua implementação real, linha a linha, para que um time possa checar se uma garantia alegada é real ou apenas suposta. Um artefato mostra como construir um processo governado. O outro mostra como verificar um que você não construiu. Os dois apontam para a mesma superfície de controle.

O número que aponta para o suspeito errado

Quando uma mudança assistida por IA sai errado, o reflexo é interrogar o modelo. O prompt foi vago demais? Ele alucinou uma API? Essas perguntas importam, mas erram onde a alavancagem de fato está. A migração da Anthropic produziu 6.502 commits de mudança, rodando compilador e suíte de testes como árbitros a cada passo, mais rodadas de revisão adversarial antes de qualquer merge. A economia não foi sutil: cerca de 5,9 bilhões de tokens de entrada e 690 milhões de tokens de saída, uns US$ 165 mil em gasto de API, para mover uma base de código que consumia 6.745 MB de memória ao longo de 2.000 builds para 609 MB, com a matriz de build caindo de 30 minutos para cerca de dois segundos e o binário ficando 19% menor.

O processo é a causa desses resultados. Os testes rodaram a mesma suíte de sempre; o compilador aplicou as mesmas regras de sempre. O que mudou foi que o loop que produzia o código tinha árbitros embutidos antes de qualquer humano olhar um diff. Um caso separado, o de um engenheiro chamado Krieger, portou cerca de 165 mil linhas de Python para TypeScript num fim de semana, gastando cerca de 27 milhões de tokens. Base de código diferente, par de linguagens diferente, mesma disciplina: governe o loop, e o loop escala para migrações que levariam meses de trabalho manual de um time.

O kit de seis passos da Anthropic é um livro de regras, não um prompt mágico

O movimento central no texto da Anthropic não é a chamada ao modelo, é o sequenciamento. Uma migração começa com um livro de regras: como cada idioma da linguagem de origem mapeia para o destino, escrito antes de a implementação começar, para que a resposta exista uma vez em vez de ser reinventada por cada agente que toca a base de código. Depois, a saída do compilador e a suíte de testes existente viram árbitros, verificações mecânicas que um humano não precisa rodar à mão e das quais não dá para convencer o contrário. Depois, agentes de revisão adversarial checam o mapeamento aceito contra o diff real antes de ele poder ser mesclado.

O próprio enquadramento da Anthropic para o princípio é direto: você não conserta o código, você conserta o processo que produziu o código. Isso reformula o que significa uma regressão. Dezenove regressões depois de uma migração de um milhão de linhas não é um veredito sobre a competência do modelo, é uma medida de quão apertados estavam os árbitros do loop nessa execução comparados às execuções em que a contagem foi zero. Se você quer reduzir a contagem de regressões do mês que vem, você aperta o livro de regras ou adiciona um árbitro. Você não troca de modelo na esperança.

Essa é a mesma lógica de governança coberta em o harness era o produto, onde os artefatos eram um arquivo de mapeamento de padrões e uma tabela de lifetimes que deixavam 64 agentes paralelos concordarem sem conversar entre si. O que a Anthropic acrescenta aqui é a economia de tokens: um loop governado não é de graça, e conhecer o custo por linha migrada permite que um time decida se o loop vale a pena antes de comprometer orçamento, em vez de descobrir a conta depois do fato.

O Harness Handbook: auditando o que você não construiu

Um livro de regras funciona quando você controla o harness de ponta a ponta. Poucos times chegam a esse nível de controle. Eles rodam Codex, Claude Code ou outro produto de agente, e o comportamento real do harness, quais ferramentas ele chama, em que ordem, sob quais barreiras, mora dentro de um código que eles nunca escreveram e raramente leem. O Harness Handbook existe porque essa lacuna já é grande o bastante para esconder falhas reais em garantias de segurança. Os pesquisadores por trás dele mapearam o comportamento documentado de um harness em produção contra sua implementação e encontraram 2.267 arquivos, mais de 34 mil funções e mais de 160 mil conexões de código por baixo. Essa é a escala na qual “o harness revisa toda mudança antes do merge” deixa de ser algo verificável lendo um README e passa a ser algo que só se verifica rastreando código.

A contribuição do Handbook é um método para tornar esse rastreamento tratável, ligando um comportamento alegado, “o agente X sempre pede confirmação antes de deletar”, às funções específicas que ou aplicam essa regra ou não. Isso é auditabilidade no sentido literal: não confiar na descrição do fornecedor sobre o harness, mas ter um jeito de checá-la contra o artefato que de fato roda. Junto com o kit da Anthropic, as duas peças cobrem as duas direções do mesmo problema. Construa seu próprio harness, governe-o com um livro de regras e árbitros. Adote o harness de outra pessoa, mapeie o comportamento documentado dele contra a implementação real antes de apostar um fluxo de produção numa alegação que você não verificou.

Por que isso substitui a confiança em nível de modelo

O instinto de avaliar um modelo isoladamente, pontuações de benchmark, alegações de alinhamento, o cartão de segurança de um fornecedor, trata comportamento como propriedade do modelo, o que é um equívoco. O mesmo modelo conectado a um loop com árbitros e revisão adversarial produz confiabilidade diferente do mesmo modelo conectado a um loop sem eles. É por isso que o número de 19 regressões e o número de zero regressões podem ser ambos verdadeiros para o mesmo modelo subjacente: a variável que se moveu foi o harness, não os pesos.

Isso tem uma implicação direta para onde um time deve gastar seu esforço de governança. Auditar um cartão de modelo é um exercício pontual com retornos decrescentes; o modelo não muda semana a semana. Auditar o harness, o livro de regras que ele aplica, os árbitros que ele roda, os portões de revisão antes do merge, é onde o trabalho contínuo de governança de fato compra confiabilidade, porque o harness é o que um time continua mudando conforme escala o uso. As 160 mil conexões de código num único harness são o argumento para por que essa auditoria precisa ser assistida por ferramenta em vez de uma leitura corrida: uma mudança num harness daqui a dois meses pode quebrar silenciosamente uma garantia que existia hoje, e só um mapa de comportamento para implementação vai pegar isso.

Faça isto agora

Antes de escalar qualquer mudança de código conduzida por agente, escreva o livro de regras que ela deve seguir e identifique os árbitros mecânicos, testes, compilador, verificações estáticas, que vão pegar desvio sem um humano no loop. Depois faça a pergunta mais difícil sobre o harness que você de fato está rodando: você consegue apontar o código específico que aplica a garantia de segurança na qual você está confiando, ou você está confiando numa descrição dela? Se você não conseguir responder isso em menos de uma hora, comece a consertar pelo harness.

Fontes

Anthropic. “How Anthropic runs large-scale code migrations with Claude Code.” Julho de 2026.
Indiana University / Tencent. “Harness Handbook: Making Agent Harnesses Understandable, Auditable & Editable.” Junho de 2026.

A Victorino ajuda times a tornar os harnesses de agentes legíveis e auditáveis antes de escalar: contato@victorino.com.br | www.victorino.com.br