Loops de verificação no Claude Code: tabela do benchmark, checklist de Stop hook e fontes

TL;DR

• A recomendação da Anthropic está certa no essencial: o modelo que recebe um loop de feedback produz trabalho melhor. O problema é quem roda o loop. Em 116 execuções, o /verify embutido retornou PASS 24 de 24 vezes, inclusive numa mudança que quebrava um requisito declarado.
• Um modelo que confere a própria mudança compartilha o próprio ponto cego. O Haiku 4.5 errou o mesmo caso de campo único em 11 de 11 execuções, em todas as configurações com o mesmo modelo, e o /verify dele marcou com um check o caso errado.
• No Opus 5.5, o /verify custou 2,5x ($0.96 contra $0.39) e não mudou nenhum resultado. O Opus sozinho acertou 12 de 12 e rodou a suíte de testes por conta própria em 11 dessas execuções.
• Um skill de projeto é opcional para o modelo: disparou em 10 de 24 execuções, 0 de 6 no Haiku. Um Stop hook disparou em todas as execuções por cerca de 20% a mais no Opus.
• A verificação que funcionou veio de fora do autor: o mesmo /verify rodado pelo Opus disse FAIL 3 de 3 na mudança do Haiku e apontou o bug. Ligado como Stop hook, fez o Haiku corrigir o bug 3 de 3 vezes, a $1.36 por tarefa contra $0.76 do Opus escrevendo sozinho.
• Copie isto: um Stop hook para a parte determinística, um verificador que não seja o autor para o julgamento, e nenhum /verify no Opus para trabalho bem especificado.

O que as medições dizem

A afirmação da Anthropic: "Se o Claude tem esse loop de feedback, ele vai multiplicar por 2-3 a qualidade do resultado final." s4 O blog transforma isso num fluxo de adoção em 5 passos: escolha sua checagem manual mais repetida, teste o /verify embutido, escreva o procedimento em linguagem simples como skill, torne-o determinístico e depois leve-o para o CI. s1 Desde a v2.1.215, "o Claude não roda mais os skills /verify e /code-review por conta própria; invoque-os com /verify ou /code-review quando quiser." s3

Os relatos de campo são sobre verificação declarada mas não executada. A issue #96416 é um veredito de revisão com 19 preocupações, 5 verificadas, e um "accept as-is" emitido mesmo assim. s6 A issue #97039 é uma afirmação "held up" após checagens parciais, apesar de uma checklist carregada. s7 "O build passa" e "pronto para produção" são barras diferentes, e cada falha custa 2-3 rodadas de reprompt. s8

Nosso benchmark avaliou cada "done" com testes de aceitação ocultos que o agente nunca viu. 112 execuções de tarefas + 4 execuções /verify entre modelos = 116 execuções, $66.29 de gasto equivalente em API. Falsos "done": 12 de 112, 11 deles do Haiku no T6 em todas as configurações A a E, 1 do Sonnet no T6 com o skill, onde os próprios testes novos falhavam e o skill nunca disparou. s1

O /verify embutido disse Verdict: PASS em 24 de 24 execuções nos três modelos (23 interpretáveis, 1 pass sem rótulo), inclusive no T6 quebrado do Haiku. No Opus custou $0.96 contra $0.39 sem ele (2,5x) e 125 s contra 75 s; não mudou nenhum resultado. s3

O skill de projeto escrito conforme o fluxo de 5 passos foi invocado em 10 de 24 execuções: Opus 8/12, Sonnet 2/6, Haiku 0/6. O Stop hook disparou em todas, a $0.47 contra $0.39 no Opus (+20%). s19

O ponto cego é um único requisito, T6 req. 4: um só update que dá o mesmo valor único a vários documentos encontrados deve lançar DuplicateKeyError. O Haiku errou em 11 de 11 execuções, em todas as configurações (plain, /verify, skill, hook, testes primeiro). O /verify do Haiku checou "update de um doc para o e-mail de outro" e nunca tentou um update atingindo vários documentos. A regra de testes primeiro não ajudou: 3/3 ainda erram o req. 4, e um também quebrou o req. 3. s1

A mesma mudança do Haiku, com /verify rodado por outro modelo: o Sonnet disse PASS (1/1), o Opus disse FAIL 3/3, cada execução apontando o mesmo caso, um update gravando o mesmo valor em vários documentos, a $0.39 a $0.47 por checagem. Como Stop hook no Haiku (configuração F), o verificador Opus fez o bug ser corrigido em 3 de 3 execuções; as três bateram o limite de 60 turnos ao corrigir, com média de $1.36 por execução de T6 incluindo o verificador, contra $0.76 do Opus escrevendo o T6 sozinho com 0 falsos "done". s19

Medições

Bancada: Claude Code 2.1.283 headless (claude -p), diretório de config isolado, mesmo prompt por tarefa, limite de 60 turnos. Repositório: msiemens/tinydb @ 18d73a1 (Python, 226 testes). Seis pedidos de funcionalidade T1 a T6 com 5 requisitos declarados cada (T5: 6). Testes de aceitação ocultos, um por requisito declarado e nunca mostrados ao agente, pontuam cada execução; a suíte do próprio repositório também roda. Um falso "done" é uma execução que termina afirmando conclusão enquanto um teste oculto ou a suíte do repositório falha.

