Harness Engineering: o modelo de AI virou commodity, o que está em volta dela não

Existe uma pergunta que todo mundo faz, "qual modelo de IA é o melhor para escrever código?", e uma pergunta que quase ninguém faz, que é a que decide se você tem um produto: o que segura esse código de pé quando o modelo erra, ou quando muda de comportamento na semana que vem?

A primeira pergunta é divertida e barata de responder. A segunda é chata e cara. Este texto é sobre a segunda, e vou usar um exemplo do começo ao fim.

O que é um harness

Quem programa já conhece a palavra. "Test harness" é a estrutura que segura seu código enquanto ele roda. Monta o cenário, executa, compara o resultado com o esperado, isola a peça que está sendo testada. O código faz o trabalho. O harness é o que faz o erro aparecer cedo, num lugar controlado, em vez de estourar na frente do cliente. Pense no harness como guardrails, medidas de proteção e guias para o agente de AI.

"Harness engineering" é essa mesma estrutura aplicada a todo o trabalho feito com IA. É a estrutura em volta do modelo que torna seguro aceitar a mudança que ele gera. Não é uma ferramenta que você instala, não tem comando para isso, não tem ninguém para vender. É um conjunto de componentes, e a melhor forma de mostrar o que cada um faz é seguir uma mudança real passando por eles.

Uma mudança, sem harness

Imagine o pedido mais banal do mundo. Você diz pro agente: "adiciona cupom de desconto no checkout". Trinta segundos depois ele te entrega um código que compila, roda, e na demo funciona. Você aprova. O que acontece nas próximas 48 horas, sem nada em volta:

O agente criou uma tabela `discounts` novinha. Bonita. Só que o seu sistema já guardava promoção numa tabela chamada `promotions`, e agora você tem duas fontes de verdade que ninguém vai reconciliar. O agente não sabia da `promotions` porque ninguém contou para ele.

O desconto entrou no cálculo antes do frete. Você tinha uma regra de "frete grátis acima de 50 reais", e agora um cupom de 20 por cento derruba o subtotal para baixo de 50 e mata o frete grátis de quem deveria ter. Ninguém percebeu, porque ninguém testou a regra antiga depois da mudança.

O valor do desconto foi salvo como número de ponto flutuante. Na semana seguinte aparece um pedido de 19 reais e 999999 centavos no relatório financeiro, e o time de dados perde uma tarde atrás disso.

E o melhor: dois cupons empilham. Um cliente esperto soma dois códigos e leva 100 por cento de desconto. Você descobre pela planilha de faturamento, três dias depois, quando o estrago já rodou.

Repare que nenhum desses problemas é "o modelo é burro". O modelo fez exatamente o que foi pedido. Um modelo melhor talvez teria feito tudo isso mais rápido e com mais elegância, mas teria feito o mesmo. O que faltou não estava dentro do modelo. Estava em volta.

A mesma mudança, com harness

Agora o mesmo pedido, com a estrutura em volta. Cada componente do harness pega um dos erros de cima, e é assim que você entende o que cada um é, sem decoreba.

Retrieval. Antes de escrever, o agente consulta o seu código e schema reais em vez de inventar a partir da memória de treino. Ele encontra a tabela `promotions` e estende ela, em vez de criar uma `discounts` paralela. Retrieval é o que faz o modelo trabalhar com a sua realidade, não com a imaginação dele.

Testes e caracterização. Você tinha um teste que trava a regra "frete grátis acima de 50". No instante em que o desconto passa a derrubar o subtotal, esse teste fica vermelho e grita. A mudança não chega na sua frente "funcionando". Ela chega com um alarme apontando pro efeito colateral exato.

Review e QA. Um segundo par de olhos faz o code review e vê o desconto salvo como float. "Isso vai dar dízima em dinheiro, usa inteiro em centavos." O review, junto com o QA, é o que faz "parece pronto" virar "é pronto", e pega a classe de erro que passa no teste mas fede para qualquer humano experiente.

CI e rollback. O CI roda os testes a cada mudança, mas o empilhamento de cupons escapa de todo mundo e vai para produção mesmo assim, porque às vezes escapa. A diferença é que existe um botão. O rollback transforma uma noite ruim num revert de cinco minutos, em vez de uma operação de estorno e pedido de desculpas. Deploy ruim vira inconveniente, não incidente.

Responsabilidade. Quando o erro aparece no número de faturamento, existe uma pessoa com nome que é responsável por aquilo. Não "o agente fez". Um humano que olha, decide e responde. Automação sem dono é órfã na primeira vez que erra.

