O que é harness engineering?
A capacidade de um agente de IA não depende apenas do modelo de linguagem, mas também da infraestrutura responsável por sua execução.
Antes de tudo, vale uma reflexão: quando um agente de IA falha ao realizar uma tarefa de desenvolvimento de software, onde está o problema? Na maioria das vezes, parece que o modelo ainda não é “inteligente” o suficiente. Se fosse, o modelo capaz de raciocinar melhor, compreender projetos/classes maiores ou planejar sequências mais longas de ações. Esses erros desapareceriam naturalmente.
Essa forma de pensar direcionaram boa parte da evolução recente dos modelos de linguagem. Modelos maiores, janelas de contexto maiores e novas técnicas de treinamento buscaram ampliar as capacidades dos modelos. Por outro lado, em vez de atribuir o sucesso (ou fracasso) de uma tarefa exclusivamente ao modelo, a capacidade de um agente emerge da interação entre três componentes: o modelo, o ambiente e uma camada intermediária chamada harness.
O que é um harness?
O harness é a infraestrutura de execução que envolve um modelo de linguagem durante a realização de uma tarefa. É essa camada que determina como o agente observa um projeto, quais informações recebe como contexto, quais ferramentas pode utilizar, como interpreta o retorno de suas ações e quais evidências utiliza para concluir que uma tarefa foi realmente finalizada.
O harness é uma plataforma com vários componentes; o modelo é apenas um deles.
O modelo deixa de ser visto como o único responsável pelo comportamento do agente. Da mesma forma que um desenvolvedor depende de IDEs, sistemas de versionamento, ferramentas de teste e documentação para realizar seu trabalho, um agente também depende de uma infraestrutura que organize sua interação com o ambiente.
Sob essa perspectiva, um modelo extremamente capaz pode ter desempenho mediano quando executado sobre um harness limitado. Da mesma forma, melhorias no harness podem aumentar significativamente a confiabilidade do sistema sem qualquer alteração no modelo utilizado.
Mais do que uma camada de integração
À primeira vista, pode parecer que o harness seja apenas uma camada responsável por conectar o modelo às ferramentas disponíveis. Não somente.
O harness é responsável por diversas funções fundamentais durante todo o ciclo de vida de uma tarefa. Vai desde a especificação da tarefa, a seleção de contexto, o acesso às ferramentas, o gerenciamento da memória do projeto, o acompanhamento do estado da tarefa, a observabilidade da execução, a atribuição de falhas, os mecanismos de verificação, o controle de permissões, a auditoria de entropia e o registro das intervenções realizadas durante a execução. Muita coisa, muito detalhe.
O harness ajuda a organiza toda a interação entre o modelo e o ambiente de desenvolvimento.
A capacidade emerge do sistema
Tradicionalmente, costuma-se avaliar um agente observando apenas sua saída final. Se ele produziu um patch correto, considera-se que foi bem-sucedido. Caso contrário, conclui-se que o modelo tem limitações.
No entanto, a capacidade de um agente é uma propriedade do sistema completo formado pelo modelo, pelo harness e pelo ambiente. Isso significa que falhas podem estar relacionadas não apenas ao raciocínio do modelo, mas também à forma como o contexto foi construído.
Níveis de Harness
Para tornar essa ideia mais concreta, existe inclusive uma classificação composta por quatro níveis de harness, denominados H0 até H3.
H0: Produz apenas o resultado final (por exemplo, um patch), com pouca ou nenhuma evidência sobre sua execução.
H1: Adiciona registros básicos da execução, permitindo reproduzir as ações realizadas pelo agente.
H2: Incorpora mecanismos de verificação e atribuição de falhas, aumentando a confiabilidade dos resultados.
H3: Produz um pacote completo de evidências (episode package), reunindo contexto, execução, verificações e rastreabilidade para auditoria e reprodução.
O aspecto interessante dessa classificação é que ela não mede a inteligência do modelo. Ela mede o nível de suporte oferecido ao agente durante sua execução. Conforme o harness evolui, cresce também a quantidade de evidências produzidas para justificar e validar as mudanças realizadas.
A avaliação de qualidade vai além da resposta do modelo
Essa visão também leva a uma mudança na forma de avaliar agentes de código.
Em vez de considerar apenas se uma tarefa foi concluída com sucesso, podemos registrar toda a trajetória de execução em um pacotão de logs. Com os logs, podemos, analisar não somente o resultado final, mas como o agente chegou ao resultado, quais decisões tomou, quais verificações realizou e quais falhas foram identificadas ao longo do processo.
Competindo com as big techs?
Durante muito tempo, a pergunta que muitos pesquisadores e praticantes faziam era se um modelo de linguagem seria capaz de produzir o código correto. Agora a pergunta é outra: a plataforma de harness consegue produzir um código correto, verificável e passível de manutenção?
Aqui abre um espaço para laboratórios e empresas que estão longe da saude financeira das bigtechs, uma vez que não precisamos concentrar os esforços em aumentar a capacidade dos modelos. Podemos, por outro lago, nos preocupar em criar uma infraestrutura que sustenta sua execução (de modelos menores, mais baratos ou mais rápidos).


A parte que mais me pegou é a que menos aparece no debate de modelo: os níveis H2 e H3. Quem constrói software para banco reconhece isso na hora, verificação, atribuição de falha e episode package não são luxo de observabilidade, são o que um regulador exige antes de deixar um sistema decidir crédito ou bloquear uma transação. Um modelo "genial" sobre um harness H0 é exatamente o que a auditoria reprova: acertou o resultado e não sabe dizer por quê. Sua tese de que a capacidade emerge do sistema, e não do modelo, é a forma técnica de dizer uma coisa que o mercado ainda resiste a aceitar: confiabilidade se projeta na camada de execução, não se espera do próximo release. Ótimo texto!