Configurações: A plain (só o pedido); B /verify (A, depois o /verify embutido como segundo turno); C skill verify (um skill de projeto invocável pelo modelo, escrito conforme o fluxo de 5 passos); D Stop hook (prove-it.py: bloqueia a parada enquanto a suíte está vermelha, e bloqueia a primeira parada pedindo uma linha de evidência por requisito); E testes primeiro (uma regra do CLAUDE.md: um teste falhando por requisito antes de qualquer código); F hook verificador Opus (claude -p /verify --model opus sobre a mudança, bloqueia com veredito diferente de PASS, no máximo 2 rodadas).

Limites: um só repositório (uma biblioteca Python pequena e bem testada), seis pedidos bem especificados, 1 a 3 repetições por célula, execuções headless. Os testes ocultos checam apenas o que o pedido declara.

Faça isto na segunda

• Escreva você mesmo um teste de aceitação por requisito declarado, antes de ler o "done" do modelo. Os testes ocultos do benchmark pegaram o que toda checagem do mesmo modelo deixou passar.
• Adicione um Stop hook que rode sua suíte de testes e retorne uma decisão block enquanto ela estiver vermelha. Ele dispara em todas as execuções; um skill não.
• Faça a primeira parada de uma tarefa custar uma linha de evidência por requisito (o padrão prove-it.py): um comando e sua saída, não uma frase.
• Leve a checagem de julgamento a um modelo que não escreveu a mudança: claude -p /verify --model opus sobre o diff, bloqueando com veredito diferente de PASS, limitado a 2 rodadas.
• No Opus 5.5 com um pedido bem especificado, pare de digitar /verify por hábito. Custou 2,5x e não mudou nada em 12 execuções; reserve-o para uma área sem testes ou para caçar um bug preexistente.
• Se você delega ao Haiku 4.5 para economizar, orce o verificador: $1.36 por tarefa com o hook Opus contra $0.76 do Opus escrevendo sozinho.
• Registre cada nova tentativa de uma correção falha num ledger e pare o loop após uma repetição, para que um hook bloqueante não queime tokens no mesmo patch errado.
• Releia seus requisitos pensando no caso de várias linhas: "um update que atinge vários documentos" é o formato do caso que 11 de 11 execuções do Haiku nunca tentaram.

Para ir além

• O fluxo de 5 passos e a escada de maturidade, da checagem manual ao CI: os degraus de cima (CI e gates de PR) são onde a parte determinística entra quando seu hook funciona localmente. s1
• Semântica do Stop hook: uma decisão block com motivo devolve o turno ao modelo; leia o contrato de código de saída e JSON antes de escrever seu próprio gate. s19
• Groundtruth, um Stop hook que recusa o fim do turno até as checagens passarem: a versão determinística da ideia, pronta para ler como implementação de referência. s5
• regressionledger, o lado do custo: um hook que impede o loop de repetir a mesma correção falha, a peça que faltava ao nosso Stop hook quando as execuções bateram o limite de 60 turnos. s10

Fontes

• Building verification loops in Claude Code with skills, Anthropic blog. Por que ler: o fluxo de 5 passos e a escada em que o skill do benchmark foi construído.
• Building verification loops in Claude Code, official Claude channel. Por que ler: três minutos sobre o que o /verify faz na primeira execução, antes de decidir se o mantém.
• Claude Code CHANGELOG, GitHub. Por que ler: a v2.1.215 é onde o /verify passou a ser só invocado pelo usuário, o que muda a frequência com que roda para você.
• Boris Cherny: give Claude a way to verify its work, X. Por que ler: a afirmação de "2-3x a qualidade", na redação exata.
• Groundtruth, GitHub. Por que ler: um gate de Stop hook funcional para copiar em vez de escrever o seu do zero.
• Issue #96416, GitHub. Por que ler: uma transcrição datada de um veredito de revisão que verificou 5 de 19 preocupações e aceitou mesmo assim.
• Issue #97039, GitHub. Por que ler: a mesma falha dois dias depois com uma checklist carregada, então a checklist não é a solução.
• AI coding agents can verify some of their work now, dev.to. Por que ler: a formulação mais clara da distância entre "o build passa" e "pronto para produção".
• Saguaro, GitHub. Por que ler: o debate entre revisão no loop e no nível do PR, com o contra-argumento nos comentários.
• regressionledger, GitHub. Por que ler: o problema de custo de tentativas que um hook bloqueante cria, e uma forma de limitá-lo.
• SPICE simulation to oscilloscope to verification with Claude Code, personal blog. Por que ler: um loop de verificação cujo oráculo é um instrumento físico.
• Hooks reference, code.claude.com. Por que ler: o contrato da decisão block que seu Stop hook precisa respeitar.

FAQ

O /verify embutido pega bugs?

Não neste benchmark. Retornou PASS em 24 de 24 execuções com Opus 5.5, Sonnet 5 e Haiku 4.5, inclusive numa mudança do Haiku que quebrava um requisito declarado. Seu único achado útil foi um bug upstream preexistente, sem relação com a mudança.

Por que um verificador mais forte ajuda um autor mais fraco?

A checagem do Haiku testou o caso em que ele já tinha pensado. O Opus, com a mesma mudança e o mesmo /verify, tentou um update atingindo vários documentos e disse FAIL 3 de 3. O Sonnet disse PASS. O verificador precisa ver um caso que o autor não viu.

É mais barato verificar o Haiku com o Opus, ou escrever com o Opus?

Escrever com o Opus. O hook verificador Opus sobre o Haiku custou em média $1.36 por execução de T6 e bateu o limite de 60 turnos todas as vezes; o Opus escrevendo o T6 sozinho custou em média $0.76 com 0 falsos "done".