Em novembro de 2025, Justin Young, da Anthropic, publicou um post sobre o que a empresa aprendeu rodando coding agents de longa duração. Uma observação daquele texto ficou na minha cabeça. Ele descreveu um modo de falha em que o Claude, depois de avançar um pouco em um projeto, olhava para o estado do trabalho, via que algumas coisas tinham sido construídas e declarava a tarefa concluída. O verbo era “declarar”. O agente rodava um curl, recebia um 200 de volta, dava a integração por encerrada e seguia em frente.
Cinco meses depois, Birgitta Böckeler, da Thoughtworks, publicou o texto mais claro que já li sobre o que devemos construir em volta do modelo para evitar exatamente isso. Ela chamou essa camada de harness e a dividiu em duas metades: guides (controles feed-forward que antecipam o comportamento do agente e o direcionam antes de ele agir) e sensors (controles de feedback que observam o resultado e ajudam o agente a se corrigir).
Dois meses antes do texto de Böckeler, Kief Morris já havia publicado o framework de loops que deu a essa camada o seu formato estratégico.
O que o harness é de verdade
Se você falar “harness” para a maioria dos engenheiros em 2026, eles vão concordar com a cabeça e dizer que já fazem isso. Aí você pergunta o que eles querem dizer com isso e recebe uma lista de três itens: linters, testes, CI. Isso não é um harness. É uma fatia pequena da camada de sensors, sem nenhum guide e sem nenhum julgamento.
O enquadramento de Böckeler é o que adotei internamente na Cheesecake Labs. O harness tem duas metades.
Guides são feed-forward
Eles moldam o que o agente faz antes de ele agir. O arquivo CLAUDE.md na raiz do projeto, o template de PR que o agente lê antes de abrir um pull request, a spec que ele precisa implementar, a skill que codifica como aquele time faz migrations de banco de dados, as convenções de arquitetura escritas em texto corrido que o agente lê a cada sessão.
Guides são baratos e acumulam valor com o tempo. São também a parte do harness em que a maioria dos times menos investe, porque nada disso entrega uma feature sozinho.
Sensors são feedback
Os sensors observam o que o agente fez e dizem a ele se aquilo funcionou. Linters e type checkers, claro, mas também suítes de teste que realmente rodam, agentes de code review separados que leem o diff, checagens de fidelidade que comparam a implementação com a spec, hooks no commit e na abertura do PR e o judge model que avalia o trabalho contra os critérios de aceitação. Os sensors são como o agente descobre que errou.
O ponto mais afiado de Böckeler é que você precisa dos dois. Só com sensors, você fica com um agente que repete o mesmo erro, porque nada informou a regra certa lá no início. Só com guides, você fica com um agente que segue as regras, mas nunca descobre se elas produziram o resultado certo. Um harness de verdade é o loop fechado entre os dois.
Leia mais: Spec-Driven Development: como capturar a intenção antes de queimar tokens
A escada de maturidade. Onde a maioria dos times está.
O enquadramento de Morris, com as posições in / on / out of the loop, é a ferramenta de diagnóstico mais útil que tenho hoje para conversar com líderes de engenharia. Eu pergunto onde o time deles está e a resposta já me diz no que investir em seguida.
In the loop
O engenheiro revisa cada linha que o agente produz. Ele é o gatekeeper do loop mais interno, onde o código é gerado. Nas palavras de Morris: “o desafio, quando insistimos em nos envolver de forma próxima demais no processo, é que nos tornamos um gargalo”.
A maioria dos times que eu vejo mora aqui: usam Claude Code, entregam features e têm engenheiros seniores gastando metade do dia revisando na mão diffs gerados por IA. O agente ficou mais rápido e o revisor virou a restrição.
On the loop
O engenheiro projeta e mantém os mecanismos que produzem e validam o trabalho do agente. Morris de novo: “em vez de inspecionar pessoalmente o que os agentes produzem, podemos fazer com que eles produzam melhor”.
É aqui que harness engineering vira uma categoria de trabalho de verdade. Você para de corrigir PRs ruins um a um e passa a corrigir o sistema que os produziu. O trabalho do engenheiro sênior deixa de ser revisar linhas e passa a ser construir o harness.
Out of the loop
O harness está maduro o suficiente para o agente rodar de forma majoritariamente autônoma, enquanto a pessoa audita resultados agregados. Morris chama esse estágio de casa natural do que muita gente chama vagamente de “vibe coding”, mas só quando o harness é forte o bastante para manter seguro o código escrito assim. Sem esse harness, “out of the loop” é só entregar bugs mais rápido.
Flywheel
Existe um quarto degrau que Böckeler sugere, mas não nomeia: o harness melhorando a partir dos próprios resultados. Gates que falham viram atualizações no CLAUDE.md, PRs rejeitados viram novos testes e o harness vai se acumulando. É aqui que está a alavancagem.
O salto de in para on é a maior jogada de carreira dos próximos dois anos para engenheiros seniores e a maior jogada de arquitetura para líderes de engenharia. O salto seguinte, de on para out, exige que o harness seja realmente bom.
Completion gates. A cascata.
Esta é a parte do harness que a maioria dos times não construiu e mais precisa. A premissa é simples: “pronto” não é o agente dizer que está pronto, é o sistema provar que está. Uma tarefa passa por uma cascata de checagens, com os filtros mais baratos primeiro, antes de ser aceita. Cada gate captura um modo de falha específico e, quando reprova, devolve um motivo classificado e uma correção acionável.
A cascata que eu rodo na Cheesecake Labs tem cinco gates. Nenhum deles é inédito isoladamente. A ordem e o enquadramento são meus, construídos em cima do modelo de guides e sensors de Böckeler e da taxonomia de modos de falha da Anthropic.
Gate 1: estrutural
Lint, typecheck, testes unitários. Barato e determinístico. Pega o que a Anthropic chama de falha de “marcar como concluído sem verificação”: o agente rodou um curl, recebeu um 200 e declarou a integração funcionando. Na minha experiência, esse gate reprova algo entre 30 e 50% dos PRs de primeira tentativa do agente. É um sinal saudável. Significa que o gate está fazendo o trabalho dele.
Gate 2: integridade de arquivos
Arquivos críticos intocados. O agente apagou testes silenciosamente para eles passarem? Reescreveu um contrato de API em vez de se adequar a ele? Alterou um arquivo de configuração fora do escopo da mudança? São essas as falhas que chegam à produção como regressões silenciosas. Uma allow-list simples com os arquivos que cada tarefa pode tocar pega a maior parte delas. A correção cabe em uma linha de YAML. Poucos times têm isso.
Gate 3: suficiência
O diff realmente cobre o escopo da spec? Um agente que entrega metade da feature e declara o resto como “trabalho de follow-up” é o modo de falha mais comum que vejo em fluxos com plan mode. A correção é mecânica: cada tarefa no tasks.md tem critérios de aceitação, cada PR corresponde a uma tarefa e o gate verifica se o diff tocou aquilo que a tarefa dizia que ia tocar.
Gate 4: fidelidade
A implementação realmente faz o que o design dizia que ela faria? Este é o gate que a maioria dos times pula. A mecânica é emprestada de ferramentas de avaliação de RAG, como o RAGAS, e adaptada: calcular a similaridade semântica entre o diff e o markdown de design. Barato, baseado em embeddings, roda em segundos. É um filtro, não um veredicto. Se a similaridade fica abaixo de um limite, o PR reprova antes de custar um judge model.
Gate 5: judge LLM
Um modelo separado, de preferência um modelo diferente, lê a spec, o design, os testes e o diff e produz um aceite ou uma rejeição explícita, com motivos. Zheng et al. (2023) mostraram que LLMs fortes atuando como juízes concordam com humanos em mais de 80% das vezes, “o mesmo nível de concordância que existe entre humanos”.
O trabalho de Agent-as-a-Judge da Meta, de 2024, estendeu a ideia especificamente para coding agents e concluiu que a abordagem “supera drasticamente o LLM-as-a-Judge e é tão confiável quanto o nosso baseline de avaliação humana”. O judge roda apenas em PRs que já passaram pelos gates 1 a 4, então é o gate mais caro, mas também o que você paga com menos frequência.
A ordem importa porque o judge é caro em tokens e em latência. Você só paga por ele nos PRs que já passaram pelas checagens de estrutura, integridade, suficiência e fidelidade. Quando o judge entra, ele está avaliando um trabalho plausivelmente correto, não um trabalho que já tinha falhado no lint.
Leia mais: As três eras do software: do autocomplete ao desenvolvimento agêntico
LLM-as-Judge. Nunca deixe o executor avaliar a si mesmo.
Quero sublinhar o argumento estrutural aqui, porque essa é a mudança que os times mais resistem em fazer.
O agente que implementou a feature não é quem decide se ela está pronta. É o mesmo conflito de interesse de um desenvolvedor revisando o próprio PR. O agente executor tem um incentivo (embutido no jeito como o prompt dele foi escrito) para convergir em “concluído”. Se você deixar que ele avalie a si mesmo, a avaliação vai ser generosa. A única correção é ter um avaliador separado.
Na prática, isso significa dois agentes, de preferência dois modelos diferentes. Na Cheesecake Labs, rodamos Sonnet 4.6 para implementação e Opus 4.7 para julgamento. O judge vê apenas a spec, o design, os testes e o diff. Ele não vê o raciocínio do executor. Não vê o histórico de conversa. E produz um veredicto estruturado: aceitar, rejeitar (com motivos classificados) ou pedir esclarecimento (com perguntas específicas).
A taxa de rejeição na primeira passada fica entre 15 e 25%, dependendo do time e da qualidade da spec. Isso não é sinal de que o executor é ruim. É sinal de que o judge está fazendo o trabalho dele. Sem o judge, esses 15 a 25% do trabalho seguiriam adiante marcados como “pronto” e só apareceriam mais tarde: no QA, na sprint seguinte ou em produção.
O relatório DORA 2025 Accelerate State of DevOps coloca o ponto mais amplo de forma direta: “a IA não conserta um time. Ela amplifica o que já está lá”. Se a sua definição de “pronto” já era frouxa, a IA vai entregar mais trabalho frouxo e mais rápido. O judge aperta essa definição.
Onde o harness aprende
O quarto degrau, o flywheel, é onde esse trabalho se acumula. A maioria dos times nunca chega lá porque trata cada PR rejeitado como um caso isolado. O PR é corrigido, mergeado e esquecido.
O padrão que leva você até o flywheel é mecânico e nada glamouroso. Todo PR rejeitado gera um registro: o que falhou, por quê e qual foi a correção. Toda semana, o time revisa esses registros e faz uma única pergunta. Existe um guide que a gente poderia adicionar e que teria evitado isso? Uma entrada no CLAUDE.md, uma skill, um novo gate, um novo teste. Se sim, adicione. Faça o commit. Agora o próximo PR não consegue falhar da mesma forma.
Rode uma retro semanal de trinta minutos sobre o harness nos projetos em que ele já está maduro o suficiente para sustentar isso. No primeiro mês, parece burocracia. No terceiro, parece os trinta minutos mais alavancados da agenda. O custo de construir o harness é pago pelo próprio harness.
Para fechar
O debate sobre agentic coding está convergindo rápido. O post da Anthropic sobre harness, os guides e sensors de Birgitta Böckeler, as posições de loop de Kief Morris, o gap do SWE-Bench Pro, a conclusão do DORA 2025. O enquadramento está se assentando. O modelo não é o gargalo. O harness é.
On the loop é onde você muda o harness que produziu o artefato. Essa é a frase do texto de Morris à qual eu sempre volto. O engenheiro sênior que era o gargalo no mundo In-the-loop vira a pessoa mais alavancada da empresa no mundo On-the-loop.
A descrição do cargo muda. O output de um ótimo engenheiro sênior não é mais código. É o sistema que faz as próximas cem features saírem corretas consumindo muito menos do tempo dele.
Na Cheesecake Labs, ajudamos organizações de engenharia a sair do “a gente usa Claude Code” para o “a gente construiu o harness que nos permite confiar no Claude Code”. Gates, judges, logs de falha classificados: a infraestrutura sem glamour que transforma agentic coding em um sistema de entrega.
Se os seus engenheiros seniores estão passando a maior parte da semana revisando diffs de agentes na mão, fale com a gente. A correção quase sempre é uma correção de harness, e ela se paga em semanas.
