Quando falamos de harness engineering, muitas vezes algumas dúvidas pairam no ar: por que isso seria relevante pra mim? O que de fato é esse harness para que eu possa engineer ele?
Antes de mais nada, precisamos separar o conceito de modelo de agente. O modelo é o “cérebro” da sua aplicação. Ele é treinado e disponibilizado ao público, tem diferentes tamanhos e diferentes níveis de inteligência. Porém, modelos do tipo LLM (o que estamos acostumados a utilizar, como GPT-6 Astra, Opus 5.5, GLM 5.3, etc – não confundir com os novos modelos do tipo System One, como o Jev) produzem, no final das contas, texto. Eles não operam ferramentas nem executam chamadas a menos que exista um ambiente propício para isso.
Aos modelos que são capazes de agir além da mera produção de texto (comumente denominados chatbots), chamamos agentes. Uma definição que me agrada é que agente = modelo + ferramentas em um loop.
Essa primeira definição faz sentido mas é incompleta, uma vez que existe muito mais a ser controlado. Por exemplo, quais as permissões que um determinado modelo tem? Que tipo de persistência ele apresenta? Como posso inspecionar uma thread para entender se o modelo usou as ferramentas corretas?
Eis então uma segunda definição, mais completa: agente = modelo + harness. De forma simplificada, tudo que não é o modelo necessariamente é o harness. Assim, a disciplina do harness engineering nada mais é do que projetar, construir e avaliar o ambiente onde um modelo performa, suas ferramentas disponíveis, suas permissões, memória, etc.
Para entender melhor sobre os conceitos por trás dos agentes de IA, além de aprender como aplicá-los em tarefas de programação e projetá-los para uso pessoal ou compartilhado, não deixe de conferir a Trilha do Engenheiro de IA e de participar do lançamento no YouTube!
Existem dois casos clássicos de harness engineering: um harness individual, projetado de modo a aumentar a eficiência do seu usuário num conjunto de tarefas relevantes; e um harness compartilhado, projetado de modo a prover para um grupo de pessoas o necessário para resolver as pendências de tal grupo. Analisemos cada caso de forma separada.
Projetando um harness para uso próprio
Suponha que você é um engenheiro de software em um time de desenvolvimento. Seu trabalho consiste, de forma geral, a escrever código que implemente soluções, garantir que esse código esteja funcional e que resolva o problema a ser resolvido. Como você pode montar um harness que te ajude a aumentar sua eficiência nesse trabalho?
Nesse caso, você poderia trabalhar em um ambiente que permitisse acesso aos modelos mais capazes. Além disso, seria interessante se conectar ao seu issue tracker – como o Linear – de modo a automaticamente listar os tickets assinalados a você, incluindo o escopo e critério de aceite. Você também precisaria ter acesso ao GitHub, para que a IA trabalhasse nas mudanças e criasse um PR quando finalizado. Essa execução poderia ser orientada por diversas skills que instruiriam o modelo a reutilizar os padrões do repositório. Por fim, você garantiria a qualidade do código através de code reviews automatizados e despachando um QA manual através do Computer Use.
Identificar onde a IA pode acelerar o seu trabalho é responsabilidade de cada um. O domínio do harness engineering permite que você projete o ambiente perfeito para performar de modo rápido, seguro e eficiente.
Projetando um harness para uma empresa
Muitas vezes, no entanto, um harness precisa ser compartilhado por múltiplas pessoas. Pense no banco de dados de uma empresa: ali existem informações de diferentes domínios, que podem ser úteis para diferentes funções. Por exemplo, o financeiro quer acesso aos registros de pagamento, enquanto um PM deseja dividir usuários em cohorts baseados nos seus atributos.
Existem muitas formas de se fazer isso: umas mais seguras que outras. De forma mais temerária, você pode gerar uma API key ou permitir que seus companheiros de trabalho conectem-se diretamente nos serviços necessários. Além do óbvio risco de segurança, esse processo claramente não escala. Assim, uma alternativa superior é desenvolver um harness comum, conectado às ferramentas da empresa, hospedado em um servidor, e disponível através de uma interface que permita validação, permissão e inspeção, como um gateway em um MCP server.
Quando argumentei que harness engineering é a nova função do engenheiro de software, era principalmente esse caso que tinha em mente. Afinal, quem além de um engenheiro com bom domínio de agentes de IA seria capaz de projetar tal sistema?
Tal conceito tem se popularizado lá fora como domain-specific harness – ou seja, um ambiente controlado para que os modelos de IA interajam com as ferramentas relevantes de um domínio específico (como as da sua empresa ou time).
É justamente esse o tema do meu curso sobre Harness Engineering, que integrará a Trilha do Engenheiro de IA. Ali você aprenderá a anatomia de um harness, e como projetar, implementar e avaliar os sistemas onde agentes de IA operarão.
Além do Harness Engineering, a Trilha também compreenderá os cursos de Fundamentos da Engenharia de IA e Programação Agêntica, e seu lançamento oficial será quarta-feira, dia 30/09 às 19h. Como existirá uma condição especial para a Turma Fundadora, além de bônus exclusivos, não deixe de se inscrever na lista de lançamento para ser avisado das novidades.