Harness Engineering: O que separa times que escalam IA dos que escalam dívida

Photo by Pascal Habermann on Unsplash

Quando a velocidade sobe, mas a confiança cai

Se você está desconfiado com a IA, você não está sozinho. Eu também já desconfiei.

Lendo um artigo recente do Martin Fowler (se você não conhece esse cara, se informe sobre ele pra ontem), uma frase ficou martelando na minha cabeça: a IA acelera aquilo que você já é. Se seu sistema de engenharia é saudável, acelera saúde. Se está capenga, acelera dívida.

Foi nesse ponto que a ideia ganhou forma para mim: o jogo não é mais sobre “quem escreve sintaxe mais rápido”. O jogo virou sobre quem constrói melhor o sistema de controle ao redor da IA.

Esse sistema eu tem sido chamado de Harness Engineering.

O que eu entendo por Harness Engineering

Se eu tivesse que resumir em uma frase:

Harness Engineering é a disciplina de projetar testes, restrições arquiteturais, contexto e governança de risco para guiar o que a IA produz com segurança e consistência.

Repara que isso muda o centro de gravidade da nossa profissão.

Antes, o foco principal era: “como eu escrevo esse código?”

Agora, o foco estratégico passa a ser:

• “Como eu defino o comportamento esperado?”
• “Como eu protejo os limites arquiteturais do sistema?”
• “Como eu forneço contexto suficiente para reduzir ambiguidade?”
• “Como eu calibro o nível de autonomia da IA pelo risco da tarefa?”

Eu gosto de uma analogia simples: o harness é a torre de controle. O avião (agente) pode ser rápido e poderoso, mas sem plano de voo, comunicação e regras de aproximação, a chance de colisão aumenta rápido.

Por que esse tema importa agora

No mesmo artigo do Fowler, aparecem ideias que eu considero centrais para os próximos anos:

• middle loop (camada de supervisão) como trabalho de engenharia cada vez mais relevante
• risk tiering (estratificação de risco) como disciplina central
• TDD como forma robusta de prompt engineering (olha ele de novo aí)

Eu concordo com essa direção porque ela conversa com algo que eu já vejo na prática: equipes que tratam IA como brinquedo de produtividade tendem a gerar pico de velocidade e vale de confiança. Equipes que tratam IA como parte do sistema de engenharia criam um efeito mais sustentável.

E aqui tem um ponto de liderança muito importante: isso não é responsabilidade de um indivíduo isolado. É desenho de sistema de trabalho. É alinhamento entre liderança técnica, arquitetura, plataforma e produto.

“Poxa, Hugo, então agora todo dev vai virar auditor de IA e parar de programar?”, diz o Leitor

Não. A programação continua existindo. O que muda é o vetor de valor.

O diferencial competitivo deixa de ser só escrever código e passa a incluir a capacidade de desenhar barreiras de proteção e ciclos de validação que mantêm qualidade em alta velocidade.

Os 4 pilares do Harness Engineering

Para não ficar abstrato, vamos ver o tema em quatro pilares que se reforçam.

1. Testes e avaliações primeiro

Se a IA gera opções, quem define certo e errado é o seu sistema de avaliação.

Por isso, eu tenho visto TDD (Test-Driven Development, desenvolvimento guiado por testes) ganhar um novo papel: não apenas melhorar design de código humano, mas também ancorar o comportamento esperado para agentes.

Sem isso, você está validando no olho e no feeling. E feeling não escala.

Na prática, esse pilar significa:

• Definir critérios de aceitação antes da geração
• Usar testes automatizados como contrato mínimo de comportamento
• Incluir avaliações não-funcionais quando fizer sentido (performance, segurança, observabilidade) ou as famosas Architectural Fitness Functions
• Tratar falhas recorrentes como sinal de lacuna no harness, não apenas “erro do modelo”

2. Restrições arquiteturais explícitas

Arquitetura implícita morre rápido quando você injeta velocidade de geração.

Se os limites de domínio, os contratos e os padrões de integração não estão claros, a IA tende a preencher lacunas com soluções plausíveis, mas desalinhadas.

Aqui entra um trabalho que times maduros já deveriam fazer, com IA ou sem IA:

• Tornar decisões arquiteturais explícitas (ADRs)
• Definir limites que não podem ser atravessados
• Estabelecer padrões aceitos para comunicação entre componentes
• Reduzir ambiguidade estrutural

É literalmente engenharia de contenção. Você não está reduzindo criatividade. Está protegendo integridade do sistema.

3. Engenharia de contexto

