Por que você deve aprender Engenharia de Harness? 5 produtos, 3 escolas, 5 princípios universais explicados completamente

Sistema desmembrado Engenharia Harness: 5 produtos, 3 escolas (OpenAI / Anthropic / ThoughtWorks), 5 princípios universais, e por que a "Declínio do Harness" te obriga a cortar metade do projeto a cada 6 meses.
Este artigo é originado do artigo de @sairahul1 no X, organizado e compilado pelo Dongqu.
(Resumindo: Introdução à Engenharia Harness (Engenharia de IA): Padrões de programação mais recentes da OpenAI, ensinando você a alcançar facilmente o Nível 1)
(Complemento de contexto: CEO do YC compartilha segredos de IA: o futuro pertence às pessoas que constroem sistemas de juros compostos de informação)

Índice do artigo

Toggle

    1. Definição de Harness
    1. Metáfora de OS
    1. O que mudou em 2026
    1. Arquivos AGENT.md / CLAUDE.md
    1. Listas de Recursos JSON (Rastreador de progresso)
    • Por que JSON e não Markdown?
    1. Rotina de inicialização de sessão
    1. Contratos de Sprint
    • Por que são importantes
    1. Modelos de tarefas estruturadas
    1. Escola da OpenAI: Prioridade ao ambiente
    • Como eles fazem
    • Evidências
    1. Escola da Anthropic: Separar "fazer" e "avaliar"
    • Como eles resolvem: 3 agentes especializados
    • Resultados (Testes A/B)
    1. Escola da ThoughtWorks: Quadro 2×2
    • Insights deles: classificar cada controle de harness com dois eixos
    • Matriz 2×2
    1. Princípio 1: Contexto supera instrução
    1. Princípio 2: Planejamento e execução devem ser separados
    1. Princípio 3: Laços de feedback são essenciais
    1. Princípio 4: Faça uma coisa de cada vez
    1. Princípio 5: O código é o próprio documento
    • Implicações práticas
    1. O declínio do Harness (Harness Decay) é real
    • É isso que é o declínio do Harness
    1. Construir para deletar (Build to Delete)
    1. Realidade de custos
    • Mas aqui é a parte que ninguém fala
  • Resumo completo
    • O que é harness
    • 5 produtos de harness
    • 3 escolas
    • 5 princípios universais
    • Contradições intrigantes

Em fevereiro de 2026, um pequeno time da OpenAI produziu 1 milhão de linhas de código de produção.

Eles não escreveram uma linha.

Foi um agente de IA que escreveu.

O sistema que eles projetaram é para tornar o agente confiável.

Esse sistema agora tem nome — Engenharia Harness.

Em poucas semanas, a Anthropic publicou 3 artigos relacionados. ThoughtWorks organizou em um quadro. Philipp Schmid, da Hugging Face, chamou de "A disciplina mais importante de 2026".

Em 90 dias, uma nova disciplina de engenharia se formou. E fora da equipe de infra de IA, quase ninguém entendeu.

Este artigo explica tudo claramente. Sem enrolação, sem jargões acadêmicos, apenas o modelo mental que você realmente precisará usar.

1. Definição de Harness

A definição mais simples dada pela ThoughtWorks:

Agente = Modelo + Harness

Harness é tudo que está fora do modelo.

  • Restrições que mantêm o agente na linha
  • Laços de feedback para detectar erros
  • Documentos que dizem onde o agente está
  • Ferramentas às quais ele tem acesso

Remover harness → um modelo de linguagem no seu código que só adivinha.

Adicionar o harness correto → um sistema capaz de gerar código de produção.

Esse nome vem de arreios. Harness são rédeas, sela, bridão — direcionando um animal forte, mas difícil de prever, para um caminho útil.

Você não está tornando o cavalo mais inteligente, está criando um equipamento que torna sua força útil.

2. Metáfora de OS

Philipp Schmid dá a melhor metáfora técnica: Imagine como um computador.

| Papel | Correspondente | | --- | --- | | Modelo | CPU (poder de processamento bruto) | | Janela de contexto | RAM (memória de trabalho limitada e volátil) | | Harness | Sistema operacional (gerencia o que o CPU vê e quando vê) | | Agente | Aplicativo rodando em cima |

Seu modelo é forte. Mas sem um sistema operacional para gerenciar memória, agendar tarefas, aplicar regras — ele é apenas um pedaço de silício.

A maioria roda aplicativos "sem sistema operacional". Então, seu agente quebra na linha de produção.

3. O que mudou em 2026

LangChain usou o mesmo modelo duas vezes no Terminal Bench 2.0:

| Harness | Pontuação | | --- | --- | | Harness antigo | 52.8% | | Novo harness | 66.5% |

Mesmo modelo. Harness diferente. Uma diferença de 13,7 pontos percentuais.

