Harness engineering: o gargalo do vibe coding virou o ambiente

O modelo já sabe escrever o código que você pediu. O que ele não sabe é onde está pisando. gbrl808 colocou o problema numa frase:

"O gargalo não é mais a inteligência do modelo, é a qualidade do ambiente onde ele opera."

Harness é esse ambiente: as instruções, a estrutura do repositório, os linters, os testes, os arquivos de progresso, os scripts de setup. O modelo é a LLM, harness é o resto. Fazer esse resto de propósito, com projeto e manutenção, é o que ele chama de harness engineering.

Um engenheiro brilhante no primeiro dia de empresa

A analogia dele é de contratação. O modelo é uma pessoa recém-contratada, capaz de escrever qualquer coisa. Largue essa pessoa num repositório sem README, sem arquitetura documentada, sem testes e sem integração contínua, e ela vai fazer bobagem.

"Não porque ele é burro, mas porque ele não tem contexto."

Ela decide pela experiência que trouxe de fora, porque é a única que tem, e erra tudo que é específico daquele projeto. Harness é o onboarding desse engenheiro, o que transforma um modelo poderoso num agente em que dá para confiar.

A rota que o GPS traça e o recálculo que ele faz no caminho

Para explicar o que falta, ele pega 2 conceitos de engenharia de controle. Feed forward são as instruções dadas antes da execução, para aumentar a chance de dar certo: a spec, o agents.md, as regras de arquitetura, as skills. É preventivo. Feedback é observar o resultado depois e corrigir o que saiu errado, e são os sensores que fazem isso: os linters, os testes, os type checkers, o agente revisor.

"Feed forward é a rota que ele traça antes de sair. O feedback é quando ele detecta que tu saiu ou errou a saída e recalcula em tempo real."

E o motivo de precisar dos dois lados juntos:

"Se tu tivesse só a rota, tu ia te perdendo no primeiro erro. Só com o recálculo tu sai sem direção nenhuma, então tu precisa dos dois."

A maior parte do que já se usa em vibe coding mora no primeiro lado. O spec driven development resolve a entrada do trabalho, e resolve bem, mas uma spec diz o que fazer sem verificar se foi feito. Os sensores são a metade que costuma ficar de fora.

O que conta como sensor

Sensor é a ferramenta que roda depois do código e devolve um sinal de passou ou não passou. O linter, a suíte de testes, o type checker, um agente revisor rodando contra uma lista de critérios. Nenhum deles é parte do agente que escreveu o código. São ferramentas externas, que rodam por fora e olham para o que ficou no disco. Essa separação é o que vira um contrato entre o agente implementador e o validador: um escreve, o outro mede, e a especificação é o que os dois compartilham. Foi o mesmo caminho de vibe coding para playbook separado do harness principal.

O valor desse sinal está em ele ser um resultado medido, e não mais uma instrução. Um teste vermelho é uma informação nova que o agente não tinha quando começou, e é ela que dá a ele o que corrigir na iteração seguinte. É assim que a autocorreção acontece dentro da própria tarefa, antes de o código chegar em você.

Um harness sem sensores fica só com o lado do feed forward. A instrução pode estar boa, a arquitetura documentada, a spec detalhada, e ainda assim nada no ambiente mede o que saiu. O agente entrega e segue em frente porque não existe nenhum sinal contradizendo a suposição de que ficou pronto. Montar o sensor é decidir, antes de começar, qual comando responde essa pergunta.

Sim, gasta mais token

Ele mesmo levanta a objeção e responde que não tem como fugir dela. Rodar os sensores e uma verificação depois da implementação custa mais que só gerar código e parar por ali, e a comparação que ele usa é com code review, que também custa tempo e ninguém propõe cortar. Na demonstração, a implementação inteira daquela rodada saiu por 51 centavos, verificação incluída.

O que se compra com isso aparece no longo prazo. O alvo é o slop acumulado: código que compila mas viola as regras de arquitetura, duplica lógica e piora a cada sessão. O raciocínio dele é de composição. Se você perde um pouco de qualidade a cada funcionalidade (ele joga 5% como hipótese, não como medição), um sistema inteiro construído assim termina em código horrível. Os sensores rodando em cada iteração são o que segura a qualidade no lugar.

Por onde começar no seu próximo projeto de vibe coding

Pegue uma tarefa e feche o loop nela. Antes de escrever a primeira linha, defina qual comando decide se ela passou: o teste que precisa ficar verde, o linter que não pode acusar nada, o type checker sem erro. Rode esse comando ao fim de cada iteração e devolva a saída inteira para o agente quando ele falhar. Você vai descobrir na hora quantas tarefas declaradas prontas não passam no seu próprio critério.

Os artigos que saíram sobre o tema em fevereiro de 2026 chegam à mesma conclusão dele, e ela muda o que vale a pena melhorar: o próximo salto do vibe coding vem do ambiente que você monta em volta do modelo. Vale assistir à live para ver os sensores rodando na tela.