Esse pilar conecta diretamente com o que venho escrevendo sobre maturidade de agentes: contexto bom gera saída boa.

Quando falo de contexto, não é “prompt enorme”. É contexto útil, curado e orientado a decisão:

• convenções do time
• decisões arquiteturais e seus porquês
• regras de negócio que não podem ser violadas
• exemplos reais que servem como referência

Se você já usa artefatos como OpenSpec, OpenCode e AgentSkills, ótimo: eles cabem perfeitamente dentro deste pilar como instrumentos concretos de contexto.

O erro comum é achar que contexto é documento estático. Não é. É um ativo vivo de engenharia.

Para maiores detalhes, leia meu artigo anterior: Liderança Situacional na Era da IA.

4. Risk tiering e autonomia proporcional

Nem toda tarefa merece o mesmo nível de autonomia.

Esse é, talvez, o pilar mais negligenciado no começo da adoção de IA.

Eu sugiro uma matriz simples:

A ideia é simples: quanto maior o impacto potencial, maior o rigor de validação.

O Harness Loop: operacionalizando no dia a dia

Uma forma prática de tornar isso rotina é operar em ciclo.

Eu uso um loop de cinco etapas:

1. Especificar comportamento, limites e critérios
2. Gerar com agentes de IA
3. Avaliar com testes, checks e revisão orientada a risco
4. Restringir onde houve deslizes (ajustar contexto e limites)
5. Aprender com incidentes, retrabalho e acertos para evoluir o harness

Perceba que esse modelo desloca a conversa de “qual prompt mágico eu uso” para “qual sistema de aprendizagem e proteção meu time está construindo”.

Quando esse loop amadurece, acontece algo poderoso: a velocidade deixa de ser inimiga da qualidade.

Anti-patterns: sinais de que você está sem harness

Se você quiser um check rápido de realidade, aqui vão sinais clássicos de adoção desequilibrada:

• Volume de PR aumentou, mas o tempo de review explodiu
• Mesma feature com padrões diferentes dependendo de quem pediu ao agente
• Crescimento de correções pós-merge
• Discussões arquiteturais reaparecendo em toda sprint
• Sensação constante de “não confio totalmente nisso”

Se três ou mais desses sintomas estão acontecendo juntos, provavelmente não falta IA. Falta harness.

Outro anti-pattern comum: tentar resolver tudo com uma política genérica de uso de IA em uma base e achar que isso basta. Política sem mecanismo operacional vira intenção sem efeito.

O papel dos líderes técnicos nesse cenário

Na minha visão, o líder técnico da era dos agentes não perde relevância. Ele muda de alavanca.

Em vez de ser apenas o “resolvedor final” de problemas complexos, ele passa a ser também:

• designer de sistema de controle
• curador de critérios de qualidade
• articulador entre arquitetura, plataforma e produto
• educador do time em práticas de validação

Isso conversa com algo que eu já defendi em outros artigos: liderança técnica não é cargo, é comportamento. E aqui esse comportamento aparece de forma cristalina.

Você pode até usar a melhor IA do mercado, mas sem engenharia de proteção o resultado tende a oscilar. Com harness bem desenhado, até agentes diferentes convergem para outputs mais consistentes.

Conclusão: velocidade sem controle não é evolução

Se eu tivesse que resumir tudo em poucos pontos, seria isso:

• A IA muda o jogo, mas não elimina engenharia; ela muda onde a engenharia precisa ser mais forte
• Harness Engineering é o nome que tem sido usado para esse novo centro: testes, arquitetura, contexto e risco trabalhando juntos
• O papel do desenvolvedor e do líder técnico evolui de executor de sintaxe para designer de sistema de controle
• Times que tratam IA como aceleração sem proteção tendem a escalar dívida
• Times que constroem harness consistente conseguem escalar velocidade com mais confiança
• Aos CEOs, vocês sempre encontrarão alguém num corredor querendo vender uma solução mágica, vocês já sabem a resposta, o filme se repete.

No fim do dia, não se trata de frear inovação. Se trata de colocar cinto de segurança, freios ABS e pneus novos em um carro que agora corre muito mais rápido.

E aí, no seu contexto, qual pilar do Harness Engineering está mais frágil hoje: testes, restrições arquiteturais, contexto ou risk tiering? Quero muito ler sua experiência nos comentários. 👍😃🚀

Artigos relacionados que podem aprofundar essa conversa:

• Liderança Situacional na Era da IA
• Arquétipos da Liderança Técnica
• Times de Plataforma