Harness Engineering Não É Novo — Mas Nomeá-lo Importa

A OpenAI publicou um artigo chamado “Harness engineering: leveraging Codex in an agent-first world”, de Ryan Lopopolo. A tese central: harness engineering é uma disciplina de engenharia emergente, definida pela prática de orquestrar agentes de IA como principal mecanismo de produção de software. Eles construíram um produto interno ao longo de cinco meses com agentes Codex — cerca de um milhão de linhas de código, mil e quinhentos PRs, começando com três engenheiros. Zero código escrito manualmente, segundo eles. Uma média de 3,5 PRs por engenheiro por dia.

Os números impressionam. A tese merece escrutínio.

O Que a OpenAI Está Dizendo

Antes de criticar, vale entender o argumento completo. A equipe da OpenAI chegou a conclusões práticas que refletem experiência real:

AGENTS.md como mapa, não como enciclopédia. Tentaram consolidar todas as instruções em um único arquivo extenso. Não funcionou. Migraram para um AGENTS.md de aproximadamente cem linhas que aponta para um diretório docs/ estruturado como sistema de registro. O agente precisa saber onde encontrar a informação — não precisa receber tudo de uma vez.

O repositório como fonte única de verdade. A frase mais reveladora do artigo: “Do ponto de vista do agente, qualquer coisa que ele não consegue acessar em contexto enquanto executa efetivamente não existe.” Isso não é insight novo para quem trabalha com LLMs, mas é a primeira vez que vejo a OpenAI articulá-lo com essa clareza — e as implicações para arquitetura de repositório são profundas.

Invariantes, não implementações. Em vez de ditar como o agente deve escrever código, a equipe definiu o que o código deve respeitar. Linters customizados. Testes estruturais. O que chamaram de “taste invariants” — logging estruturado, convenções de nomenclatura, limites de tamanho de arquivo. As mensagens de erro dos linters injetam remediação diretamente no contexto do agente. É engenharia de contexto aplicada a qualidade de código.

Gestão de entropia. Aqui está o dado mais honesto do artigo: 20% do tempo da equipe é gasto limpando o que eles chamam de “AI slop” — código gerado que replica padrões existentes, inclusive os ruins. Agentes propagam padrões. Se o repositório contém padrões ruins, o agente os replica com eficiência industrial. A solução: “princípios de ouro” documentados e tarefas recorrentes de “coleta de lixo” no backlog.

Throughput cresceu com a equipe. Contrariando a Lei de Brooks — que prevê que adicionar pessoas a um projeto atrasado o atrasa mais — a equipe reportou que o throughput aumentou ao expandir de três para sete engenheiros. A explicação oferecida: agentes paralelizam trabalho de forma que humanos sozinhos não conseguem.

São observações úteis. Algumas, genuinamente perspicazes. O problema não está nos dados. Está no enquadramento.

Por Que “Nova Disciplina” É Uma Afirmação Exagerada

Vamos decompor as práticas que a OpenAI descreve sob o rótulo de harness engineering:

Documentação estruturada para orientar execução automatizada. Isso é engenharia de documentação. Existe há décadas. Makefiles, READMEs de projeto, runbooks de operação — todos seguem o mesmo princípio: documentar para que uma entidade não humana (ou um humano que não conhece o contexto) possa executar.
Validação automatizada via linters e testes estruturais. Isso é integração contínua. Jenkins, Travis CI, GitHub Actions — a indústria resolve esse problema desde os anos 2000. A diferença é que agora o “desenvolvedor” que precisa passar nos testes é um LLM em vez de um humano.
Gestão de repositório como interface de sistema. Isso é infraestrutura como código aplicada à organização do projeto. O conceito de “repositório como fonte de verdade” é fundacional em DevOps.
Controle de qualidade por invariantes em vez de prescrição. Isso é design por contrato, formalizado por Bertrand Meyer nos anos 1980.
Gestão ativa de degradação de código. Isso é refatoração contínua. Martin Fowler escreveu o livro canônico sobre isso em 1999.

Nenhuma dessas práticas é nova. O que é novo é o público-alvo: agentes de IA baseados em LLMs. E essa diferença importa — mas não o suficiente para justificar a criação de uma disciplina inteiramente nova.

