🎯 Aceite que o verificador e o teto
No topico 5 do modulo anterior voce viu o passo verificar do loop descobrir/planejar/agir/verificar/parar. Este modulo inteiro e sobre esse unico passo, porque ele define o que o loop persegue. O loop nao para no que voce queria — ele para no que o verificador aprovou. Se o verificador aceita qualquer coisa, o loop entrega qualquer coisa.
🆕 Novo aqui? Duas palavras antes de seguir
- Verificador: qualquer coisa que checa se um resultado esta bom — pode ser codigo (um teste), pode ser outro modelo de IA, pode ser uma pessoa.
- Teto de qualidade: o melhor resultado possivel que aquele sistema consegue produzir. Nenhum loop supera o criterio que o aprova.
O que olhar: seis tentativas em cima, uma fatia estreita embaixo. Nao importa quantas voltas o loop de agindo — o que sai e definido pela largura do gargalo, nao pela quantidade de tentativas. Um verificador largo (aceita quase tudo) deixa passar lixo; um verificador estreito demais trava o loop pra sempre.
✓ Combinacao que funciona
- ✓Prompt medio + verificador otimo — o loop tateia, mas o gargalo barra o ruim
- ✓Criterio escrito antes de rodar a primeira volta
- ✓Verificador que sabe dizer “nao” com frequencia
✗ Combinacao que falha
- ✗Prompt otimo + verificador fraco — converge pra algo que so parece bom
- ✗Criterio “que fique bom”, decidido na hora
- ✗Verificador que aprova quase tudo que chega
Conceitos-chave
Define o que sai, nao o que entra
Nada supera o verificador
Escreva verificadores, nao prompts
Parece bom ≠ e bom
🪜 Empilhe a escada de verificadores
Nao existe um verificador so. Existe uma escada: compila → lint → teste automatizado → outro modelo julgando → humano. Cada degrau custa mais caro e pega um tipo diferente de erro — compilar pega erro de sintaxe, teste pega erro de logica, humano pega erro de julgamento que nenhuma maquina enxerga.
🆕 Novo aqui? Tres palavras antes de seguir
- Lint: ferramenta que confere estilo e erros comuns de codigo sem rodar o programa — mais rapida que um teste.
- Determinístico: mesmo input, mesmo output, sempre. Um teste automatizado e deterministico.
- LLM-as-judge (modelo julgando): usar um segundo modelo de IA pra avaliar o resultado do primeiro — probabilistico, pode variar entre rodadas.
O que olhar: a subida da esquerda pra direita. Compila e lint sao quase gratis e deterministicos — rode-os toda volta do loop. Modelo julgando e humano custam caro e sao mais lentos; reserve pros casos que ja passaram pelos degraus baratos. Determinístico > probabilistico sempre que existir opcao — so suba a escada quando o degrau de baixo nao consegue detectar o erro que voce procura.
📊 Onde cada degrau pega o erro
- Compila — sintaxe quebrada, import faltando
- Lint — padrao de codigo, variavel nao usada, cheiro de bug
- Teste automatizado — logica errada num caso conhecido
- Modelo julgando — tom, coerencia, aderencia a um estilo
- Humano — julgamento de negocio, contexto que nenhum dos anteriores tem
Conceitos-chave
Nao um verificador, varios
Rode o barato toda volta
So quando o barato passou
Teste > modelo, quando possivel
🚫 Nao deixe ele carimbar o proprio trabalho
Mesmo agente, mesma conversa, escreve e depois “revisa” o proprio trabalho? Ele aprova quase sempre. Nao e preguica nem malicia — e que o raciocinio inteiro que produziu aquele resultado ainda esta ali do lado, na mesma janela de contexto, puxando o julgamento pro “esta bom”. Revisao de verdade exige contexto limpo.
🆕 Novo aqui? Uma palavra antes de seguir
- Contexto limpo: quem julga ve so o resultado final e o criterio de aprovacao — nao o rascunho, nao o raciocinio, nao as tentativas que vieram antes.
O que olhar: a divisoria tracejada no meio. A esquerda, tudo mora na mesma caixa e a seta volta pra ela mesma — nao ha separacao real entre quem produziu e quem julga. A direita, so o resultado e o criterio atravessam a fronteira; o revisor nunca ve o rascunho nem o raciocinio. Essa separacao — contexto limpo, revisor distinto — e exatamente o que um grafo entrega de graca (cada no com seu proprio contexto) e o que um unico loop tem dificuldade de fazer sozinho. A Trilha 3 faz o comparativo completo; aqui fica so o motivo.
⚠️ Atencao: “deixa eu conferir meu proprio trabalho” nao existe de graca
Isso vale pra gente tambem — voce ja releu um texto seu na mesma sentada e nao viu o erro que um colega achou em cinco segundos. Com modelo de IA o efeito e igual ou pior: ele tem acesso literal ao proprio raciocinio, entao a “revisao” vira so uma segunda passada pelo mesmo caminho de pensamento.
Conceitos-chave
Aprova quase sempre
So resultado + criterio
Nao ve o processo
Motivo concreto de existir no separado
📐 Escolha a referencia
Todo verificador compara o resultado com algo. Esse algo e a referencia: um teste que passa, um exemplo aprovado antes, uma regra escrita, um numero alvo. Sem referencia concreta, a verificacao vira opiniao — e opiniao muda de humor entre uma volta e outra do loop.
Referencia concreta: teste que passa
"Essa funcao deve retornar 42 pra esse input." Sim ou nao, sem meio termo.
O loop sabe exatamente quando parar. Nenhuma ambiguidade sobra pro julgamento.
Referencia por exemplo: um caso aprovado antes
"Deve soar como este e-mail que o time ja aprovou." Menos rigido, ainda ancorado em algo real.
Funciona bem quando "certo" e mais sobre estilo do que sobre um numero exato.
Sem referencia: “que fique bom”
Nenhum numero, nenhum exemplo, nenhuma regra — so uma sensacao.
O verificador vira uma moeda: aprova hoje o que reprovaria amanha. O loop converge pra sorte, nao pra qualidade.
💡 Dica pratica
Antes de escrever o verificador, escreva uma frase no formato “o resultado esta certo se ___”. Se voce nao consegue completar a frase com algo que da pra checar (numero, teste, exemplo, regra), voce ainda nao tem verificador — voce tem uma esperanca.
Conceitos-chave
O “algo” com que se compara
A referencia mais rigida
Referencia por estilo
“Que fique bom” nao verifica nada
👁️ Vigie o vigia
O verificador apodrece com o tempo, mesmo sem ninguem mexer nele. Teste para de cobrir o que mudou no codigo. Dado de exemplo envelhece. A definicao de uma metrica muda por baixo, num outro sistema, e ninguem avisou o verificador. A verificacao escorrega de checar a realidade pra so conferir papel com papel — e o painel continua verde o tempo todo.
🎯 O sintoma classico
Painel verde, resultado real ruim.
Se o verificador some da sua atencao depois de escrito — vira “codigo legado que ninguem toca” — ele vai continuar aprovando pelo criterio antigo enquanto o mundo muda ao redor. E o mesmo mecanismo do topico 5 do modulo anterior: metricas viram alvo e o alvo, sem manutencao, para de representar o que interessa de verdade.
⚠️ Atencao: verificador sem dono nao se auto-atualiza
Alguem precisa revisitar o verificador quando o processo mudar — nova regra de negocio, novo formato de dado, novo caso de uso. Trate o verificador como codigo de producao: tem dono, tem changelog, tem revisao periodica. Um verificador esquecido e pior que nenhum verificador, porque ele te da falsa confianca.
✓ Verificador vivo
- ✓Revisado quando o processo real muda
- ✓Reprova de vez em quando (sinal de que ainda esta ativo)
- ✓Tem dono nomeado
✗ Verificador apodrecido
- ✗Escrito uma vez, nunca revisto
- ✗Sempre verde, nunca reprova nada
- ✗Ninguem lembra por que a regra existe
Conceitos-chave
Envelhece mesmo parado
Deixa de checar a realidade
Falsa confianca visual
Alguem revisa periodicamente
✍️ Escreva o verificador antes do prompt
Mesma logica de escrever o teste antes do codigo. Escreva o verificador antes do prompt do agente, e teste-o contra um resultado ruim de proposito. Um verificador que nunca reprova nada nao esta verificando — esta so carimbando. Esse verificador, depois, vira um no do seu grafo — a Trilha 4 mostra como.
✓ Ordem certa
- ✓1. Escreve o verificador
- ✓2. Testa contra um caso ruim conhecido — precisa reprovar
- ✓3. So entao escreve o prompt do agente
✗ Ordem que da errado
- ✗Escreve o prompt primeiro, ve o que sai, verifica “no olho”
- ✗Escreve o verificador so pra confirmar o que ja saiu bom
- ✗Nunca testa o verificador contra um caso ruim
🧪 Exemplo pratico: prompt pronto pro Claude Code
Objetivo: pedir pro Claude Code escrever o verificador ANTES de escrever o prompt do agente que ele vai verificar — e forcar um caso-ruim de teste junto.
Antes de escrever qualquer prompt de agente, escreva o VERIFICADOR para a tarefa <descreva a tarefa, ex: "resumir um artigo em ate 5 bullets">. O verificador deve: 1. Ser um script/funcao deterministica sempre que possivel (nao outro modelo). 2. Definir a referencia por escrito: o que torna o resultado aprovado (ex: "tem no maximo 5 bullets", "cada bullet tem menos de 30 palavras", "nenhum bullet repete a frase de outro"). 3. Retornar aprovado/reprovado + o motivo. Depois, crie um CASO RUIM DE PROPOSITO: um resultado que claramente viola a referencia (ex: 12 bullets, ou bullets repetidos). Rode o verificador contra esse caso ruim. So depois disso, escreva o prompt do agente que vai gerar o resultado de verdade.
Como verificar: rode o verificador contra o caso ruim de proposito. Se ele aprovar o caso ruim, o verificador esta quebrado — volte e reescreva a referencia antes de seguir. So avance pro prompt do agente depois que o verificador reprovar corretamente o caso ruim e aprovar um caso bom conhecido.
Agora troque pelo seu: substitua
<descreva a tarefa> pela sua tarefa real e a lista de criterios pelos
seus criterios de aceitacao. Guarde o caso ruim — ele vira um teste de regressao do verificador pra sempre.
Checagem rapida (nao bloqueia nada): voce testou seu verificador contra um caso ruim de proposito e ele aprovou o caso ruim. O que isso significa?
Conceitos-chave
Antes do prompt do agente
Precisa reprovar de verdade
Nao esta verificando
Ponte pra Trilha 4
📌 Resumo do Modulo
Proximo Modulo:
2.3 — Onde o loop quebra: as falhas estruturais que nenhum verificador bom sozinho resolve.