A ferramenta que nos deu rédeas não tinha rédeas em si mesma — a fronteira entre arnês e Reins

Image: AI generated

Em 31 de março de 2026, a Anthropic publicou acidentalmente source maps junto ao pacote npm do Claude Code (v2.1.88). A causa foi a ausência de uma única linha no .npmignore.¹ Os 59,8 MB de source maps expuseram cerca de 512 mil linhas de TypeScript não ofuscado, em aproximadamente 1.900 arquivos. A Anthropic declarou que não se tratava de uma violação de segurança, mas de um erro de empacotamento na implantação — um erro humano —, e recomendou aos usuários que fixassem a versão v2.1.87.

Quando as pessoas examinaram o código exposto, encontraram uma única função com 3.167 linhas no arquivo print.ts.²

O agente de código mais vendido do mundo, aquela ferramenta que nos promete colocar rédeas no código — não havia colocado rédeas em si mesma.

Não trago esta ironia para ridicularizar. Muito pelo contrário. Este episódio é a resposta mais nítida a uma pergunta que eu vinha tentando responder com clareza há algum tempo.

“Reins Engineering é, no fundo, harness engineering?”

É uma boa pergunta. E uma pergunta afiada. As duas coisas se parecem. Ambas são externas ao modelo. Ambas são estruturas não-modelo construídas em código. Ambas impedem o agente de fazer algo indesejado. Então a suspeita — “as rédeas são apenas uma parte do arnês” — é legítima.

Por um tempo, não consegui responder a essa pergunta com clareza. Depois de encontrar a resposta, percebi que ela descreve com mais precisão o que Reins é. E o vazamento acima prova isso empiricamente.

Primeiro: os dois não se opõem

Pense num conjunto de arreios. A sela colocada nas costas do cavalo, a cabeçada, e os dois fios que correm da cabeçada até as mãos do cavaleiro — as rédeas.

As rédeas estão presas na cabeçada. Não estão fora dos arreios — são peças montadas nos arreios. Por isso, se a pergunta for “arnês e Reins são claramente distintos, opostos?”, a resposta é não. Os dois são partes de um mesmo equipamento.

É preciso começar por aí. O slogan comum — “arnês é a cerca, rédeas são o controle” — os coloca em oposição. Mas ao opô-los, perde-se o argumento. “Gates de verificação também fazem parte do arnês” — essa objeção derruba tudo. E ela está certa. CI, checagem de tipos, suíte de testes são todos scaffolding externo ao modelo, e isso é exatamente o que o arnês inclui.

Por isso a pergunta precisa mudar. Não se eles se opõem, mas onde eles se separam.

Onde as rédeas se tornam possíveis — três camadas de loop

Antes de encontrar o ponto de separação, é preciso entender onde as rédeas se tornam possíveis. Vista em camadas de loop, são três.

① Loop de chat       LLM → pessoa → LLM              Tudo probabilístico. Rédeas impossíveis.
② Loop agêntico      LLM → execução → observação → LLM    Execução toca terreno determinístico → rédeas possíveis.
③ Loop Reins         ② + verificadores projetados + catraca       Rédeas completas.

No loop de chat, não há onde colocar a cabeçada. Nem sequer se monta no cavalo. Enquanto o LLM responde, a pessoa lê, e devolve ao LLM, nenhum passo é determinístico. Não há ferro para enganchar o bocado.

O loop agêntico coloca a sela. No momento em que a execução entra — o compilador roda, os testes falham, arquivos são escritos —, o loop pisa pela primeira vez em terreno determinístico. Finalmente há algo para segurar.

É exatamente por isso que o Claude Code teve um sucesso avassalador. Ao incorporar gates determinísticos — Bash, I/O de arquivos, execução de testes — dentro do loop (em parte por acidente), ele já possuía “rédeas parciais”. Algo que não existia na era do chat.

Isso não é apenas minha afirmação. O HAL (Holistic Agent Leaderboard) de Princeton demonstrou, em mais de 21 mil execuções de agentes, que a precisão oscila em dezenas de pontos percentuais simplesmente trocando o scaffold com o mesmo modelo.³ O modelo é fixo; o que mudou é a estrutura ao redor dele. Addy Osmani resume em uma linha: “modelo razoável + arnês excelente > modelo excelente + arnês ruim.” Ele também observou que o mesmo Opus marca pontuações maiores em arnês customizado do que dentro do Claude Code.⁴

Até aqui, é o território que o setor chama de “harness engineering”. Uma descoberta correta. E é exatamente onde se confunde com Reins — afinal, os dois produzem resultados de fora do modelo.

Mas o ② é apenas a metade acidental de Reins. Reins Engineering é o trabalho de completar intencionalmente essa metade. Transformar o gate que entrou por acidente em verificadores projetados, catraca e separação decisão/implementação — elevando o ② ao ③. O discurso do arnês prova Reins, mas não o substitui.

Três eixos

Dois profissionais trabalham com o mesmo cavalo.

