Harness engineering não basta: o manifesto que explica por que as "fábricas de software" com IA falham

Todo mundo no Brasil está aprendendo o que é harness engineering. A Alura publicou guia. O Olhar Digital dedicou coluna. Virou pauta de newsletter, de podcast, de post no LinkedIn. O harness de IA é o termo da vez.

E no dia 23 de julho, um dos caras que ajudou a criar esse vocabulário publicou um manifesto dizendo que isso não basta. "Why Software Factories Fail (or: harness engineering is not enough)", de Dex Horthy, fundador da HumanLayer, bateu 373 pontos no Hacker News no dia da publicação.

Neste post a gente destrincha o argumento: por que as "fábricas de software" com IA degradam codebase, o que os benchmarks escondem, e o que o manifesto propõe no lugar.

TL;DR

• O que é: manifesto técnico da HumanLayer sobre por que fábricas de software 100% autônomas falham em manter qualidade de código no longo prazo.
• O argumento: os modelos não foram treinados para preservar arquitetura. Nenhuma configuração de harness resolve isso sozinha.
• Os números: relatório da Faros AI aponta +242,7% de incidentes por PR e +54% de bugs por dev desde a adoção em massa de coding agents.
• Link útil: manifesto completo no GitHub, repo público, com versão em vídeo apresentada no AI Engineer World's Fair 2026.

O contexto: como o harness de IA virou o assunto do ano

Rápido alinhamento de vocabulário. A fórmula que a indústria consolidou em 2026 é: agente = modelo + harness. O harness é tudo que roda em volta do modelo — ferramentas, permissões, loops de feedback, observabilidade. Se o conceito ainda está nebuloso, a gente já destrinchou o que é harness de IA aqui no blog.

Harness engineering, portanto, é a prática de configurar esses pontos para o agente errar menos. Mitchell Hashimoto, cofundador da HashiCorp, deu a definição que colou: "anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again" — citada no post da própria HumanLayer que lista os pontos de configuração: CLAUDE.md, servidores MCP, skills, subagents, hooks, memória, system prompt.

É engenharia de verdade, e funciona. O problema é a promessa que penduraram nela: se o harness for bom o suficiente, dá pra apagar a luz da fábrica — agentes escrevem, revisam e fazem deploy, ninguém lê uma linha, e a velocidade sobe 10x, 100x. "Code is free. Just ship more stuff", como o próprio manifesto resume a narrativa antes de desmontá-la.

É essa a régua que separa quem usa IA de quem constrói software com IA — e treinar a segunda coisa, toda semana, com código de produção na mesa, é o motivo de existir o Clã Beer and Code, a maior comunidade de engenharia de IA do Brasil.

A fábrica de luzes apagadas quebrou em três meses

Dex não está teorizando. Ele rodou o experimento. Entre julho e novembro de 2025, a HumanLayer operou uma "lights-off factory": agentes escrevendo, revisando e deployando código sem nenhum humano no circuito. Em três meses, a codebase degradou a ponto de um único bug custar semanas de debugging manual — ele mesmo conta a história como cautionary tale na entrevista ao Pragmatic Engineer.

E o padrão não é só dele. O manifesto cita um relatório da Faros AI de 2026 medindo o que aconteceu depois que os times adotaram coding agents em massa:

• +25% de comentários por review;
• +31,3% de PRs mergeadas sem revisão;
• +242,7% de incidentes por PR;
• +54% de bugs por desenvolvedor.

O próprio Dex faz a ressalva honesta: "this report is more of a correlation signal than a verifiable smoking gun". Correlação, não prova. Mas a direção bate com o que ele viu na própria fábrica — e com o que qualquer time que ligou o modo turbo em janeiro está sentindo agora no on-call.

A raiz: o modelo nunca paga o preço da arquitetura ruim

Aqui está a parte mais interessante do manifesto, e a que menos gente discute.

Por que o agente escreve código que passa nos testes e apodrece a arquitetura? Porque foi treinado exatamente pra isso. Benchmarks como o SWE-bench dão recompensa binária: teste passou, ponto. Um try-catch engolindo erro passa. Um type cast preguiçoso passa. Nas palavras do manifesto: "there is no penalty for eroding codebase maintainability".

