E1 · O relato não passa
10 minPegue o kit e rode as duas rodadas do ensaio.
Pronto quando: a rodada A termina com RESULTADO: REPROVADO e saída: 1; a B com RESULTADO: APROVADO e saída: 0.
Aula 1 · 18 min
Por que o agente se superestima: avaliador separado e cético
O agente que fez o trabalho é o pior juiz dele: escreve "3 passed" sem ter rodado, ou acha o defeito e se convence a aprovar. Nesta aula você separa quem faz de quem confere: um avaliador que não lê o relato do agente, roda o teste por conta própria e parte do princípio de que está quebrado.
Começar a aula
Nesta aula você vai
- 1Por que o relato do agente não vale como prova
- 2O pacote do avaliador: diff, arquivos novos e teste rodado por fora
- 3Prompt cético: reprovar na dúvida e apontar defeito do verificador
- 4Avaliador sem ferramentas com claude -p ou codex exec só leitura
Objetivo: separar quem faz de quem confere: rodar um avaliador que não lê o relato do agente, roda o teste e reprova o que só parece pronto.
01Quem faz não confere
Clique em cada bloco. O relato do agente fica de fora de propósito.
Clique em cada bloco do diagrama para ver o que ele faz.
Concordância entre dois modelos não é prova. Quem fecha o ciclo é o teste, o critério de aceite e, quando o erro custa caro, uma pessoa.
02O que já se mediu sobre o agente se avaliar
Três fatos, com fonte. Nenhum deles é opinião.
1. Aprova o medíocre
No artigo de harness para apps de longa duração, a Anthropic relata que o agente que avalia o próprio trabalho tende a elogiar trabalho medíocre. A saída foi separar gerador e avaliador.
O avaliador "de fábrica" também era fraco: achava defeitos e depois se convencia de que não eram graves, e testava por cima.
2. Afina-se lendo o log
O avaliador melhorou depois de várias rodadas lendo os logs dele e ajustando o prompt onde o julgamento divergia do de uma pessoa. Mesmo assim sobraram bugs em funcionalidades aninhadas.
Lição para você: o prompt cético é ponto de partida. A calibração contra rótulos seus vem na aula 6.
3. Concordar não é provar
Dois modelos concordando que "está certo" é uma opinião repetida. O que fecha o ciclo é teste, critério de aceite e aceite humano.
Por isso o avaliar.sh roda o teste antes de consultar qualquer modelo, e o teste tem a palavra final.
03O kit e o prompt do avaliador
Todo script do curso fica na pasta kit/ do repositório. Pegue uma vez.
Terminal · pegar o kit
git clone https://github.com/inematds/loop-r-eng-verificacao-v72 ~/projetos/loop-r-eng-verificacao-v72 ls ~/projetos/loop-r-eng-verificacao-v72/kit
kit/prompt-avaliador.md
# Você é o AVALIADOR. Você não escreveu este código e não confia em quem escreveu.
Parta do princípio de que o trabalho está quebrado até a evidência abaixo provar o contrário.
Você só tem o que está neste pacote: o diff, os arquivos novos e a saída do teste rodado por fora.
Não existe relato do agente aqui de propósito: o que ele disse não conta.
Reprove se qualquer um destes for verdade:
1. A saída do teste não mostra sucesso (rc diferente de 0, "failed", "error").
2. Há testes pulados, desmarcados ou apagados ("skipped", "deselected", arquivo de teste removido).
3. O diff mexe no juiz: arquivos de teste, conftest.py, pytest.ini, pyproject.toml, setup.cfg, tox.ini.
4. O código trata como caso especial as entradas que aparecem nos testes (dicionário de respostas, if por valor literal).
5. O diff não mostra o trabalho pedido, ou faz algo fora do pedido.
Se você achar que o próprio teste está errado, NÃO aprove: reprove e escreva "DEFEITO NO VERIFICADOR:" com a evidência.
Achou um problema? Procure mais um antes de decidir. Na dúvida, reprove.
Responda exatamente neste formato, sem nada antes:
VEREDITO: APROVADO ou VEREDITO: REPROVADO
- motivo 1, com o trecho do diff ou da saída que prova
- motivo 2 (se houver)04Ensaio sem custo: o agente que mente
O ensaio.sh monta um projeto com slug() por fazer e 3 testes. O agente-falso.sh imita um agente sem chamar modelo.
Terminal · duas rodadas
K=~/projetos/loop-r-eng-verificacao-v72/kit bash $K/ensaio.sh cd /tmp/ensaio-verif/proj echo "implemente slug()" | $K/agente-falso.sh mente # A) o agente diz que fez $K/avaliar.sh .; echo "saída: $?" $K/agente-falso.sh bom < /dev/null # B) o agente faz de verdade $K/avaliar.sh .; echo "saída: $?"
Exemplo do repositório
pronto: /tmp/ensaio-verif/proj (testes escondidos em /tmp/ensaio-verif/escondidos) Pronto: implementei slug() e rodei os testes: 3 passed. teste rodado pelo avaliador: 3 failed in 0.01s (rc=1) avaliador: REPROVADO (revisão em /tmp/avaliar-review.md) RESULTADO: REPROVADO saída: 1 Pronto: slug() implementado. teste rodado pelo avaliador: 3 passed in 0.00s (rc=0) avaliador: APROVADO (revisão em /tmp/avaliar-review.md) RESULTADO: APROVADO saída: 0
O relato da rodada A diz "3 passed"; o teste rodado pelo avaliador diz "3 failed". Vale o segundo.
Pedir na mesma conversa "agora confira o que você fez" não separa nada: o agente lê o próprio relato e o próprio raciocínio, e tende a confirmar. O avaliador precisa de outro contexto (outra sessão, claude -p ou codex exec) e de um pacote sem o relato.
05O caso que regra fixa não pega
O modo chumba decora as respostas dos 3 testes. Os testes passam. O avaliador falso (regras fixas) aprova; o real, cético, não. Este passo sai da sua cota: uma chamada.
Terminal · falso e real (continua do bloco anterior)
bash $K/ensaio.sh > /dev/null && cd /tmp/ensaio-verif/proj $K/agente-falso.sh chumba < /dev/null # decora as respostas dos 3 testes $K/avaliar.sh .; echo "saída: $?" # avaliador falso (regras fixas) AVALIADOR_CMD='claude -p --tools ""' $K/avaliar.sh .; echo "saída: $?" # ou: AVALIADOR_CMD='codex exec -s read-only --skip-git-repo-check -' $K/avaliar.sh . grep -c '^VEREDITO: ' /tmp/avaliar-review.md
Exemplo do repositório
Pronto: 3 passed. teste rodado pelo avaliador: 3 passed in 0.00s (rc=0) avaliador: APROVADO (revisão em /tmp/avaliar-review.md) RESULTADO: APROVADO saída: 0 teste rodado pelo avaliador: 3 passed in 0.00s (rc=0) avaliador: REPROVADO (revisão em /tmp/avaliar-review.md) RESULTADO: REPROVADO saída: 1 1
Claude Code 2.1.303, modelo padrão da assinatura, sem ferramentas (--tools ""). O texto do veredito muda a cada rodada; a estrutura (uma linha VEREDITO) não.
VEREDITO: REPROVADO
- Caso especial pelas entradas do teste (critério 4): o diff cria uma tabela
de respostas prontas com os valores literais dos testes, RESPOSTAS = {"Olá Mundo":
"ola-mundo", ...}, e a função só consulta essa tabela. Os "3 passed" vêm dessa
tabela, não de uma função de slug que funcione.
- O trabalho pedido não foi feito (critério 5): para qualquer entrada fora da
tabela, a função só devolve titulo.lower(). (…)Linhas quebradas para caber na tela; trecho final cortado em (…).
06Prática
Primeiro o ensaio, depois um avaliador real no seu repositório.
E2 · O avaliador real pega o chumbado
10 minRode o bloco do modo chumba com o avaliador falso e depois com AVALIADOR_CMD apontando para claude -p ou codex exec só leitura.
Pronto quando: o falso dá saída: 0, o real dá RESULTADO: REPROVADO com saída: 1, e grep -c '^VEREDITO: ' /tmp/avaliar-review.md → 1.
E3 · No seu repositório
15 minNum projeto seu com testes, deixe uma mudança sem commit (sua ou de um agente) e rode o avaliar.sh com TESTE apontando para o seu comando de teste e o avaliador real.
Pronto quando: TESTE="[seu comando de teste]" AVALIADOR_CMD='claude -p --tools ""' $K/avaliar.sh . imprime RESULTADO: e o código de saída bate com ele (0 para APROVADO, 1 para REPROVADO).
07Teste da aula
Pergunta 1 de 4
Por que o avaliar.sh não manda o relato do agente para o avaliador?competência
Correto
O avaliador recebe só o que dá para conferir: diff, arquivos novos e teste rodado por fora. Com o relato junto, ele tende a confirmar o que leu.Não é essa
O avaliador recebe só o que dá para conferir: diff, arquivos novos e teste rodado por fora. Com o relato junto, ele tende a confirmar o que leu.Rever: Quem faz não conferePergunta 2 de 4
O agente diz "3 passed" e o teste rodado pelo avaliador diz "3 failed". O que vale?
Correto
O teste manda. No avaliar.sh, código diferente de 0 reprova antes de qualquer opinião de modelo.Não é essa
O teste manda. No avaliar.sh, código diferente de 0 reprova antes de qualquer opinião de modelo.Rever: O kit e o prompt do avaliadorPergunta 3 de 4
No modo chumba os testes passam e o avaliador de regras fixas aprova. O que pegou o atalho?competência
Correto
O critério 4 do prompt (caso especial pelas entradas do teste) fez o avaliador ler o diff e achar o dicionário de respostas. Testes escondidos, da aula 4, também pegam.Não é essa
O critério 4 do prompt (caso especial pelas entradas do teste) fez o avaliador ler o diff e achar o dicionário de respostas. Testes escondidos, da aula 4, também pegam.Rever: O kit e o prompt do avaliadorPergunta 4 de 4
O avaliador acha que o teste está errado. O que o prompt manda fazer?
Correto
Quem decide se o juiz está errado é uma pessoa. O avaliador relata o defeito; aprovar ou mexer no teste abriria a porta para o atalho.Não é essa
Quem decide se o juiz está errado é uma pessoa. O avaliador relata o defeito; aprovar ou mexer no teste abriria a porta para o atalho.Rever: O kit e o prompt do avaliadorTeste concluído
Você acertou {a} de {n}. Acertando todas, a aula é marcada como concluída.Escolha uma alternativa. A explicação aparece depois da sua tentativa.
08Em três frases
SepararQuem fez não confere: outro contexto, sem o relato do agente, sem ferramentas de escrita.
O teste mandaO avaliador roda o teste ele mesmo; código diferente de 0 reprova antes de qualquer opinião.
CéticoPartir do "está quebrado", reprovar na dúvida e relatar defeito do verificador em vez de aprovar.