AIDiveEle se avaliou: PASS
O verificador embutido do Claude Code, /verify, retornou PASS numa funcionalidade que estava quebrada. Esse é o resultado de um bench com 116 sessões do Claude Code num repositório real, em que cada "concluído" foi avaliado depois por testes de aceitação que o agent nunca viu.
Boris Cherny, criador do Claude Code, chama a verificação de a coisa mais importante que você pode dar a ele. O check embutido só roda sob demanda desde o Claude Code v2.1.215: você digita /verify, ou ele não roda. Neste bench, ele disse PASS em 24 rodadas de 24, e uma dessas rodadas tinha entregue uma funcionalidade quebrada. O que realmente pegou o bug está descrito abaixo, junto com a configuração que custou duas vezes e meia mais e não mudou nada.
O teste: 116 rodadas, testes que nunca viu
Um falso "concluído" é uma sessão que termina afirmando que o trabalho está pronto enquanto um teste de aceitação oculto, ou a própria suíte do repositório, falha. O bench mede com que frequência isso acontece sob seis configurações de verificação.
A dúvida por trás disso vem do próprio rastreador de issues do Claude Code: a issue #96416, aberta em 2026-09-23, descreve uma revisão que listou 19 preocupações, verificou 5 delas e ainda assim concluiu "accept as is".
| Parâmetro | Valor |
|---|---|
| Repositório | msiemens/tinydb (banco de dados de documentos em Python), commit 18d73a1 |
| Suíte de testes do repositório | 226 testes |
| Pedidos de funcionalidade | 6, cada um declarando 5 requisitos |
| Testes de aceitação ocultos | um por requisito declarado, escritos antes de qualquer rodada, nunca mostrados ao agent |
| Modelos | Opus 5.5, Sonnet 5, Haiku 4.5 |
| Claude Code | 2.1.283, headless (claude -p), limite de 60 turnos |
| Sessões | 112 rodadas de tarefa + 4 rodadas /verify entre modelos = 116 |
| Gasto | US$ 66,29 equivalente em API |
As seis configurações vão do Claude Code puro (só o pedido) até um segundo modelo checando o trabalho no fim:
| Configuração | O que adiciona |
|---|---|
| A simples | nada |
| B /verify | o /verify embutido digitado como um segundo turno |
| C verify-change (skill) | um skill de projeto escrito seguindo o fluxo da Anthropic |
| D Stop hook | um script que bloqueia a parada enquanto a suíte está vermelha e pede evidência de cada requisito |
| E testes primeiro | uma regra em CLAUDE.md: um teste falhando por requisito antes de qualquer código |
| F verificador Opus | um Stop hook que roda /verify com Opus sobre a mudança |
Pedidos claros numa biblioteca bem testada são o caso fácil. Opus 5.5 puro acertou as 12 rodadas dele, e rodou a suíte de testes sozinho em 11 delas.
O /verify embutido: PASS, sempre, 2,5x
/verify é o skill de verificação que acompanha o Claude Code. Ele roda a mudança, lê o diff e escreve um veredito passo a passo. Desde a v2.1.215, ele só é acionado pelo usuário, então no bench ele foi digitado depois de cada tarefa, como um segundo turno.
Ele retornou um veredito PASS em 24 rodadas de 24 entre os três modelos, incluindo a mudança quebrada do Haiku. No Opus 5.5, ele não mudou nenhum resultado e custou 2,5 vezes mais:
| Opus 5.5, por tarefa | Simples | Com /verify |
|---|---|---|
| Custo | US$ 0,39 | US$ 0,96 |
| Tempo de execução | 75 s | 125 s |
| Resultados alterados | 0 de 12 |
Para ser justo, o /verify encontrou um bug real: numa tarefa do Opus, ele apontou um problema de reuso após fechamento que já existia na biblioteca, não causado pela mudança que estava checando. Num trabalho que já estava correto, é uma segunda opinião cara.
Skill ou hook: o que fica de fora
Um skill é um procedimento em markdown que o Claude pode abrir quando julga relevante. O post da Anthropic sobre loops de verificação descreve uma receita de seis passos: escolha o acompanhamento manual que você mais faz, tente primeiro o /verify embutido, escreva o procedimento em linguagem simples, transforme-o num skill e depois invoque-o numa tarefa nova e itere. O skill do bench, verify-change, foi construído exatamente assim e instrui o Claude a provar cada requisito contra o código real antes de dizer que terminou.
Um skill é uma sugestão, e o Claude decide se o abre:
| Modelo | Sessões que abriram o skill |
|---|---|
| Opus 5.5 | 8 de 12 |
| Sonnet 5 | 2 de 6 |
| Haiku 4.5 | 0 de 6 |
| Total | 10 de 24 |
O único falso "concluído" do Sonnet veio de uma sessão em que o skill nunca abriu: ela terminou com dois dos próprios testes novos falhando.
Um Stop hook é um script que o Claude Code roda toda vez que o agent tenta terminar. Ele pode recusar a parada e mandar o agent de volta com um motivo. O hook do bench roda a suíte de testes, bloqueia enquanto ela está vermelha e, na primeira parada, pede uma linha de evidência por requisito. Ele disparou em toda sessão. No Opus, custou 20% a mais, US$ 0,47 contra US$ 0,39 por tarefa (94 s contra 75 s). Neste bench, ele nunca encontrou uma suíte falhando no momento da parada, então não teve nada para pegar: um hook sempre dispara, mas só checa o que você mandou ele checar.
O ponto cego: 11 de 11 perdidos
A tarefa que falhou pedia campos únicos numa tabela: dois usuários não podem compartilhar um e-mail, e qualquer atualização que deixasse dois documentos com o mesmo valor único deve levantar DuplicateKeyError.
O Haiku 4.5 testou mover um usuário para o e-mail de outro usuário, e isso foi recusado corretamente. Ele nunca testou uma única atualização que corresponde a vários documentos e escreve o mesmo e-mail novo em todos eles. Esse caso passou sem erro em 11 sessões do Haiku de 11, em toda configuração com o mesmo modelo: simples, /verify, o skill, o Stop hook e testes primeiro.
O próprio /verify do Haiku marcou o caso que ele tinha tentado e escreveu PASS. O teste oculto reportou DID NOT RAISE DuplicateKeyError. O Sonnet 5, quando pedido para rodar /verify na mesma mudança, também retornou PASS. Opus e Sonnet escreveram essa funcionalidade corretamente por conta própria, então isso é um modelo numa tarefa, mas um check escrito pela mesma mente compartilha o mesmo ponto cego.
A checagem externa: Opus diz FAIL
O mesmo /verify sobre a mesma mudança do Haiku, rodado pelo Opus 5.5, retornou FAIL em 3 rodadas de 3, nomeando o caso perdido a cada vez: uma atualização que corresponde a vários documentos escreve o mesmo valor em todos eles sem erro. A pegada veio de um modelo diferente, não do autor e não do próprio check do autor.
Montado como Stop hook (configuração F), o Opus checa o trabalho do Haiku toda vez que ele tenta terminar. Os resultados:
| T6, por rodada | Haiku + verificador Opus | Opus 5.5 sozinho |
|---|---|---|
| Bug corrigido / falso "concluído" | corrigido em 3 de 3 | 0 falso "concluído" |
| Turnos | limite de 60 turnos atingido em toda rodada | |
| Custo | US$ 1,36 incluindo o verificador | US$ 0,76 |
A checagem externa funciona. Nessa tarefa, custou mais do que o modelo mais forte escrevendo a funcionalidade sozinho.
O que copiar, e quanto custa
Pare de deixar que o modelo que escreveu uma mudança seja o único a checá-la.
| Regra | Por quê | Custo neste bench |
|---|---|---|
| Mantenha um Stop hook para tudo que um script possa checar | ele dispara em toda sessão | cerca de 20% a mais no Opus |
| Faça a checagem real vir de fora do autor: um modelo mais forte no portão, ou seus próprios testes escritos a partir do pedido | o mesmo modelo perdeu o próprio bug 11 vezes de 11 | US$ 1,36 por tarefa para Haiku + verificador Opus |
Num pedido claro com Opus, pule digitar /verify |
0 resultados alterados | 2,5x o custo, 125 s contra 75 s |
Os limites: uma biblioteca pequena, seis pedidos claros, de uma a três rodadas por célula, sessões headless, e testes ocultos que checam só o que cada pedido declara. Num trabalho mais confuso, os números vão mudar.
