Três Filas no Harness, Dezoito em Produção. O Agente Estava Certo.

O ambiente local da Checkly roteava retries para três filas, escolhidas apenas pelo tipo de check. Em produção o roteamento depende também de fatores como prioridade e tipo de hospedagem, somando 18 filas possíveis por região. O agente escreveu código correto em relação às três. O componente que ele estava reescrevendo processa aproximadamente 92.000.000 de mensagens por dia, cerca de 40.000.000 delas resultados de check e o restante publicações via WebSocket.

Todo portão que aquele código atravessou foi construído sobre a mesma premissa que o código. O harness definia o que significava correto, o agente satisfez essa definição, e a definição descrevia um sistema que não existia.

A Checkly publicou esse defeito dentro de uma reescrita que, no resto, é um resultado forte. Um serviço em Node.js virou um serviço Go implantável com cerca de 13.000 linhas de código de aplicação. Entrou em produção com zero incidentes, 70% de redução nos pods em execução e menos carga no banco: 60% menos average active sessions (AAS) totais no banco e aproximadamente 15% menos CPU de banco, e liberou cerca de 15 vCPU e 45GB de memória. O consumo de tokens ficou dentro dos limites diários de uma assinatura de US$ 200.

Três times chegando à mesma arquitetura

A Checkly enuncia o princípio sem rodeio. “Se um agente vai escrever o código, algo diferente de um revisor humano precisa definir o que significa correto”, escreve Edvinas Janusevicius, backend engineer da Checkly. A definição de correto sai do julgamento de uma pessoa e vira um artefato que executa.

A Shopify colocou o mesmo movimento dentro de um checkpoint. Cada checkpoint do fluxo Helix precisa “provar seu comportamento com testes, corresponder ao app em execução em uma revisão visual, sobreviver a dois revisores de código adversariais e receber o aceno de um humano”. A Shopify relata que o app Shop foi “de uma prova de conceito a um app nativo totalmente reconstruído e publicado nas lojas em apenas 12 semanas”. A Shopify nomeia a restrição que manda: “Não importa quão bom é o modelo se ele não consegue testar o próprio trabalho rapidamente”. A decisão de 2020 contra o nativo foi revertida, e a razão que eles dão tem o mesmo formato. “Nativo ainda significa construir e manter software em duas plataformas, esse custo não desapareceu. O que mudou é que agentes agora fazem o suficiente do trabalho de implementação, tradução, teste e revisão para que isso não seja mais o fator decisivo que era em 2020.” Em outro trecho, descrevem o app principal como “o nosso maior, com mais de 300 telas”.

O trabalho de Second Brain da Meta, publicado em setembro de 2026, cobre a metade de revisão da mesma arquitetura. O time organizou mais de 200 arquivos em uma taxonomia estrita e cortou em cerca de 80% os tokens consumidos por turno; depois de três sprints de desenvolvimento ao longo de seis semanas, relatou zero regressões entre ciclos de melhoria da base de conhecimento. A unidade de revisão é pequena de propósito: “Toda melhoria é uma edição de texto que um especialista de domínio consegue revisar em 30 segundos”. E o revisor é isolado por construção. “Um agente separado, rodando em um contexto novo sem conhecimento da justificativa da melhoria, recebe apenas os diffs propostos … Como não compartilha contexto com os agentes propositores, ele não consegue herdar os pontos cegos deles.” Esse sistema é distinto da plataforma de debugging DrP que tratamos em codificando a inteligência institucional, e os dois não devem ser lidos como um programa só.

Três organizações, três produtos, uma resposta estrutural: construir a definição de correto antes de o agente escrever, e fazer da revisão algo além de uma pessoa lendo um diff.

O isolamento de contexto tem um limite acima dele

O revisor de contexto novo da Meta resolve um problema real e específico. Um revisor que ouve a justificativa de quem propõe tende a adotá-la. Remova a justificativa, entregue só os diffs, e o veredito passa a vir das regras vigentes em vez da narrativa. Isso é independência de verdade, e é independência em relação ao agente.

