Harness Engineering: o dev que não conhece vai ficar pra trás?

Meu PM colou uma query no ChatGPT pra entender um bug de produção. O modelo respondeu com uma tabela que não existe no nosso banco.

Ele não sabia. O ChatGPT não tinha contexto do nosso schema. E o PM passou meia hora debugando uma hipótese inventada.

Isso não é culpa do modelo. É falta de harness.

Harness Engineering é a construção do ambiente que controla como modelos de IA usam ferramentas, recebem contexto e acessam recursos. Não é sobre qual modelo usar. É sobre o ambiente que você constrói pra esse modelo operar.

Ficar pra trás de quê? De quem já entendeu que o modelo sozinho não resolve. De quem monta o ambiente certo pra cada domínio. De quem dá acesso real ao contexto certo, não só "cola no ChatGPT e torce".

Índice

1. Do arquivo de regras ao ambiente completo
2. O harness economiza tokens (e evita alucinação)
3. Harness por domínio: o dev que entende propaga
4. O que funciona no meu time (e o que ainda não medi)
5. Checklist antes de dar autonomia

1. Do arquivo de regras ao ambiente completo

Se você usa Cursor, Kiro, Codex ou Claude Code, você já está dentro de um harness. A ferramenta inteira é um harness.

O nível básico você provavelmente já faz:

Rules/Steerings: arquivos .md que dizem pro agente como se comportar
MCPs: conexões com sistemas externos (Jira, Confluence, banco)
Contexto de projeto: o agente lê seu código, sua estrutura

Isso é harness engineering de entrada. Mas a disciplina não parou aí.

Harness maduro inclui:

Permissões granulares. Não é só "pode usar o terminal". É: pode rodar npm test, não pode rodar rm -rf. Pode ler o banco, não pode escrever.

Human-in-the-loop por design. Ações sensíveis param e pedem confirmação. Não é o agente decidindo pedir. É o harness obrigando a parar.

Observabilidade. Logs de cada ferramenta chamada. Trilha de auditoria. Métricas de custo. Você reconstrui o que o agente fez e quanto custou.

A diferença entre harness básico e maduro é governança. No básico você confia. No maduro você audita.

2. O harness economiza tokens (e evita alucinação)

O PM do exemplo inicial gastou tokens e tempo porque o modelo não tinha contexto. Alucinou uma tabela.

Harness bem construído resolve isso de três formas:

Steerings evitam perguntas repetidas. Se o agente já sabe que usamos PHP 8 no backend, ele não pergunta. Se já sabe a convenção de branches, não inventa. Cada steering carregada é uma pergunta a menos.

Servidor MCP bem desenhado traz só o necessário. Em vez de colar o schema inteiro no prompt, o servidor retorna só as tabelas relevantes pra query. Contexto preciso, não contexto massivo. O protocolo MCP não garante isso sozinho: quem decide é o desenho das ferramentas, os schemas restritos e os limites de resposta.

Roteamento de modelo. Tarefa simples vai pro modelo barato. Tarefa complexa vai pro modelo caro. O harness decide, não você a cada prompt.

Em uma investigação específica, mantendo modelo e tarefa, o contexto direcionado reduziu o consumo aproximado de ~50k para ~15k tokens. Ainda não tratei isso como benchmark: é uma observação, não uma medição sistemática.

3. Harness por domínio: o dev que entende propaga

Aqui está o ponto que muita gente não percebe: você, como dev, é o responsável por perpetuar harness na empresa.

O PM que colou a query no ChatGPT não sabia que existia MCP de banco. Não sabia que podia ter contexto real. Ele fez o que sabia fazer.

Se você entende harness, seu trabalho não é só configurar o seu. É democratizar o acesso.

Na prática:

Harness de Produto. Seu PM precisa consultar dados de produção? Monta um servidor MCP que expõe views autorizadas, com allowlist de consultas, mascaramento de PII e limites de tempo/linhas. Ferramentas de negócio, não SQL arbitrário. Ele para de inventar tabela.

Harness de QA. Seu QA precisa entender fluxos pra criar cenários? Monta uma steering com os fluxos críticos documentados. Ele para de perguntar "como funciona X" toda sprint.

Harness de Design. Seu designer precisa entender constraints técnicos? Monta um contexto com as limitações do sistema. Ele para de propor coisa que não dá pra fazer.

Harness de Dados. Seu analista precisa de métricas? Monta um MCP que conecta no warehouse com as dimensões certas. Ele para de pedir extração manual.

O dev que entende harness e guarda pra si está desperdiçando impacto. O dev que propaga harness pro time inteiro está multiplicando capacidade.

4. O que funciona no meu time (e o que ainda não medi)

No meu time, mantemos quatro repositórios frontend. Antes do harness compartilhado, cada dev configurava diferente. PRs iam e voltavam por inconsistência.

Hoje mantemos ~80 steerings no catálogo, mas nem todas entram no contexto ao mesmo tempo. Cada projeto ou tarefa carrega só as relevantes. O detalhamento de quais e como funcionam está em Cursor, Kiro, ChatGPT: três harness, uma arquitetura — este post é o modelo mental, aquele é a arquitetura.

O que funciona: PRs mais consistentes. Menos "arruma isso" no review. Onboarding mais rápido porque o agente já sabe as convenções.

O que ainda não resolvemos: harness de domínio pra outras áreas. O PM ainda cola no ChatGPT. O QA ainda pergunta fluxo. Temos steerings de dev, não temos harness de empresa.

Isso é o básico funcionando. Mas o básico bem feito já muda o jogo do time de engenharia. O próximo passo é expandir pros outros domínios.

5. Checklist antes de dar autonomia

Antes de soltar o agente numa tarefa com consequências:

## Checklist de autonomia

- [ ] **Contexto**: o que ele precisa saber? Está escrito?
- [ ] **Ferramentas**: quais ele pode usar? Quais estão proibidas?
- [ ] **Permissões**: read-only por padrão? Ações sensíveis pedem confirmação?
- [ ] **Sandbox**: ele pode fazer algo destrutivo? Tem contenção?
- [ ] **Avaliação**: como você sabe se ele fez certo?
- [ ] **Logs**: você consegue reconstruir o que aconteceu?