Por que é que precisas de aprender Engenharia de Harness? Análise completa de 5 produtos, 3 escolas e 5 princípios universais

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 design a cada 6 meses. Este artigo é originado do artigo de @sairahul1 no X, organizado e compilado pelo Dongqu.
(Prévia: Introdução à Engenharia Harness (Engenharia de IA): Padrões de programação mais recentes da OpenAI, ensinando como 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 deste artigo

Alternar

    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: Estrutura 2×2
    • Insights deles: classificar cada controle de harness com dois eixos
    • Matriz 2×2
    1. Princípio 1: Contexto supera instruções
    1. Princípio 2: Planejamento e execução devem ser separados
    1. Princípio 3: Laços de feedback são inegociáveis
    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
    • Assim é 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 manualmente.

Escrito por agentes de IA.

O sistema que humanamente projetaram é aquele que torna o agente confiável.

Este sistema agora tem nome — Engenharia Harness.

Em semanas, a Anthropic publicou 3 artigos relacionados. ThoughtWorks organizou em um framework. 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 modelos mentais que você realmente 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 ao agente onde está
  • Ferramentas às quais ele tem acesso

Remover o harness → um modelo de linguagem que adivinha dentro do seu código.

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

Este nome vem de arreios. Harness são rédeas, sela, bridão — direcionando um animal forte, mas difícil de prever, para uma direção ú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 oferece 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ê, quando vê) | | Agente | Aplicação 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, seus agentes na linha de produção quebram.

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. Arquivo AGENT.md / CLAUDE.md

Produto mais universal de harness.

Arquivos markdown dispersos pelo código. Cada sessão do agente começa lendo — como um onboarding de um novo engenheiro.

O que contém?

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

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.

5. Listas de Recursos JSON (Rastreador de progresso)

Quando o agente cobre várias sessões construindo um app, cada janela de contexto 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 6 horas de autonomia.

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

Cada sessão começa do mesmo jeito. Sempre.

A rotina de 7 passos da Anthropic:

  1. Confirmar diretório de trabalho
  2. Ler git log e arquivos de progresso
  3. Buscar na lista de features a mais prioritária ainda 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 ela: o agente passa os primeiros 20 minutos entendendo o estado atual, repetindo tarefas. Com ela: entra com informações e vai direto ao trabalho.

7. Contratos de Sprint

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

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, a implementação começa.

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

Por que é importante

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

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 dos arquivos (não uma fantasia)
  • Nomes de símbolos existentes
  • Padrões já utilizados
  • Critérios de aceitação concretos

Só então começa a implementação.

Parece óbvio. Mas a maioria das equipes pula essa etapa.

O agente adivinha a estrutura de arquivos, inventa APIs inexistentes, faz algo que não combina 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 escrita manual.

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

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
  • Agente integrado 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% das PRs internas 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 quando a qualidade é claramente medíocre aos olhos humanos.

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

Como eles resolvem: 3 agentes especializados

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

Insight: fazer um "avaliador" independente ser 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 minutos | App quebrado | | Harness completo | $200 | 6 horas | Software funcional + UI refinada |

11. Escola da ThoughtWorks: Estrutura 2×2

ThoughtWorks aborda de diferentes ângulos — eles não criam produtos, mas observam 50+ equipes de engenharia falhando nos mesmos pontos.

Como eles veem: classificar 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, milissegundos (linter, verificador de tipos, suíte de testes)
  • Inferencial = usando LLM, segundos (revisores de código, analisadores semânticos)

Matriz 2×2

| | | --- | | Feedforward (orientações) | | Feedback (sensores) | | --- | --- | --- | | Computacional | sistema de tipos, linter, regras de arquitetura | suite de testes, cobertura, testes de mutação | | Inferencial | documentos de especificação, restrições descritivas | 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ções

Diferentes equipes, mesma descoberta:

  • OpenAI: forneça um mapa, não um manual de 1.000 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: chamado de "Feedforward"

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

Conectar ao arquivo real → adaptar ao código. Partir 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 antes do agente 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 — mesmo que por IA — não precisa ser feito por humanos, mas deve ser uma etapa separada, e sua saída precisa ser revisada antes de começar.

14. Princípio 3: Laços de feedback são inegociáveis

  • OpenAI: agente integrado ao CI/CD e observabilidade
  • Anthropic: agente Avaliador dedicado + automação de navegador
  • ThoughtWorks: formalizado como "sensores", alertando que só feedforward nunca garante que as orientações funcionaram

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

| Escola | | --- | | Fonte do 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, o harness é só um prompt com passos extras.

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

  • OpenAI: quebre o objetivo em blocos menores, prioridade profunda
  • Anthropic: "uma feature por sprint", terminar e commitar
  • ThoughtWorks: fases de ciclo de vida (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 progresso → escolher UMA feature → implementar → commitar → repetir.

"Princípio do progresso incremental" é o traço 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 — mecanismo de continuidade do agente
  • ThoughtWorks: avalia a "harnessabilidade" — legibilidade do código para o agente

Ninguém mantém uma base de conhecimento separada para o agente. O repositório é a única verdade.

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

Implicações práticas

  • Equipes que investem na organização do código obtem desempenho melhor do agente gratuitamente
  • Repositórios desorganizados + IA agente = 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.

De março a abril, componentes do harness que suportavam a carga passaram a ser 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.

Isso é o declínio do Harness

Cada componente do harness assume "o que o modelo não consegue fazer" como hipótese. Quando o modelo evolui, essas hipóteses 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 | Autoavaliaçã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, faça-o de modo que possa ser removido.

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

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

Essas não são sinais de má engenharia. São consequência natural de "sobrepor coisas em modelos que evoluem rapidamente".

Componentes de harness mortos, ao rodar, consomem tokens e não contribuem em nada — pura perda.

19. Realidade de custos

Dados honestos do teste A/B da Anthropic:

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

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

Vale a pena? Depende do quanto uma versão ruim do release custa ao seu time.

Mas aqui é a parte que ninguém fala

A combinação Harness + modelo é evolutiva.

$200 de harness, quando atualiza o modelo, fica $124.

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

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

Eles são os que projetam as melhores "restrições".

E estão dispostos a jogar fora essas restrições assim que elas deixam de gerar lucro.

Resumo completo

O que é harness

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

5 produtos de harness

  1. CLAUDE.md / AGENT.md — documentos de onboarding do agente
  2. Lista de recursos JSON — rastreamento de progresso + suíte de testes integrada
  3. Rotina de inicialização de sessão — os 7 passos padrão
  4. Contrato de sprint — negociação prévia antes de codificar
  5. Modelo de tarefas estruturadas — caminhos reais de arquivos, padrões reais

3 escolas

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

5 princípios universais

  1. Contexto supera instruções
  2. Planejamento e execução devem ser separados
  3. Laços de feedback são inegociáveis
  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 — modelo melhor, harness mais simples, execução mais barata

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údos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
  • Recompensa
  • Comentar
  • Republicar
  • Partilhar
Comentar
Adicionar um comentário
Adicionar um comentário
Nenhum comentário
  • Fixado