Um faz os arreios. As medidas da sela, a resistência da cabeçada, a forma do bocado. Isso serve igualmente para qualquer cavalo, qualquer jornada. Uma vez bem feito, os mesmos arreios servem tanto para ir a São Paulo quanto ao Rio de Janeiro. Quem os faz é o artesão — não quem vai montar.

O outro segura as rédeas. Ele conhece esta jornada. Sabe em qual bifurcação virar à esquerda, onde fica o destino, quando pode dizer “chegamos”. O fio que ele segura está preso nos mesmos arreios, mas o sinal que ele envia muda a cada jornada. Quem envia o sinal não é o artesão — é o cavaleiro.

Aqui estão os três eixos.

• Função. O arnês bloqueia — limites que impedem. Reins guia — para onde ir e quando terminar.
• Ciclo de vida. O arnês é feito uma vez e reutilizado em todas as tarefas. Reins é projetado de novo a cada tarefa.
• Propriedade. O arnês é entregue pelo fornecedor. Reins é escrito pelo arquiteto.

O loop do Claude Code é o mesmo para qualquer projeto meu. Isso é arnês. A Anthropic o fabricou e entregou; é igual para todos os usuários. Mas “rescisão de locação = fotos em cinco locais designados” — essa definição de conclusão foi escrita por mim, para este domínio. Nenhum arnês a contém. Isso é Reins.

A dependência flui em uma direção

Se os dois fossem a mesma coisa, não seria possível separar um do outro. Vamos tentar.

Arnês sem Reins. O agente roda. Roda sem parar. Mas vaga. Perambula por um campo sem marcador de objetivo, sem julgamento de conclusão, e para quando acha que “isso deve bastar”. Já conhecemos isso. Chamamos de vibe coding.

Reins sem arnês. Isso nem sequer é possível. Você segura as rédeas, mas não há cabeçada para prender. Não há onde enviar o sinal. É apenas segurar um fio no ar.

A dependência é unidirecional. Reins precisa do arnês, mas o arnês não precisa de Reins. O arnês funciona sem Reins — funciona mal, mas funciona. Essa assimetria refuta com precisão a ideia de que “os dois são a mesma coisa”. Se fossem a mesma coisa, ao separar um, os dois deveriam cair. Mas o arnês corre sozinho.

A interseção é de exatamente um compartimento

Então realmente não há sobreposição? Há. Exatamente um compartimento.

Gates de verificação em execução. CI rodando dentro do loop agêntico. Essa superfície de execução pertence aos dois lados — é parte do arnês e também aquilo que Reins aciona. É aqui que a pergunta “isso não é arnês?” nasce. Sim, nesse único compartimento os dois apontam para a mesma coisa.

Mas fora dali, separam-se.

   Só arnês               Interseção              Só Reins
─────────────────  ─────────────────  ─────────────────
 Sandbox·permissões   Gates de verificação   Definição de conclusão
 Fiação de ferramentas  (checks em execução)  Design anti-cheese
 Gestão de contexto                           Análise proxy↔objetivo
 (bloqueio sem direção)  (superfície de exec.) (intenção sem substrato)

O arnês tem bloqueio sem direção separado — o sandbox não diz para onde ir, apenas impede a saída. Reins tem intenção sem substrato de execução separado — a definição de “o que é conclusão” existe antes mesmo do gate que a executará. Nenhum dos lados consegue conter o outro inteiramente. Os dois se cruzam. Não se incluem.

Por que a pergunta “subconjunto?” está errada

“Então Reins é um subconjunto do arnês?”

Para ser subconjunto, os dois precisam ser medidos pela mesma régua. Mas o arnês é definido pelo eixo quem entrega e quanto se reutiliza (eixo do substrato), e Reins é definido pelo eixo o que faz à trajetória (eixo funcional). Os eixos são diferentes.

É como perguntar “vermelho é subconjunto do pesado?”. Existe algo vermelho e pesado (= um gate em execução), mas a cor não pode ser contida no peso. Porque as réguas são diferentes. A relação de subconjunto em si é um erro de categoria aqui.

A relação precisa é esta. Reins pressupõe o arnês, mas não está contido nele. Uma camada que se apoia em cima não é uma parte contida dentro. O que está apoiado se estende além do substrato.

Onde realmente se separam — o cheese

Até aqui, é uma história de estrutura. Mas o lugar onde Reins se separa decisivamente do discurso do arnês é outro. É o cheese.

Os designers de jogos sabem. “Mate 10 ratos” é uma quest infame. Há uma lacuna entre o que o gate verifica (10 ratos mortos) e o que o designer realmente queria (o jogador experenciar o conteúdo), e o jogador explora essa lacuna. Isso se chama cheese. É exatamente o mesmo fenômeno que a pesquisa em segurança de IA chama de “specification gaming” — um agente de corrida de barcos que fica circulando em volta de itens de pontuação em vez de cruzar a linha de chegada, e um agente de Tetris que pausa o jogo indefinidamente para não perder.⁵

