Harness engineering: como saber se o código do seu agente de IA está pronto

Harness engineering é a camada de testes que prova, com evidência, se o código escrito por um agente de IA funciona, e não apenas parece funcionar.

Um agente de IA entrega código em minutos. Saber se esse código está pronto para produção continua levando o mesmo tempo de sempre, a não ser que exista uma infraestrutura de teste desenhada para essa velocidade. Harness engineering é a disciplina de construir essa infraestrutura: um conjunto de testes, avaliação em lote e portões de aprovação que verifica automaticamente se o código gerado por um agente está correto, seguro e dentro do escopo esperado, antes de chegar à produção. Na prática, substitui a pergunta “parece certo?” por “passou no teste?”.

Por que revisar código de agente como revisor humano não escala

A Qodo registrou que 89% das organizações já tiveram pelo menos um incidente de produção ligado a código gerado por IA (Qodo, 2026 State of AI Code Quality Report). O mesmo levantamento mostra que 36,4% dos desenvolvedores dizem que revisar código de agente exige mais esforço cognitivo do que revisar código escrito por um colega humano. Faz sentido: um humano segue um padrão mental parecido com o de quem revisa. Um agente gera código plausível com a mesma naturalidade para o caminho certo e para o caminho sutilmente errado.

O reflexo natural é aumentar a revisão manual. O problema é que revisão manual não escala no mesmo ritmo que geração de código. Se um agente produz o volume de dez desenvolvedores, revisar linha por linha exigiria dez revisores só para esse agente. A saída viável é testar de um jeito que não dependa de um humano olhar cada linha de código. Testes automatizados tradicionais, sozinhos, também não bastam: eles validam bem o comportamento esperado e conhecido, e um agente de IA erra com mais frequência fora desse território, no caso de borda que ninguém escreveu como cenário de teste. A avaliação de um harness é feita em camadas, e vamos ver todas mais adiante. Uma delas, a avaliação em lote com golden dataset, existe para cobrir o que o teste unitário sozinho não alcança. 

O mesmo padrão de retrabalho já aparece no método BMAD contra a dívida técnica do vibe coding: estruturar papéis e artefatos de especificação resolve o planejamento, mas não substitui a validação de que o código gerado a partir dali realmente funciona. Harness engineering entra depois, como a camada que fecha essa lacuna quando a especificação e a arquitetura já estão definidas.

As 4 camadas de um harness de testes para agentes de IA

A primeira camada é de testes determinísticos: verifica se a lógica de decisão faz o esperado em casos conhecidos, rodando a cada commit, como um teste unitário tradicional. Se falhar, o build quebra e nada sobe.

A segunda é a avaliação em lote com golden dataset: verifica a qualidade da saída em cenários reais variados, não só no caminho feliz, comparando a resposta do agente contra um conjunto de respostas de referência. Se o score cair abaixo do limiar definido, a entrega não passa.

A terceira é a execução isolada, em sandbox: verifica se o agente ficou dentro do escopo de acesso permitido, rodando em ambiente contido, sem credenciais nem dados de produção. Uma ação fora do escopo é bloqueada antes de qualquer efeito real.

A quarta é o gate de CI/CD por score: verifica se o conjunto de testes e avaliação passou do limiar mínimo antes do merge, bloqueando o pipeline automaticamente, sem depender de aprovação manual. O PR não avança, mesmo que o código pareça correto à primeira vista.

Cada camada resolve um tipo diferente de erro. A camada 1 pega o erro de lógica óbvio. A camada 2 pega o erro que só aparece fora do caminho feliz, como o dado ausente ou a resposta em um formato inesperado. A camada 3 limita o estrago de um agente com acesso maior do que deveria. A camada 4 garante que as três anteriores realmente bloqueiam o deploy, em vez de virar um alerta que alguém ignora sob prazo apertado.

Nem toda camada pede o mesmo nível de investimento em todo agente. As camadas 1 e 4 costumam ser as mesmas para toda a base de código. As camadas 2 e 3, avaliação em lote e sandbox, variam conforme o risco e o domínio de cada agente: um agente que só sugere texto interno precisa de um golden dataset bem mais simples do que um agente com permissão de executar ações em sistemas de produção, onde a execução isolada deixa de ser opcional.

A lacuna de confiança que a maioria ainda não mediu

A CloudBees encontrou uma contradição direta entre percepção e resultado: 81% dos líderes empresariais relatam aumento de problemas de produção ligados a código gerado por IA, e ao mesmo tempo 92% seguem confiantes na prontidão desse mesmo código para produção (CloudBees, 2026 State of Code Abundance Report). As duas coisas convivem porque a confiança nasce da velocidade de entrega, e o problema aparece só depois, no incidente. Harness engineering é o que troca essa confiança por evidência checável antes do deploy.

Essa lacuna cresce mais rápido quando vários agentes trabalham em paralelo, como no modelo de squads que orquestram múltiplos agentes de IA especializados em tarefas diferentes. Cada agente pode passar no próprio teste isolado e ainda assim gerar uma integração quebrada entre os dois. Por isso o harness precisa validar também a interface entre agentes, não só a saída de cada um.

O que muda quando o harness vira parte do processo

Uma equipe que estrutura essas 4 camadas para de perguntar “alguém revisou isso?” e passa a perguntar “isso passou no gate?”. A segunda pergunta tem resposta objetiva, registrada, repetível. A primeira depende de quem revisou, de quanto tempo teve, e de quão cansado estava naquele dia.

Aqui na Maitha, entendemos que o uso de IA no desenvolvimento de software precisou de um novo método de trabalho, e para isso criamos o Synapse Agentic Delivery: um modelo que orquestra agentes dedicados a testes de aceitação e testes técnicos dentro de cada sprint, apoiado no pilar de qualidade, sempre com um gate humano antes de qualquer entrega ir para produção. Harness engineering é um dos pontos centrais desse método: é o que garante que suas iniciativas de IA no desenvolvimento não travem nesse gargalo de validação, e tenham mais chance de chegar à produção com sucesso.