O Que Eles Não Disseram

O artigo da OpenAI tem lacunas que merecem atenção.

“Zero código escrito manualmente” depende de uma definição estreita. Quem escreveu o AGENTS.md? Quem definiu os linters customizados? Quem redigiu os “princípios de ouro”? Quem compôs os prompts que direcionam os agentes? Esses são artefatos de engenharia. São código no sentido mais fundamental — instruções que determinam o comportamento de um sistema. A afirmação de “zero código manual” só se sustenta se você definir “código” como “linhas em uma linguagem de programação compilada ou interpretada”. É uma definição que ignora metade do trabalho de engenharia moderna.

Nenhuma identidade de produto. O artigo descreve um produto interno construído em cinco meses, mas não diz o que o produto faz. Não sabemos para quem é, que problema resolve, se tem usuários, se gera receita. Um milhão de linhas de código é um número. Sem contexto de produto, é um número vazio.

Nenhuma métrica de qualidade. Mil e quinhentos PRs em cinco meses. Qual a taxa de defeitos? Quantos bugs em produção? Qual o tempo médio de resolução de incidentes? Qual o coverage de testes? O artigo reporta throughput sem reportar qualidade. Isso é como avaliar uma fábrica pela quantidade de peças produzidas sem medir quantas são defeituosas.

Nenhuma análise de custo. Quanto custa operar agentes Codex em escala para uma equipe de sete? Qual o consumo de tokens? Qual o custo por PR? A ausência de dados econômicos é especialmente notável vindo de uma empresa que vende a ferramenta utilizada.

Autointeresse comercial não declarado. A OpenAI está descrevendo como é produtivo usar o Codex para construir software. A OpenAI vende o Codex. Isso não invalida as observações — muitas são empiricamente sólidas. Mas o conflito de interesse deve ser declarado, não ignorado.

O Comparativo Que Importa

A Anthropic publicou, em novembro de 2025, o documento “Effective Harnesses” — um guia sobre como estruturar o ambiente ao redor de agentes de codificação. O padrão que descrevem: um Initializer que prepara o contexto, seguido de um Coding Agent que executa. Não usaram o termo “harness engineering”. Mas descreveram a mesma disciplina.

A Manus, uma das startups mais visíveis em agentes de IA, reescreveu seu harness cinco vezes em seis meses. Não publicaram um manifesto sobre uma nova disciplina. Simplesmente iteraram sobre o mesmo problema que a OpenAI descreve.

O AGENTS.md — o formato de arquivo que a OpenAI destaca como central — já está presente em mais de sessenta mil projetos, segundo a Linux Foundation (AAIF, dezembro de 2025). A adoção aconteceu organicamente, sem que ninguém precisasse batizá-la de disciplina.

A convergência é reveladora. Quando organizações independentes chegam às mesmas soluções sem coordenar, o padrão subjacente é real. A necessidade de um nome novo é questionável.

A Analogia Correta: DevOps, Não Descoberta

Harness engineering está para a era agêntica assim como DevOps esteve para a era da nuvem.

DevOps não inventou monitoramento. Não inventou integração contínua. Não inventou infraestrutura como código. O que DevOps fez foi convergir práticas existentes sob um rótulo que criou identidade profissional, expectativas organizacionais e mercado de trabalho. O nome criou a disciplina — não porque as práticas eram novas, mas porque nomeá-las coletivamente permitiu que organizações as tratassem como investimento estratégico em vez de custo operacional.

Harness engineering pode cumprir a mesma função. O que é genuinamente novo não são as práticas individuais — é o público-alvo (agentes de IA) e o grau de automação que esse público permite. Documentar para um LLM é diferente de documentar para um humano. Testar código gerado por agente exige calibração diferente de testar código humano. Gerenciar entropia em um repositório onde agentes produzem código com eficiência industrial é um problema de escala que não existia antes.

Mas chamar isso de “nova disciplina de engenharia” é como dizer que DevOps foi uma nova disciplina de operações. Não foi. Foi a convergência de práticas existentes em torno de uma nova realidade operacional.

