DEV Community

Cover image for Harness Engineering: o dev que não conhece vai ficar pra trás?
Tiago Vilas Boas (Montanha)
Tiago Vilas Boas (Montanha)

Posted on Edited on AI-assisted

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

#ai #productivity #devops #braziliandevs

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

Se você usa Cursor, Kiro, Codex ou Claude Code, você já está dentro de um agente de codificação: o modelo, mais o harness do fornecedor que a ferramenta traz, mais o harness do usuário que você coloca no seu sistema. A ferramenta inteira não é um harness. Ela hospeda um.

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ê reconstrói 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.

A escada de maturidade, na ordem certa:

  1. Vault hub-first: arquivos de contexto curtos (~200 linhas), organizados por escopo. É o chão de tudo.
  2. Skills + steerings: receitas sob demanda. O agent sabe o que fazer sem você repetir.
  3. MCPs nos sistemas que você já usa: Jira, Sentry, banco. Contexto real, não hipótese.
  4. RAG com embeddings: só quando o hub/grep não escala. Adiciona custo de infra e debugging.
  5. Graphify (code graph): quando a pergunta é sobre código (PaymentService, dependências), não sobre decisão ou incidente.

Não pule degrau. RAG antes de vault é infra sem fundação. Graphify antes de steerings é poder sem direção.

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

Por que o contexto importa: o loop do agent

Antes de falar de tokens, vale entender o ciclo: contexto montado → modelo decide → tool call ou resposta → resultado volta pro ambiente → próximo turno. O harness é a política que controla o que entra nesse loop (o que pode ser lido, gravado, aprovado) a cada passo. Contexto ruim no início contamina toda a cadeia.

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. Trocar o modelo só aloca a camada de dentro. Não cria o harness: guia entra antes da geração, sensor volta depois.

Em uma investigação específica, mantendo modelo e tarefa, o contexto direcionado derrubou o consumo de tokens pra uma fração do que era. 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. Exemplo real: um MCP que eu construí

Falar de harness é fácil. Mostrar é outra coisa.

Uma das ferramentas que construí foi o dev-to-mcp: um servidor MCP que conecta agentes ao DEV.to. O agente consegue buscar artigos, listar tags populares, criar drafts, publicar.

Por que construí em Go e não usei um pronto em Python?

Cold start. Em stdio, o cliente MCP sobe o servidor uma vez por sessão, não a cada chamada. Então o custo de iniciar aparece uma vez por sessão: servidor em Python pode levar segundos (imports, virtual env); em Go, o binário sobe em ~50ms. Depois disso, cada chamada vai pro processo que já está de pé.

Segurança de credenciais. No macOS, o servidor lê a API key direto do Keychain (serviço dev-to-mcp, conta = seu usuário do sistema). Só se não achar nada no Keychain ele cai pra variável DEV_TO_API_KEY: é o caminho pra Linux/Windows, de preferência injetada por um vault (1Password CLI, pass) e nunca num .env versionado. No meu Mac, a key vive só no Keychain: não aparece em .env, não vai pro log, não fica em histórico de shell.

Crash behavior. Em qualquer linguagem, se o servidor cai, o processo termina e o pipe de stdio fecha. Subir de novo é trabalho do cliente MCP. O que o Go me dá aqui é um binário só, sem runtime nem venv pra reconstruir.

Esse MCP é um exemplo do que a seção 3 propõe. Não é um MCP de banco, não é de Jira. É um MCP de publicação. Serve pra quem escreve conteúdo técnico e quer o agente ajudando a publicar sem sair do editor.

O ponto não é "use esse MCP". É: se você identificou uma fricção no seu workflow, você pode construir a ferramenta. E se construir bem, pode servir pra outros.

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

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

Hoje mantemos dezenas de 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.

6. 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?
Enter fullscreen mode Exit fullscreen mode

Se você não consegue responder, o harness não está pronto.

Leitura complementar

Qual área da sua empresa ainda opera na base do "cola no ChatGPT e torce"? Produto? QA? Dados? O que te impede de montar o harness pra eles?

Se quiser ir mais fundo na pilha (agent, loop, quando RAG entra de verdade e quando Graphify é o cérebro certo), continua em Harness Engineering: as 5 camadas do agent.

Top comments (0)