Meu gate de locação também é cheeseable. Cinco fotos verificam “as fotos existem”, não “a rescisão foi concluída adequadamente”. E se o responsável fotografar apenas paredes limpas? O gate é aprovado. No momento em que a medição vira objetivo, a medição se degrada — é a Lei de Goodhart.⁶

Aqui está o ponto central. O arnês só consegue responder “passou?” Se os testes estão verdes, se os tipos batem, se o schema não quebrou — até aí. Mas “essa aprovação captura o objetivo?” é algo que o arnês jamais conseguirá responder. Porque o que é cheese só pode ser definido por quem conhece o objetivo do domínio. Por que fotografar apenas paredes limpas é uma fraude, por que as regras foram todas aprovadas mas o objetivo foi alcançado em apenas 90% — isso só é sabido por quem conhece o propósito desta tarefa.

Essa pessoa é o cavaleiro. Aquele que segura as rédeas.

Projetar gates à prova de cheese — antecipar os pontos onde o proxy não consegue acompanhar o objetivo — é fundamentalmente diferente para cada tarefa, carrega conhecimento de domínio, e é escrito pelo operador. O arnês task-agnostic não pode entregar isso. Não é que não consiga — é que, sem conhecer o domínio, sequer pode tratar disso.

Aqui está o território exclusivo de Reins Engineering que o discurso de harness engineering e agentic engineering não possui. Eles falam sobre como fazer um arnês melhor. Reins fala sobre para qual porta enviar esta jornada, sem que ela se quebre.

Então, voltando ao vazamento

Agora voltemos à ironia do início. Agora fica claro por que aquele episódio é evidência, não ridicularização.

O cavalo era genial. Opus é força probabilística em estado puro. A sela também funcionava — Claude Code é o melhor arnês do mundo, e os números do HAL provam isso. Mas o código que esse arnês produziu driftou exatamente no modo de falha previsto. Uma função com 3.167 linhas. A manifestação em código da parede dos 200 endpoints. O próprio vazamento também — ausência de uma linha no .npmignore — significa que não havia gate nos artefatos de implantação.

A empresa que fabrica o melhor arnês do mundo não colocou esse arnês no próprio estábulo.

Isso não é antítese — é evidência decisiva da tese. Reins não é uma propriedade que o modelo ou o agente possui — é uma disciplina que se aplica. Que o agente seja inteligente e que o código produzido por ele esteja sob Reins são duas coisas completamente separadas. Um modelo maior não é a resposta. Um arnês melhor também não é a resposta. Segurar as rédeas, definir diretamente o que é conclusão desta jornada, projetar gates que previnam cheese — essa disciplina é a resposta.

Portanto

O arnês faz o cavalo correr. Reins decide para qual porta enviar o cavalo. O arnês é colocado uma vez; Reins é segurado a cada momento. O arnês é entregado pelo artesão; Reins está nas mãos do cavaleiro.

Os dois não se opõem. São peças diferentes do mesmo conjunto. Mas são peças diferentes. Sem o arnês, Reins não existe; sem Reins, o arnês vaga. E saber se este trabalho terminou direito — isso é sempre a mão que segura as rédeas.

Da próxima vez que alguém perguntar “isso é só arnês?”, responda assim:

“Arnês é o que o fornecedor entrega. Reins é o que eu projeto para esta quest. Sem arnês, Reins não existe — mas arnês sem Reins apenas vaga. Até a ferramenta que nos deu rédeas não tinha rédeas no próprio código — porque rédeas não são algo que se tem, são algo que se aplica.”

Artigos relacionados

• IA com rédeas: Reins Engineering — a origem do reframe gate=rédeas
• Quem define “conclusão”? — gates à prova de cheese, tasking como design de quest
• Por que agentes de código funcionam e por que quebram — “geração pode ser probabilística, mas verificação deve ser determinística”
• Por que seu agente nunca para — sistema que pode parar = sistema com conclusão definida
• yongol: a parede dos 200 endpoints — spec escrita pelo operador = a materialização de Reins

Leitura complementar

Textos externos que aprofundam — ou abordam de outro ângulo — as fronteiras deste artigo: arnês e Reins, como parar, specs que são cheesed.

• How Coding Agents Work — Simon Willison — “agentes de código são um arnês ao redor de um LLM.” A definição definitiva de arnês; leitura recomendada antes de mergulhar no artigo.
• Agent Harness Engineering — Addy Osmani — formaliza arnês como uma disciplina de engenharia. Usa ‘sprint contract’ para tratar condições de término — é onde mais se sobrepõe ao argumento deste texto.
• Reward Hacking in Reinforcement Learning — Lilian Weng — a espinha teórica da Lei de Goodhart e do specification gaming. Fundamenta, sob a perspectiva de RL/RLHF, por que cheese acontece.
• Water Finds a Crack — Soren Johnson — “dado a oportunidade, o jogador vai otimizar a diversão para fora do jogo.” Um clássico do game design que mostra o arquétipo humano do reward hacking.
• Effective Harnesses for Long-Running Agents — Anthropic — o próprio fabricante aborda a falha de “declarar conclusão sem ter terminado”. Verificação determinística e condições de término em um único artigo.