O Dado Que Deveria Preocupar Mais

O relatório da LangChain de 2025 mostra que 57% das organizações têm agentes de IA em produção. Mas 32% identificam qualidade como a principal barreira para expansão. O Gartner projeta que 40% dos projetos de IA agêntica serão cancelados até 2027.

Esses números contam uma história que o artigo da OpenAI não aborda: a maioria das organizações que adotam agentes de IA não tem a infraestrutura que a equipe da OpenAI descreve. Não tem AGENTS.md. Não tem linters customizados. Não tem processos de “coleta de lixo” para entropia. Não tem engenheiros dedicados a manter a qualidade do repositório como interface para agentes.

O problema real não é que harness engineering precisa de um nome novo. O problema é que a maioria das organizações não pratica os fundamentos que a OpenAI empacota sob esse rótulo — com nome ou sem nome.

O Que Isso Significa Para Quem Constrói Com Agentes

Se você está construindo software com agentes de IA — e em 2026, é provável que esteja — três coisas importam mais do que a terminologia.

Primeiro, trate seu repositório como interface, não como armazenamento. Isso é a contribuição mais concreta do artigo da OpenAI. Agentes operam a partir do que conseguem acessar no contexto. Se suas convenções estão na cabeça de um engenheiro sênior em vez de documentadas no repositório, o agente vai ignorá-las. Não por rebeldia — por ignorância estrutural.

Segundo, invista em invariantes, não em instruções. Dizer ao agente “use logging estruturado” é frágil. Criar um linter que rejeita código sem logging estruturado e inclui a correção na mensagem de erro é robusto. A diferença é entre esperar comportamento e exigir comportamento. Engenheiros de software reconhecem esse padrão: é a diferença entre documentação e testes automatizados.

Terceiro, reserve tempo para gestão de entropia. O dado de 20% da OpenAI é provavelmente conservador para equipes com menos maturidade. Agentes amplificam padrões — bons e ruins. Se você não tem um processo regular de identificar e corrigir padrões degradados no repositório, a qualidade vai decair exponencialmente com o volume de código gerado. Não é diferente do conceito de dívida técnica. É dívida técnica com taxa de juros mais alta.

O Ponto Real

A OpenAI quer que harness engineering seja reconhecida como uma disciplina nova. A Anthropic documenta as mesmas práticas sem reivindicar novidade. A comunidade open-source adota os mesmos padrões organicamente.

A verdade está no meio: as práticas são antigas, mas sua convergência em torno de agentes de IA é significativa. Nomear essa convergência tem valor — assim como nomear DevOps teve valor. O perigo é confundir o ato de nomear com o ato de inventar.

Para nós na Victorino, isso é familiar. Nosso CLAUDE.md é essencialmente o que a OpenAI chama de AGENTS.md. A governança que integramos desde o primeiro dia — e não aparafusamos depois — é exatamente o que harness engineering descreve em sua melhor versão. O problema da entropia que a OpenAI quantifica em 20% é precisamente o que justifica operações contínuas de IA em vez de implementação única.

Harness engineering não é uma descoberta. É um reconhecimento tardio de que agentes de IA precisam da mesma disciplina de engenharia que qualquer outro sistema em produção — adaptada, não inventada do zero.

O nome é novo. A disciplina não é. E está tudo bem assim.

Fontes

Ryan Lopopolo. “Harness engineering: leveraging Codex in an agent-first world.” OpenAI, 2026.
Anthropic. “Effective Harnesses.” Documentação de melhores práticas, novembro 2025.
Linux Foundation (AAIF). Dados sobre adoção do formato AGENTS.md, dezembro 2025.
LangChain. “State of AI Agents.” Relatório anual, 2025.
Gartner. Projeção sobre cancelamento de projetos de IA agêntica, 2025.
Manus. Relatos sobre iterações de harness de agentes, 2025–2026.
Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1988.
Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.

Na Victorino Group, a governança de agentes de IA não é uma camada que adicionamos depois — é a fundação sobre a qual construímos. Se você está operando agentes em produção e precisa de clareza sobre como estruturar o harness que os governa, vamos conversar. | www.victorino.com.br