Vercel fez o oposto — reduziu ferramentas do agente em 80%. Resultado? Melhor, não pior.

A dura verdade de 2026:

  • Agente nunca foi a parte difícil
  • Harness é

Se 2025 foi o ano em que agentes de IA provaram que podem programar, 2026 é o ano em que se descobriu que o "ambiente" é mais importante que o "modelo".

4. Arquivos AGENT.md / CLAUDE.md

Produtos mais comuns de harness.

Arquivos markdown dispersos no código. Cada sessão do agente começa lendo — como um documento de onboarding de um novo funcionário.

O que eles contêm?

  • Contexto do projeto
  • Convenções de código
  • Decisões arquitetônicas
  • Diretrizes de "como fazemos aqui"
  • O que está em andamento atualmente

OpenAI chama de AGENT.md. Anthropic chama de CLAUDE.md. Cursor usa .cursorrules.

Nomes diferentes, mesmo princípio. Um por módulo principal. Atualizado conforme o projeto evolui.

Sem ele: o agente inicia cada sessão às cegas. Com ele: o agente entra com informações já carregadas.

5. Listas de Recursos JSON (Rastreador de progresso)

Quando o agente cruza várias sessões para construir um app completo, a janela de contexto de cada sessão fica vazia. Como ele sabe o que já foi feito?

Um arquivo JSON.

Cada entrada descreve:

  • Uma feature
  • Como verificar se passou
  • Status Pass / Fail

A sessão do agente começa lendo esse arquivo — priorizando o fail mais alto → implementa → marca como pass → commita → repete.

Por que JSON e não Markdown?

Anthropic descobriu: a probabilidade de o agente sobrescrever JSON acidentalmente é menor do que de sobrescrever Markdown.

Detalhes pequenos, mas cruciais em cenários de autonomia de 6 horas.

6. Rotina de inicialização de sessão

Cada sessão começa do mesmo jeito, toda vez.

Os 7 passos de Anthropic para iniciar:

  1. Confirmar diretório de trabalho
  2. Ler git log e arquivo de progresso
  3. Buscar na lista de features a tarefa mais prioritária não concluída
  4. Iniciar servidor de desenvolvimento
  5. Executar validações básicas de ponta a ponta
  6. Implementar uma feature
  7. Comitar com mensagem descritiva e atualizar progresso

Sem isso: os primeiros 20 minutos do agente são gastar entendendo o estado atual, repetindo o ciclo. Com isso: o agente entra com informações e já vai direto ao trabalho.

7. Contratos de Sprint

Antes de escrever qualquer linha de código — dois agentes negociam primeiro.

Agente Gerador propõe:

  • O que fazer
  • Como verificar sucesso

Agente Avaliador revisa:

  • A proposta está completa?
  • Os critérios de sucesso estão claros?

Se ambos concordarem, o código é escrito.

É uma revisão de projeto. Mas ambos são IA.

Por que é importante

No mesmo ciclo, planejar e executar com o mesmo agente gera resultados pouco confiáveis.
A etapa de "planejar" — mesmo que feita por IA — aumenta muito a qualidade do output.

8. Modelos de tarefas estruturadas

Antes de qualquer código, o harness analisa o código real.

Ele gera um mapa de impacto fundamentado:

  • Caminho real de arquivos (não uma fantasia)
  • Nomes de símbolos existentes
  • Padrões já utilizados
  • Critérios de aceitação concretos

Depois começa a implementação.

Parece óbvio, mas a maioria das equipes pula essa etapa.

O agente tenta adivinhar a estrutura de arquivos, inventa APIs inexistentes, cria coisas que não combinam com o código real.

Ter um contexto fundamentado antes de agir melhora muito a qualidade do output.

9. Escola da OpenAI: Prioridade ao ambiente

O time do Codex da OpenAI tem um problema absurdo:

1 milhão de linhas de código de produção, zero linhas escritas à mão.

Num projeto desse tamanho, não dá para revisar linha por linha. Então, eles não fazem isso.

Em vez disso — eles projetam o ambiente de forma tão completa que o agente gera "saídas passíveis de revisão" desde o início.

Como eles fazem

  • Dependências rigorosas (Tipos → Config → Repositório → Serviço → Runtime → UI)
  • Todo o código disperso em AGENT.md
  • O agente conectado direto ao pipeline CI/CD

Filosofia: Projete o ambiente. Depois deixe o agente rodar.

Evidências

App Sora Android. 4 engenheiros. 28 dias. Top da Play Store. 99,9% sem falhas.

Codex processa 70% dos PRs internos semanalmente.

10. Escola da Anthropic: Separar "fazer" e "avaliar"

Outro problema que eles enfrentam:

Quando pedem ao agente que avalie sua própria saída, ele se elogia — mesmo que a qualidade seja claramente medíocre aos olhos humanos.

