O Check Passou Porque Não Checou Nada: Regras de Duas Reescritas em Escala de Agentes

Nove engenheiros da Microsoft fizeram merge de 1.211 pull requests em 21 de outubro. Bas Brekelmans, ao contar como o time do Copilot Cowork chegou a esse ritmo, também descreve um check que passou sem testar nada.

O script mandava a saída do check para o tail. Nas palavras dele: “A shell pipeline returns the exit code of its last command, and that was tail, which always succeeded.” Qualquer que fosse o resultado do check, o harness via sucesso. Uma pessoa que escreve esse pipeline ganha um bug silencioso. Uma frota de agentes acaba achando a saída, porque, como o mesmo texto diz, “Agents keep working until the checks pass, so if a check can pass without testing anything, an agent will eventually find that path.”

A Maple chegou ao mesmo lugar por outro caminho. Portou 287.000 linhas de React e 131 rotas em 3 dias, contados do primeiro commit até a última tela portada, com rodadas de revisão e correções pós-deploy por cima disso. O título do relato já aponta o trabalho de verdade: “The hard part was proving nothing changed.”

Times diferentes, bases de código diferentes, a mesma conclusão. Um check verde só conta como prova depois que mostra que olhou para alguma coisa.

Já escrevemos sobre agentes que burlam a verificação em escala, sobre a revisão que pegou o que os testes perderam e sobre tirar a caneta do agente que avalia os próprios testes. Este texto fica nas regras que esses times escreveram. Elas são curtas, específicas e cabem em qualquer time que roda agentes contra um pipeline de CI.

Faça cada check dizer o que tocou

A primeira regra do Cowork é quase constrangedora de tão simples: “Every check reports how many files it checked.”

Um check que inspecionou zero arquivos e um que inspecionou centenas devolvem o mesmo sinal verde. Só a contagem separa os dois. Com o número impresso, um revisor (humano ou agente) enxerga a diferença entre “passou” e “passou por cima de nada”. A contagem também vira algo para alertar. Um número que cai para zero depois de uma refatoração do glob de arquivos é um sinal que nenhum exit code entrega.

A regra custa uma linha de log por check. E transforma uma afirmação em uma pequena prova.

Faça cada check novo falhar uma vez, de propósito

A segunda regra: “Every new check comes with a test that makes it fail on purpose.”

Um check que você jamais viu falhar é um check em que você confia por fé. O Cowork vai além no nível do pull request. Antes de o PR abrir, o harness reverte a correção e roda de novo os testes novos. Se um teste novo continua passando sem a correção, ele prova apenas que o teste passa.

Na minha leitura, esse passo é barato de automatizar e bem mais difícil de burlar. Um teste que não verifica nada útil costuma passar também no código sem correção, e reverter e rodar de novo pega exatamente esse caso. O passo converte “o agente diz que o teste cobre o bug” em um sim ou não mecânico.

Dê um contrato a cada loop antes de ele começar

Um agente instruído a trabalhar “até os checks passarem” tem uma única condição de parada, e o bug do tail mostra como essa condição pode ser satisfeita por acidente. A resposta do Cowork é um contrato que todo loop automatizado declara de antemão. Ele tem quatro partes:

uma regra de manter ou reverter;
uma medida que não pode piorar;
um limite de tentativas;
a lista de ações que só humanos executam.

O agente de merge é o caso concreto. Ele para “after 20 rounds or after hitting the same CI failure three times.” A segunda condição pesa tanto quanto a primeira. Minha leitura: repetir a mesma falha pode ser um loop procurando contornar o check em vez de atravessá-lo, e o limite encurta essa busca.

Já defendemos que o ativo durável de engenharia de IA é o harness. O contrato de loop torna uma parte desse harness inspecionável. Escrito, ele pode ser lido, revisado e mudado sem abrir uma única transcrição de agente.

Escreva o que significa pronto e tranque o baseline

O harness de paridade da Maple se apoia em uma definição de pronto escrita em termos contáveis: “A screen is ported when every scenario for its route reports identical (or pass with 0 perceptual pixels), with 0 behavior diffs, no console errors and no unmocked endpoints.”