E tem um problema estrutural por baixo: o loop de feedback. "Tests give you feedback in seconds, but the cost function of bad architecture is measured in weeks, months, maybe even years". Reinforcement learning precisa de sinal rápido. O custo de uma abstração errada aparece seis meses depois, quando o modelo já foi treinado, embarcado e vendido. Não tem como fazer backprop no arrependimento.

Isso explica, de tabela, por que o Claude Code disparou na frente: a Anthropic treina o modelo contra o próprio harness. Quem tem os pesos ajusta o comportamento na fonte. Quem só tem o harness ajusta prompt, hook e skill — útil, mas estruturalmente limitado. É o teto do harness engineering: você otimiza tudo em volta do modelo, menos a única coisa que decide se ele respeita a sua arquitetura.

A proposta: liga a luz e revisa o plano, não o diff

A saída do manifesto não é "volta pro VS Code e digita". É mover a revisão humana pra onde ela é barata: antes do código. Quatro fases:

1. Product review — documento curto: problema do usuário, critério de sucesso, mockup das telas. Alinhamento assíncrono antes de qualquer código.
2. System architecture — diagramas de sequência, contratos de endpoint, modelo de dados.
3. Program design — o nível que quase todo time pula: call-stack, diff da árvore de arquivos, assinaturas de métodos e tipos. É aqui que a arquitetura ruim fica visível barata.
4. Vertical slices — implementar por feature (banco → service → API → front), em fatias de 100 a 200 linhas revisáveis, não por camada horizontal.

A frase-síntese do texto: "30 minutes of planning saves hours of review". E a troca proposta é explícita — abandonar a ilusão dos 10-100x sem revisão e aceitar 2-3x com segurança. Menos sexy no pitch, mais honesto na produção.

Limitações e pontos de atenção

Antes de imprimir o manifesto e colar na parede do squad, três ressalvas.

Os dados são correlação. O próprio autor admite. Times que adotaram agentes agressivamente também estavam sob pressão de shipar mais rápido — separar as variáveis é difícil.

Dex vende ferramenta. A HumanLayer constrói um IDE colaborativo para agentes. Um manifesto dizendo "o jeito atual falha, precisa de humano no loop com tooling melhor" é também material de marketing. No Hacker News teve quem cutucasse exatamente isso — um comentário resume: "você não é parte da máquina, você É a máquina".

A crítica tem contraponto. Parte da thread argumenta que o gargalo real é outro: LLMs não fazem planejamento de longo prazo nem escolhem abstrações — e nesse caso nem as 4 fases salvam, porque o humano vira o arquiteto de tudo de novo. Vale ler a discussão completa antes de formar opinião.

FAQ rápido

Harness engineering morreu? Não. O próprio manifesto trata harness como necessário — CLAUDE.md, skills, hooks e MCP continuam sendo o básico bem feito. O ponto é que ele é insuficiente para segurar qualidade arquitetural sem revisão humana estruturada.

Harness engineering e context engineering são a mesma coisa? Não. Pela taxonomia da própria HumanLayer, harness engineering é um subconjunto de context engineering — que também cobre prompts, memória e recuperação de informação. O termo context engineering foi cunhado pelo Dex no 12-factor agents.

Então software factory não funciona nunca? Funciona onde manutenibilidade não importa: protótipo, projeto descartável, greenfield curto. O manifesto chama de vibe coding e não condena — o problema é brownfield, que ele redefine como "qualquer codebase que já começou a degradar".

O que eu aplico no meu time amanhã? Mova a revisão pra montante: exija plano escrito (arquitetura + design de programa) antes do agente codar, e quebre a implementação em fatias verticais de 100-200 linhas. Revisar plano é minutos; revisar PR de 3 mil linhas é loteria.

Conclusão

O manifesto não é anti-IA. É anti-autoengano. Harness de IA bem configurado continua sendo o piso — mas o teto é o modelo, e o modelo não foi treinado pra se importar com a sua arquitetura.

A provocação que fica: o próximo salto talvez não venha de mais um arquivo de configuração, e sim de labs treinando com sinal de manutenibilidade de longo prazo. Até lá, a vantagem é de quem planeja antes, revisa cedo e lê o código.

Como o próprio Dex fecha: dá pra se convencer de que qualidade não importa mais e correr atrás de 10-100x — ou abraçar as restrições e andar 2-3x mais rápido, com segurança.