Autoavaliação não funciona. O agente é ao mesmo tempo aluno e professor, e dá nota máxima a si mesmo.

Como eles resolvem: 3 agentes especializados

| Agente | Função | | --- | --- | | Planner | Transforma um prompt de 2 frases em especificação completa do produto | | Generator | Implementa uma feature por sprint | | Evaluator | Usa testes automatizados no navegador, como um usuário real |

Insight: Ter um "avaliador independente" mais exigente é muito mais fácil do que fazer o gerador ser exigente com seu próprio trabalho.

Resultados (Testes A/B)

| Configuração | Custo | Tempo | Resultado | | --- | --- | --- | --- | | Um agente (sem harness) | $9 | 20 min | App quebrado | | Harness completo | $200 | 6 horas | Software funcional + UI refinada |

11. Escola da ThoughtWorks: Quadro 2×2

ThoughtWorks aborda de diferentes ângulos — eles não estão criando produtos, mas analisando por que mais de 50 equipes de engenharia falham no mesmo ponto.

Como eles veem: classificando cada controle de harness com dois eixos

Eixo 1: Quando funciona?

  • Feedforward = antes da ação do agente (orientações)
  • Feedback = após a ação do agente (sensores)

Eixo 2: Como funciona?

  • Computacional = determinístico, de milissegundos (linter, verificador de tipos, suíte de testes)
  • Inferencial = usando LLM, em segundos (revisores de código, análise semântica)

Matriz 2×2

| |
| --- | --- | | Feedforward (orientações) |
| Feedback (sensores) |
| --- | --- | --- | | Computacional | Verificador de tipos, regras de arquitetura, suíte de testes, cobertura, testes de mutação |
| Inferencial | Documentos de especificação, restrições, revisores de código LLM, verificadores de comportamento |

Feedforward e feedback, usados isoladamente, não funcionam. Ambos são necessários.

12. Princípio 1: Contexto supera instrução

Diferentes equipes, mesma descoberta:

  • OpenAI: dê um mapa, não um manual de 1000 páginas
  • Anthropic: lista de recursos JSON + arquivo de progresso, para que o agente saiba onde está
  • Red Hat: antes de qualquer tarefa, analise o código real
  • ThoughtWorks: chamam de "Feedforward"

Conectar o agente ao "estado atual do mundo" sempre supera dar instruções abstratas.

Conectar ao arquivo real → adaptar ao código.
De descrições vagas → caminhos ilusórios e APIs inventadas.

Antes de digitar, garanta que o agente saiba onde está.

13. Princípio 2: Planejamento e execução devem ser separados

  • OpenAI: humanos projetam o ambiente, o agente executa
  • Anthropic: agente planejador roda antes do gerador
  • ThoughtWorks: checkpoints obrigatórios entre planejamento e implementação
  • Red Hat: fase 1 (mapa de impacto) e fase 2 (implementação) com uma barreira rígida

Cada abordagem descobriu: executar planejamento e execução na mesma rodada gera resultados pouco confiáveis.

Planejar não precisa ser feito por humanos, mas deve ser uma etapa separada, e seu resultado precisa ser revisado antes de começar a implementar.

14. Princípio 3: Laços de feedback são essenciais

  • OpenAI: agente integrado ao CI/CD e observabilidade
  • Anthropic: agente avaliador dedicado + testes automatizados no navegador
  • ThoughtWorks: formalizam como "sensores", alertando que só feedforward nunca garante que as orientações funcionaram

Três escolas, mesma regra, três abordagens:

| Escola | Fonte de feedback | | --- | --- | | OpenAI | Testes automatizados + CI | | Anthropic | Outro LLM | | ThoughtWorks | Uso combinado de ambos |

Eles divergem em "quem fornece feedback". Mas concordam que feedback é necessário.

Sem feedback, harness é só prompt com passos extras.

15. Princípio 4: Faça uma coisa de cada vez

  • OpenAI: quebre o objetivo em blocos menores, prioridade à profundidade
  • Anthropic: "uma feature por sprint", fazer e commitar antes de passar para a próxima
  • ThoughtWorks: ciclos de vida em fases (pré-integração → pós-integração → monitoramento contínuo)

Tentar fazer muitas coisas ao mesmo tempo faz:

  • Usar todo o contexto
  • Perder coerência
  • Descartar necessidades silenciosamente

A rotina da Anthropic: ler o progresso → escolher UMA feature → implementar → commitar → repetir.

"Princípio do progresso incremental" é uma característica comum de todos os harness bem-sucedidos.

16. Princípio 5: O código é o próprio documento

  • OpenAI: AGENT.md embutido no repositório
  • Anthropic: lista de features, arquivos de progresso, histórico git — mecanismos de continuidade do agent
  • ThoughtWorks: avalia a "harnessabilidade" — legibilidade do código para o agent