Esses cinco não são uma checklist que eu inventei. São o que separa "funcionou na demo" de "sobreviveu contato com cliente real". E note o que aconteceu com o exemplo: o modelo continuou sendo o mesmo. Tudo que mudou foi a estrutura em volta dele.

Não é opinião minha, é como os times sérios falam

Se isso ainda soa como tese de blog, repare onde quem constrói isso de verdade chegou, partindo de lugares diferentes.

A Anthropic, num texto de engenharia chamado Building Effective Agents, recomenda começar pela solução mais simples que resolve e só aumentar a complexidade quando o problema pedir. E manda cuidar da "interface agente-computador", as ferramentas que o modelo usa, com o mesmo rigor de uma UI para humano. Um laboratório de modelos dizendo que o ganho está na estrutura e nos padrões, não em empilhar capacidade.

A evidência empírica mais limpa vem do SWE-agent, de um time de Princeton/Stanford. Eles pegaram o mesmo modelo e só melhoraram a interface pela qual ele lê, navega, edita e roda código. Só isso levou o modelo a resolver 12,5% das issues reais do SWE-bench na primeira tentativa, muito acima do que o mesmo tipo de modelo entregava sem essa interface. Mesmo cérebro, estrutura melhor, número melhor. É o argumento inteiro virando experimento controlado.

Do lado de quem investe e de quem coloca em produção, o recado bate. Matt Bornstein e Rajko Radovanovic, da a16z, em Emerging Architectures for LLM Applications, tratam o modelo de fundação como peça cada vez mais trocável, com a diferenciação morando na camada de orquestração. E o Hamel Husain, em Your AI Product Needs Evals, defende que o que destrava um produto de IA não é trocar de modelo nem mexer no prompt, é ter um sistema de avaliação automatizada que cria o loop de feedback. Esse sistema de avaliação é parte do harness.

Onde o argumento dói

Se eu parasse aqui seria propaganda. Tem duas objeções fortes, e fugir delas seria desonesto.

A primeira é o Bitter Lesson, do Rich Sutton. A história da IA mostra que métodos gerais que escalam com computação acabam vencendo as estruturas que humanos montam à mão. Lido sobre agentes, vira o seguinte: seu harness é muleta temporária, o próximo modelo absorve metade dele. E é verdade em parte. Em 2023 virou moda montar engenhocas elaboradas em volta do modelo, camada sobre camada de regras e automação, para tentar deixá-lo autônomo. Boa parte disso virou pó quando os modelos melhoraram e um loop simples passou a bastar.

A segunda vem do Simon Willison, que cunhou a lethal trifecta. Quando um agente tem ao mesmo tempo acesso a dado privado, exposição a conteúdo não-confiável e um canal para mandar informação para fora, você tem uma rota de vazamento. E essas três coisas são exatamente o que um harness capaz entrega. A estrutura que te dá poder é a mesma que te dá superfície de ataque.

Levo as duas a sério. E mesmo assim a conclusão não muda. Ela fica mais precisa.

O que o modelo não absorve

O Bitter Lesson come a parte esperta do harness, os truques de prompt e as engenhocas elaboradas em volta do modelo. Ótimo, que coma. Não é disso que eu estou falando.

Volta no exemplo do cupom. O que o próximo modelo, mais esperto, resolve sozinho? Ele inventa menos tabela duplicada, escreve menos bug de float. Talvez ele nem precise tanto de retrieval porque já chega mais ancorado. Mas olha o que ele não te dá de graça: quem aprova o merge, qual o raio de explosão se ele errar mesmo assim, o que dispara o rollback quando o cupom empilha, quem é a pessoa que responde quando o faturamento cai. Modelo melhor não te dá responsabilidade. Ele só faz a mudança não-revisada ficar mais barata, e mudança não-revisada mais barata, sem harness, não é ganho, é passivo que você está escalando. A lethal trifecta do Willison aponta pro mesmo lugar: a resposta não é um modelo mais inteligente, é uma decisão de perímetro, ou seja, no que esse agente pode tocar e para onde ele pode falar.

"Funciona" não é o critério. "Sobrevive contato com cliente real" é o critério. A distância entre os dois é o harness.

A posição

A ferramenta importa menos do que o harness em volta dela. Não porque ferramenta não importe, ela importa e melhora rápido, mas porque a parte que decide se você tem um produto durável é justamente a parte que nenhum modelo novo entrega de graça: retrieval para ancorar, teste para avisar, review para segurar, rollback para desfazer, e um dono para responder.

A medida honesta de maturidade aqui não é "qual modelo você usa". É "quanto da sua casa cai se você trocar de modelo amanhã". Se cair muito, você comprou ferramenta achando que era estrutura.