O que é Harness Engineering?

Notas de estudo a partir do artigo Harness Engineering, de Martin Fowler.

O que significa "Harness"?

Vem do inglês e significa arreio.

Arreio é todo o conjunto de peças usado para montar e guiar o cavalo com segurança, incluindo a sela, rédeas etc.

Aplicado no nosso contexto, a ideia principal é ter um arreio para os nossos modelos de IA, para ter mais controle sobre eles.

Agente = Modelo + Harness

Um agente nada mais é do que essa soma: um modelo de linguagem envolto pelo seu harness.

Camadas do Harness

Existem três camadas nesse arreio, de dentro para fora:

• Model — o próprio modelo de linguagem, o núcleo que gera as respostas.
• System Harness — a camada própria do modelo; não temos acesso a ela, pois é propriedade de quem treinou o modelo.
• User Harness — a camada totalmente configurável por nós, que permite a nossa personalização.

Guias, sensores e grades de proteção

Guias sugerem. Sensores detectam. Grades de proteção previnem.

Guias (feedforward)

Fornecem restrições contextuais e diretivas iniciais de comportamento antes da execução.

Exemplo: um AGENTS.md dizendo "sempre use TypeScript estrito".

Sensores (feedback)

Monitoram estados e executam loops de feedback para autocorreção do agente.

Exemplo: um linter que roda depois de cada edição e aponta o que corrigir.

Grades de proteção

Interceptam chamadas e impõem limites determinísticos de segurança em tempo de execução.

Exemplo: um hook que bloqueia rm -rf sem confirmação.

Ponto de atenção

Guias e sensores não são determinísticos — podem ser dinâmicos, já que uma LLM responde de forma diferente ao mesmo prompt em momentos diferentes.

Já as grades de proteção buscam evitar esse tipo de comportamento, colocando limites determinísticos.

Então, o que é Harness Engineering?

A construção deliberada e contínua de mecanismos ao redor do modelo de linguagem (LLM), a fim de aumentar a confiança em seus resultados.

Exemplo: um AGENTS.md que ensina as convenções do projeto, um linter que roda depois de cada edição, um hook que bloqueia rm -rf (exclusão de pastas) sem confirmação.

Entendemos o que é harness, mas:

• Como aplicar no dia a dia?
• Como saber se tenho um bom harness?
• O que fazer para melhorar o harness?

Como aplicar no dia a dia?

Dá pra distinguir dois tipos de controle, que valem tanto pra guias quanto pra sensores:

• Computacionais: determinísticos e rápidos (testes, linters, type checkers, análise estrutural). Rodam em milissegundos/segundos e o resultado é confiável.
• Inferenciais: análise semântica feita por outra IA ("LLM as judge", agente revisor). Mais lentos, mais caros e não determinísticos, mas trazem um julgamento semântico que o computacional não alcança.

Na prática, o harness também precisa ser distribuído ao longo do ciclo de vida da mudança ("keep quality left"):

• O que é rápido e barato roda antes até do commit (linter, testes rápidos, um review agent leve).
• O que é mais caro roda depois da integração, no pipeline (testes de mutação, review mais profundo com visão do todo).
• Existe ainda uma camada de sensores contínuos, fora do ciclo de mudança, monitorando drift ao longo do tempo (código morto, qualidade da cobertura de testes, scanners de dependência).

Como saber se tenho um bom harness?

O artigo propõe pensar em três categorias — o que o harness está tentando garantir:

Maintainability harness

Qualidade interna do código. É a mais fácil hoje, porque já existe muita ferramenta pronta (linters, análise estrutural).

Sensores computacionais pegam bem duplicação, complexidade, cobertura, drift arquitetural. Sensores inferenciais ajudam em julgamentos semânticos (código duplicado semanticamente, over-engineering), mas de forma cara e probabilística.

Nenhum dos dois pega bem diagnóstico errado do problema ou instrução mal entendida — isso ainda depende de o humano ter especificado bem o que queria.

Architecture fitness harness

Checagens das características arquiteturais (as "fitness functions"). Exemplo: requisitos de performance ou padrões de observabilidade/logging.

Behaviour harness

O mais difícil: garantir que o sistema se comporta funcionalmente do jeito certo.

Hoje a abordagem comum é especificação funcional como guia e, como sensor, a suíte de testes gerada pela própria IA (checando se passa e a cobertura) + teste manual. O autor destaca que isso ainda deposita fé demais nos testes gerados por IA — não é confiável o suficiente ainda.

Ou seja: um bom harness é avaliado por categoria, não como bloco único — dá pra ter um harness forte de manutenibilidade e ainda assim fraco de comportamento.

O que fazer para melhorar o harness?

O loop de direção (steering loop)

Sempre que um erro se repetir, é sinal de que a guia ou o sensor correspondente precisa ser melhorado ou criado, pra reduzir a chance do erro acontecer de novo.

Dá pra usar IA pra ajudar nisso: escrever testes estruturais, gerar rascunhos de regras a partir de padrões observados, criar linters customizados, gerar guias a partir de "arqueologia" do código-base.

Harnessability

O quanto um código-base é "harnessável". Linguagens fortemente tipadas, módulos bem definidos e frameworks robustos aumentam naturalmente as chances de sucesso.

Projetos greenfield já podem nascer pensando nisso; projetos legados sofrem mais — justamente onde o harness é mais necessário.

Harness templates (ideia futura)

Pacotes prontos de guias e sensores por tipo de serviço (API CRUD, dashboard de dados, processador de eventos), reaproveitáveis — parecido com os templates de serviço que várias empresas já usam.

O papel do humano não desaparece

O harness tenta externalizar a experiência que um dev traz (senso de convenção, "não fazemos assim aqui", contexto organizacional), mas só até certo ponto.

A meta não é eliminar o humano, e sim direcionar o esforço dele pra onde é mais necessário.

É uma prática contínua de engenharia, não uma configuração única — o harness evolui junto com o código.

O que eu acho disso

Acho o conceito de harness engineering bem interessante, mas ele não é bala de prata. Depende muito do contexto do projeto.

Em projetos pequenos, descartáveis ou de prova de conceito, montar guias, sensores e grades de proteção pode ser puro over-engineering: você gasta mais tempo construindo o arreio do que efetivamente construindo o que importa. O esforço só se paga em projetos que vão viver por um tempo e ser mexidos por várias pessoas.

Outro ponto que me preocupa é a falsa sensação de segurança. Um harness bem montado pode fazer parecer que tudo está sob controle, mas sensores — principalmente os inferenciais (LLM as judge) — não são infalíveis: podem deixar passar problema real ou, pior, aprovar algo errado com confiança. Isso é perigoso principalmente pra quem está aprendendo e passa a confiar cegamente na grade de proteção em vez de entender o "porquê" por trás dela.

E tem o custo de token. Sensores inferenciais rodando a cada commit, cada PR, cada mudança, escalam rápido em custo — e esse é um fator que o artigo original não trata com o peso que eu acho que merece.

No fim, acho que harness engineering é uma ferramenta poderosa, mas como toda ferramenta, precisa ser aplicada com critério — o próprio esforço de montar o harness precisa ser proporcional ao que o projeto exige.