Ninguém vai manter uma base de conhecimento separada para o agent. O repositório é a única verdade.

Se uma regra, restrição ou decisão arquitetônica não estiver no código, o agent não vai saber.

Implicações práticas

  • Equipes que investem na organização do código obtem automaticamente melhor desempenho do agent
  • Repositórios bagunçados + IA agent = caos em escala

17. O declínio do Harness (Harness Decay) é real

Quando a Anthropic atualizou do Opus 4.5 para o Opus 4.6 — a decomposição do sprint (antes essencial) virou peso morto.

A capacidade de planejamento do modelo melhorou, tornando essa parte redundante.

Componentes que suportavam o harness em março, em abril viraram sobrecarga.

Depois, com o lançamento do Opus 4.7 — o modelo começou a verificar suas próprias saídas, e a responsabilidade do agente avaliador diminuiu novamente.

Isso é o declínio do Harness

Cada componente do harness assume "o que o modelo não consegue fazer". Quando o modelo melhora, essas suposições ficam obsoletas, e os componentes se tornam sobrecarga.

| Versão do modelo | Estado do harness | | --- | --- | | Opus 4.5 | Divisão de sprint + avaliação de cada sprint | | Opus 4.6 | Sem divisão de sprint + avaliação única (38% de economia de custos) | | Opus 4.7 | Auto-verificação do modelo → papel do avaliador reduzido |

Construir para deletar (Build to Delete)

Philipp Schmid sugere: "Construir para deletar."

Ao projetar cada componente do harness, já pense em removê-lo.

Teste periodicamente cada componente — desligue-o e veja se a qualidade do output muda.
Se não mudar, apague.

| Equipe | Reestruturações em 6 meses | | --- | --- | | Manus | Reestruturou harness 5 vezes | | LangChain | Reestruturou 3 vezes em 1 ano | | Vercel | Cortou 80% das ferramentas → melhor desempenho |

Essas ações não indicam má engenharia. São o resultado natural de "sobrepor coisas em modelos que evoluem rapidamente".

Componentes de harness que morrem, ao rodar, consomem tokens e não contribuem em nada — só desperdiçam.

Realidade de custos

Números honestos do teste A/B da Anthropic:

| Configuração | Custo | Tempo | Resultado | | --- | --- | --- | --- | | Um agente (sem harness) | $9 | 20 min | UI alterada, núcleo quebrado | | Harness completo (Opus 4.5) | $200 | 6 horas | Software funcional, UI refinada, física correta |

22 vezes mais caro — para um produto realmente funcional, não só uma demo de tela.

Vale a pena? Depende do quanto uma versão ruim do release custa para sua equipe.

Mas aqui é a parte que ninguém fala

O harness + modelo é uma evolução contínua.

Um harness de $200, após atualizar o modelo, fica $124.

| Linha de tendência |
| --- |
| Modelos melhores = harness mais simples = execução mais barata = resultados mais rápidos |

Os engenheiros vencedores de 2026 não escrevem o melhor código.

Eles projetam as melhores "restrições".

E estão dispostos a descartá-las assim que deixam de ser lucrativas.

Resumo completo

O que é harness

  1. Agente = Modelo + Harness
  2. Modelo = CPU, Harness = OS
  3. Mesmo modelo, harness melhor → +13% de desempenho

5 produtos de harness

  1. CLAUDE.md / AGENT.md — documentos de onboarding do agente
  2. Lista de recursos JSON — rastreamento de progresso + teste integrado
  3. Rotina de inicialização de sessão — os 7 passos iguais toda vez
  4. Contrato de sprint — negociação antes de programar
  5. Modelo de tarefa estruturada — caminhos reais de arquivo, padrões reais

3 escolas

  1. OpenAI: projetar ambiente, deixar o agente rodar
  2. Anthropic: separar "fazer" e "avaliar"
  3. ThoughtWorks: quadro 2×2 de feedforward/feedback

5 princípios universais

  1. Contexto supera instrução
  2. Planejamento e execução devem ser separados
  3. Laços de feedback são essenciais
  4. Faça uma coisa de cada vez
  5. Código é o próprio documento

Contradições intrigantes

  1. Declínio do Harness — o que funcionou mês passado, perde valor este mês
  2. Construir para deletar — testar e remover componentes mortos periodicamente
  3. Realidade de custos — modelos melhores reduzem o harness, barateando a execução

Os engenheiros vencedores de 2026 não escrevem o melhor código.
Eles projetam as melhores "restrições" — e estão prontos para descartá-las assim que deixam de ser lucrativas.

Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
  • Recompensa
  • Comentário
  • Repostar
  • Compartilhar
Comentário
Adicionar um comentário
Adicionar um comentário
Sem comentários
  • Fixado