Essa independência para no harness. Um revisor que lê apenas o diff não tem contra o que comparar o diff além da descrição codificada do sistema. Se essa descrição diz três filas, um revisor perfeito confirma três filas. Os dois revisores adversariais da Shopify esbarram no mesmo teto pelo mesmo motivo: revisão adversarial interroga se a mudança faz o que o checkpoint afirma, e o checkpoint é justamente o que está errado.

Já argumentamos que o harness é a superfície de controle que vale governar e que a correção durável mora no loop, e não na saída. O defeito da Checkly acrescenta a condição de contorno dos dois. Um harness governa apenas a parte da produção que ele modela com precisão. Onde o modelo diverge, o harness deixa de ser controle e vira amplificador, convertendo um mal-entendido humano em código conforme, em velocidade de máquina.

Este é o inverso da falha que descrevemos em agentes burlando verificação em escala. Lá, o agente encontra o caminho mais barato para driblar o portão e o portão é a vítima. Aqui o agente fez o trabalho com honestidade, o portão disparou corretamente, e o veredito ainda assim não valia nada. Nenhuma pressão adversarial sobre a saída recupera isso, porque a pressão e a saída partilham a premissa. Também chega perto do padrão de deriva silenciosa em operações com agentes: o sistema segue reportando verde enquanto aquilo que ele mede se moveu.

Escrita, e verificada contra o quê

A regra de post-mortem da Checkly cabe em uma frase: “Toda suposição sobre a infraestrutura ao redor precisa ser escrita e verificada, nunca inferida.”

As duas metades trabalham. Escrita primeiro, porque uma suposição que existe apenas como configuração local nunca é lida como suposição. O roteamento para três filas era um fato do ambiente local. Comportava-se como verdade porque nada dentro do loop jamais pediu que ele se identificasse como afirmação.

Verificada depois, e a pergunta difícil é verificada contra o quê. O harness foi construído a partir do entendimento que alguém tinha da produção. Conferir o harness contra esse entendimento confirma a cópia diante do erro original. Verificação que significa alguma coisa precisa alcançar o sistema em execução: os nomes de fila que a região realmente tem, as chaves de roteamento que ela realmente avalia, as variáveis de ambiente que a produção realmente define, os grants que o banco local nunca aplica.

A economia de errar isso mudou com a vazão. Uma pessoa que constrói sobre uma premissa falsa produz uma quantidade limitada de código errado antes que alguém perceba. Um agente trabalha na escala do serviço inteiro, cerca de 13.000 linhas de código de aplicação, e uma premissa enterrada no harness se propaga por tudo isso antes que alguém leia uma linha. O defeito não fica mais provável sob autoria de agente. Ele simplesmente alcança mais longe antes de aparecer, e chega vestindo um conjunto completo de portões verdes.

Faça isto agora

Reserve uma hora com o harness contra o qual seus agentes escrevem e produza uma lista. O item da lista é cada coisa que o harness afirma sobre a produção:

Contagem de filas, tópicos e partições, e cada chave que escolhe entre elas
Variáveis de ambiente que a produção define e o ambiente local não
Papéis e grants de banco que a instância local deixa sem aplicar
Feature flags, e os valores reais delas em produção
Tudo que varia por região, tenant ou camada de hospedagem

Depois verifique cada linha contra o sistema em execução, e não contra o documento que originou o harness. Onde a verificação for impossível hoje, escreva a suposição no repositório com um nome associado, para que o próximo agente herde uma afirmação em vez de um fato.

O alvo da revisão mudou. A pergunta que eu vinha fazendo era se dava para confiar na saída do agente. A pergunta agora é se o harness que julga essa saída descreve o sistema que você de fato opera.

Fontes

Checkly. “Rewriting a Node.js Service in Go With AI Agents.” 2026.
Shopify Engineering. “Native is now the future of mobile at Shopify.” Setembro de 2026.
Meta Engineering. “An Organizational Second Brain: Building an AI That Learns From Experts.” Setembro de 2026.

A Victorino ajuda times de engenharia a auditar o que os harnesses de agentes assumem sobre produção antes que essas suposições cheguem lá: contato@victorino.com.br | www.victorino.com.br