Em agosto de 2025, uma equipe de três engenheiros da OpenAI começou um experimento fora do comum: construir um produto real de software sem escrever uma linha de código sequer. Cinco meses depois, eram 1 milhão de linhas geradas inteiramente por agentes de IA — e o que tornou isso possível não foi um modelo mais poderoso, mas a infraestrutura cuidadosamente projetada ao redor dele. Esse ambiente recebeu um nome em fevereiro de 2026: harness. E a disciplina de construí-lo, harness engineering. Se você já leu sobre agentes de IA e como eles estão transformando a engenharia de dados, este artigo vai um nível acima — direto para o que de fato separa um agente que funciona em demo de um que funciona em produção.
A história do engenheiro que parou de escrever código
Em agosto de 2025, Ryan Lopopolo, engenheiro da OpenAI, começou algo que parecia improvável: construir um produto real de software sem escrever uma linha de código sequer. A equipe era pequena — três engenheiros no início — e a missão era clara: entregar um produto funcional usando apenas agentes de IA para gerar, testar e revisar código.
Cinco meses depois, o resultado era mais de 1 milhão de linhas de código geradas por agentes. Cerca de 1.500 pull requests foram abertos, revisados e muitas vezes até mesclados pelos próprios agentes. Nenhum humano escreveu código manualmente.
O que mais chama atenção nessa história não é o volume — é o que a tornou possível. No início do experimento, a produtividade era baixa. Os agentes falhavam constantemente, ignoravam convenções, geravam código inconsistente e quebravam padrões arquiteturais. O time não respondeu trocando o modelo ou ajustando prompts. Respondeu redesenhando o ambiente ao redor dos agentes. E foi aí que as coisas começaram a funcionar de verdade.
O que é um harness, afinal? E por que se fala tanto nisso?
A palavra vem do inglês e se refere ao arreio de um cavalo — o conjunto de rédeas, sela e freio que canaliza a força de um animal poderoso numa direção útil. No contexto de IA, a metáfora é precisa: o modelo de linguagem é o cavalo, capaz de coisas impressionantes, mas sem senso de direção, sem noção de limite, sem saber quando parar. O harness é tudo que envolve esse modelo e o mantém no caminho certo.
Em termos práticos, um harness é a infraestrutura completa que governa como um agente de IA opera: as ferramentas que ele pode acessar, as restrições que o mantêm seguro, os loops de feedback que permitem autocorreção, e a camada de observabilidade que permite aos humanos monitorar o que está acontecendo.
O termo ganhou nome formal em fevereiro de 2026, a partir de duas publicações quase simultâneas. Mitchell Hashimoto, co-fundador da HashiCorp e criador do Terraform, descreveu em seu blog a prática de engenharia que desenvolveu ao trabalhar com agentes de código: sempre que um agente comete um erro, você não apenas corrige aquela instância — você constrói um mecanismo para que o erro nunca se repita. Seis dias depois, a OpenAI publicou o relato do experimento interno e formalizou o termo harness engineering.
O conceito se espalhou rápido porque tocou em algo que muita equipe já estava sentindo, mas ainda não tinha palavras para descrever.
Prompt engineering, context engineering e harness engineering: qual a diferença?
Quem trabalha com IA nos últimos anos passou por uma progressão interessante. Primeiro veio o prompt engineering — a arte de formular bem a pergunta para obter uma resposta melhor do modelo. Funcionou bem para interações pontuais. Uma pergunta, uma resposta.
Depois, por volta de 2025, o foco mudou para context engineering. Andrej Karpathy foi um dos primeiros a articular isso claramente: não basta formular bem o prompt — é preciso projetar, em nível de sistema, tudo que o modelo vê no momento em que raciocina. RAG, memória, documentos relevantes, histórico de conversa. Tudo isso é context engineering.
Mas quando agentes começaram a entrar em produção de verdade — executando tarefas longas, tomando decisões sequenciais, interagindo com ferramentas externas — ficou claro que context engineering ainda não cobria tudo. Uma classe diferente de problemas apareceu: o agente ignorava convenções da equipe, gerava código que violava a arquitetura do projeto, colidia consigo mesmo em execuções paralelas, degradava a qualidade do código ao longo do tempo.
Esses problemas não eram de "o que o modelo deve ver". Eram de "o que o sistema deve bloquear, medir e reparar".
A distinção fica mais clara assim:
Prompt engineering pergunta: o que devo pedir ao modelo?
Context engineering pergunta: o que o modelo deve saber agora para executar bem o próximo passo?
Harness engineering pergunta: como o ambiente inteiro deve ser projetado para que o agente opere de forma confiável?
As três disciplinas são complementares. Prompt engineering otimiza interações individuais. Context engineering alimenta o raciocínio do agente. Harness engineering governa a execução do sistema como um todo.
Por que o mesmo modelo se comporta diferente em projetos distintos?
Essa é uma das observações mais frustrantes de quem trabalha com agentes em produção: o mesmo modelo, com o mesmo prompt base, performa muito bem num projeto e produz resultados erráticos em outro.
A causa raramente é o modelo. É o ambiente ao redor dele.
Pense assim: a Anthropic usa o mesmo Claude para alimentar uma interface de chat, o Claude Code (agente de terminal para desenvolvimento de software) e integrações empresariais via API. Mesmo modelo, comportamentos radicalmente diferentes. O que muda é o harness.
O Claude Code gerencia acesso ao sistema de arquivos, sessões de terminal, loops de verificação e estado entre sessões. O chat gerencia histórico de conversa e filtros de segurança. O modelo não muda. O ambiente ao redor muda tudo.
Isso explica por que times que investem em harness conseguem resultados consistentes, e times que apenas melhoram prompts ficam presos num ciclo de ajuste interminável. O problema não estava onde eles estavam procurando.
O que compõe um harness na prática?
Um harness não é uma coisa só. É a soma de vários mecanismos que operam ao redor do agente.
Os principais componentes:
Arquivos de contexto e instrução
São documentos como AGENTS.md, CLAUDE.md ou .cursorrules — arquivos que o agente lê ao iniciar uma tarefa e que contêm as regras do projeto: estrutura de pastas, convenções de código, decisões arquiteturais, padrões de nomenclatura. A OpenAI aprendeu na prática que um arquivo gigante de instruções não funciona: o agente passa a ignorar as regras e cai em pattern matching genérico. A solução foi tratar o AGENTS.md não como uma enciclopédia, mas como um mapa — com documentação distribuída e contextual, próxima de cada parte do repositório que o agente está modificando.
Servidores MCP e orquestração de ferramentas
O Model Context Protocol (MCP) permite que o agente acesse ferramentas e fontes de dados externas — ler tickets de um issue tracker, automatizar um browser, pesquisar documentação interna. Um detalhe importante: conectar muitas ferramentas nem sempre é melhor. Cada definição de ferramenta consome tokens de contexto, e mais opções podem confundir o agente. A Vercel descobriu isso de forma surpreendente ao construir o v0: removeram 80% das ferramentas disponíveis ao modelo e obtiveram resultados melhores. Menos capacidade, mais confiabilidade.
Enforcement mecânico e linters customizados
Aqui é onde o harness engineering se separa mais claramente do context engineering. Em vez de apenas documentar uma regra e torcer para que o agente siga, o harness a impõe mecanicamente. A OpenAI usou linters customizados para preservar consistência arquitetural — e quando o linter falhava, a mensagem de erro era projetada para injetar instruções de correção diretamente no contexto do agente, ativando um loop de autocorreção.
Gestão de estado e memória entre sessões
Agentes que operam em tarefas longas precisam de mecanismos para manter estado entre sessões. Sem isso, cada nova chamada começa do zero — e o agente perde o fio da meada em tarefas complexas.
Observabilidade
Se o agente tem acesso a logs, métricas e snapshots do ambiente, ele pode debugar e validar o próprio código. Observabilidade não é só para os humanos — é parte do harness que permite ao agente operar de forma mais autônoma.
Garbage collection automatizado
À medida que agentes geram código em escala, padrões ruins se acumulam — dívida técnica gerada por IA, ou o que alguns chamam de "entropia". Em vez de depender de revisões humanas periódicas, a OpenAI rodava agentes de background que escaneavam continuamente o repositório em busca de divergências e abriam PRs de refatoração automaticamente.
O experimento da OpenAI: 1 milhão de linhas sem uma linha escrita à mão
O experimento interno da OpenAI entre agosto de 2025 e janeiro de 2026 é o caso de referência mais citado sobre harness engineering — e vale entender os detalhes.
A equipe começou com três engenheiros e cresceu para sete. Ao longo de cinco meses, foram mesclados cerca de 1.500 pull requests. Nenhuma linha de código foi escrita manualmente. O volume total chegou a aproximadamente 1 milhão de linhas de código gerado por agentes Codex.
O resultado mais relevante: o time reportou velocidade cerca de 10 vezes maior do que no desenvolvimento manual. Mas esse número não apareceu desde o início.
Nas primeiras semanas, a produtividade era baixa. Os agentes falhavam com frequência por razões que não tinham nada a ver com o modelo em si: ambiente mal configurado, integração fraca com ferramentas, lógica de recuperação de erros inexistente. A performance subiu de forma acentuada apenas à medida que o harness foi sendo melhorado de forma iterativa.
Esse é o padrão central do experimento: cada falha do agente era tratada como um sinal para melhorar o harness, não como um problema do modelo. Com o tempo, o repositório cruzou um limiar importante — o Codex passou a conseguir levar uma nova feature do spec ao pull request mesclado de forma completamente autônoma: escrevendo código, rodando testes, respondendo ao feedback de revisão, atualizando o código e fazendo o merge.
O experimento da Stripe vai no mesmo caminho: a empresa gera mais de 1.300 pull requests escritos por IA por semana, usando task scoping controlado pelo harness, runtimes em sandbox e gates de revisão.
Harness engineering vai mudar o que significa ser engenheiro de software?
Essa é a pergunta que mais divide opiniões — e merece ser tratada com honestidade.
O que o experimento da OpenAI mostra não é que engenheiros vão desaparecer. É que o trabalho está mudando de forma concreta. Numa equipe que opera com harness engineering, os engenheiros passaram a maior parte do tempo fazendo coisas como: definir a arquitetura do repositório de forma que o agente consiga navegar nela, escrever documentação técnica legível por máquina, construir linters que encapsulam decisões de design, criar loops de verificação e sistemas de observabilidade, e revisar código gerado por agentes — muitas vezes dando feedback que o próprio agente incorpora na próxima iteração.
É uma mudança de autoria para design de ambiente. Em vez de escrever código, o engenheiro projeta o sistema que escreve código.
Isso não significa que habilidades técnicas deixam de importar. Na prática, quem entende profundamente como sistemas de software funcionam vai projetar harnesses melhores — porque sabe que decisões arquiteturais precisam ser documentadas, que linters precisam cobrir as arestas mais críticas, que observabilidade não é opcional.
O que muda é a forma como esse conhecimento é aplicado. Menos no teclado, mais no design. E para equipes de dados e engenharia que já trabalham com pipelines, orquestração e automação, essa mudança de perspectiva pode ser mais natural do que parece.
88% dos projetos de agentes de IA nunca chegam a produção. Esse número não melhorou à medida que os modelos ficaram mais capazes. O gargalo, cada vez mais, não é o modelo. É a ausência de um harness.
Quer se aprofundar mais em agentes de IA e as tendências que estão moldando a área de dados e tecnologia no Brasil? Assine a newsletter semanal do Data Hackers e receba toda semana os conteúdos mais relevantes direto no seu e-mail.