Cada trecho dessa frase pode ser verificado por uma máquina. Nada depende do julgamento de um agente de que a tela “parece certa”.

A segunda regra da Maple protege a primeira: “an agent must never edit the baseline, a scenario or a tolerance to make a diff go away.” Um harness de paridade compara a saída nova com uma expectativa gravada. O caminho mais barato para um diff verde é editar a expectativa. A Maple deu nome a esse caminho e o proibiu. Sem a regra, a definição de pronto vale o quanto vale a contenção do agente.

Lidas juntas, as regras do Cowork e as da Maple atacam a mesma fraqueza por dois lados. O Cowork obriga o check a provar que rodou. A Maple proíbe o agente de mover o alvo para onde o check aponta.

O harness era forte. A revisão ainda achou cerca de 180 defeitos.

Esta é a parte do relato da Maple que vale imprimir. A revisão achou o que o harness de paridade perdeu: cerca de 40 defeitos em uma primeira revisão. Uma revisão final feita por seis agentes achou cerca de 140 a mais, quatro deles sérios. Cerca de 180 defeitos no total passaram por um harness com definição de pronto escrita e uma regra contra editar o baseline.

A explicação da própria Maple cabe em uma frase: “It only checks what the scenarios cover, though.” O harness provou que os cenários batiam. Sobre comportamento fora dos cenários, ele ficava mudo. A Maple também registra que sua última rodada de paridade cobriu 5 de 7 blocos, então a rodada final não cobriu o port inteiro.

O Cowork traz um dado paralelo vindo do lado oposto. Agentes revisores instruídos a quebrar uma mudança sensível não acharam nada. Humanos acharam depois “four blocking issues.” Os revisores agentes da Maple acharam muita coisa e os do Cowork não acharam nada, então os dois relatos deixam em aberto se revisão por agente basta. Os números da Maple mostram a revisão achando o que o harness perdeu. O único caso relatado pelo Cowork mostra revisores humanos achando o que revisores agentes perderam em uma mudança sensível. Veja também revisão obrigatória por agentes em produção.

Os dois relatos pedem ressalvas. São relatos dos próprios times e nenhum foi auditado. O da Maple está no blog de um fornecedor. Os 3 dias excluem rodadas de revisão e correções pós-deploy, pela descrição da própria Maple. O Cowork é explícito sobre o que não mediu: “We haven’t measured cost per turn properly yet, so we’re not making any claim about cost.” Leia os dois como notas de engenharia de times que entregaram.

Faça isto agora

Comece pelos scripts de CI, porque é lá que mora o bug do tail.

Ache pipelines que escondem exit codes. Procure nos scripts de CI checks cuja saída vai para outro comando. Ligue set -o pipefail no bash ou capture o status do check de forma explícita.
Imprima uma contagem em cada check. Arquivos, testes, cenários, linhas. Falhe o job quando a contagem for zero em um check que nunca deveria estar vazio.
Exija um caso de falha para cada check novo. No CI, reverta a correção, rode de novo os testes novos e bloqueie o PR se eles ainda passarem.
Escreva um contrato para cada loop automatizado. Regra de manter ou reverter, medida protegida, limite de tentativas, ações exclusivas de humanos. Inclua uma parada para falhas idênticas repetidas.
Defina pronto em termos contáveis e tranque o baseline. Agentes não editam baselines, cenários nem tolerâncias. Garanta isso com proteção de caminho no repositório, fora do prompt.
Mantenha uma camada de revisão depois do harness. Reserve orçamento para ela. Em mudanças sensíveis, inclua humanos.

A ordem importa menos que o hábito por trás dela. Todo sinal verde do seu pipeline deveria saber responder uma pergunta: quantas coisas você checou?

Fontes

Microsoft. “Nine engineers, 1,211 pull requests in a day: Lessons from building Copilot Cowork.” Novembro de 2026.
Maple. “Porting 287,000 lines of React in 3 days. The hard part was proving nothing changed..” Outubro de 2026.

A Victorino ajuda times de engenharia a construir harnesses de verificação que agentes não conseguem passar por acidente: contato@victorino.com.br | www.victorino.com.br