Agentes de código para executivos · Capítulo 8 de 24 · 20 min
Vetar proposta que não nomeia o verificador
O verificador executa a entrega e observa o efeito, e quatro linhas da proposta mostram se ele existe de verdade.
Este capítulo faz parte do curso gratuito Agentes de código para executivos. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
A proposta tem quatorze páginas. Onze descrevem o que o agente vai fazer, duas trazem o cronograma e uma traz o gráfico. Em nenhuma delas está escrito quem confere o resultado do agente, nem o que essa conferência executa. O pedido de orçamento existe, o responsável pela entrega existe, e o mecanismo que separa entrega boa de entrega ruim não aparece em lugar nenhum. Aprovar assim significa pagar por um resultado cuja definição vai ser escrita depois, por quem tem receita atrelada a ela.
Você decide aqui se veta ou não uma proposta de melhoria de agente que não declare, por escrito, quem é o verificador e o que exatamente ele executa. Por que isso toca receita e risco: sem esse mecanismo declarado, quem define o que conta como entrega boa é quem recebe pela entrega. O conflito não aparece na assinatura, aparece na primeira divergência de leitura, quando já existe fatura emitida. A decisão que cabe a você: exigir a declaração antes do primeiro pagamento. O que dá para delegar: escolher as camadas de verificação e operá-las. O que não dá: aceitar que quem entrega seja também quem julga a entrega.
A auditoria independente e a autoavaliação
Chegam duas peças sobre o mesmo trimestre. Uma é a autoavaliação da área, escrita por quem tocou o trabalho. A outra é o parecer de quem abriu os registros, refez as contas e assinou embaixo. Nenhum conselho do mundo trata as duas com o mesmo peso, e ninguém precisa explicar por quê. A diferença não está na competência de quem escreveu, está em quem tinha interesse no resultado.
Onde a analogia para de valer: o auditor humano entende o espírito da norma e reporta o que a norma não previu. O verificador cobre só o que foi escrito, e o silêncio dele nunca é aprovação.
Verificador
Verificador é o mecanismo que executa o trabalho entregue e observa se funcionou, sem opinar. Em software, o exemplo mais comum é a suíte de testes, que é o conjunto de verificações automáticas que roda a cada alteração e reprova o que quebrou, entre os problemas que ela sabe procurar.
Pense numa linha de montagem de carros. Ninguém defende a fábrica pela habilidade de estampar uma porta, porque isso qualquer concorrente faz barato. A vantagem está na linha de inspeção: bancada de teste, torque medido, freio acionado antes de o carro sair do galpão. Gerar código virou estampar a porta, e virou barato pela mesma razão. O verificador é a linha de inspeção, e é ela que decide quem entrega peça segura em escala.
Na forma mais crua, o verificador abre ou fecha uma porta: passou ou não passou. Essa forma tem um defeito conhecido. Uma entrega que quase resolve e uma entrega que nem roda não podem receber a mesma nota, e a porta única dá a mesma nota para as duas.
O agente nunca é a fonte da verdade sobre si mesmo.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Por isso um verificador sério é uma escada de camadas, e a porta única fica para trás. A escada é uma decisão de dinheiro antes de ser uma decisão técnica. Cada degrau custa mais que o anterior e enxerga mais que o anterior. A ordem importa: toda entrega reprovada na camada de baixo, que é quase gratuita, deixa de consumir a camada de cima, que é cara. Quando alguém propõe começar pela camada mais cara porque ela é a mais completa, o que está sendo proposto é pagar o preço máximo para descobrir erro de sintaxe.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
O que cada camada prova quando passa, e o que ela nunca vê
| Camada de verificação | O que ela prova quando passa | O que ela nunca vê | Custo relativo |
|---|---|---|---|
| Compila e segue o padrão da casa | O que foi entregue é código válido e está formatado como o resto do repositório | Se o programa faz o que o pedido descrevia | Quase zero |
| Contratos e tipos conferem | As peças se encaixam e as chamadas respeitam o formato combinado entre elas | Se a regra de negócio dentro da peça está correta | Baixo |
| Os testes escritos rodam e passam | O comportamento descrito nos testes acontece de verdade, na execução | Todo comportamento que ninguém escreveu como teste | Médio |
| Roda sob carga, perto de produção | O sistema aguenta uso real, com dado real e concorrência real | Quanto vai custar manter aquilo daqui a um ano | Alto |
A quarta coluna é a que decide a ordem de compra. A terceira é a que precisa ter dono com nome próprio, porque nenhuma camada cobre o que está nela.
Fonte: Elaboração própria a partir da arquitetura de verificação em camadas usada no material técnico deste curso.
Existe evidência recente de que reforçar essa escada muda o resultado de forma material. Num estudo de junho de 2026, ao acrescentar verificação mais forte ao longo da execução, a taxa de resolução limpa subiu de 40,22% para 60,53% em três variantes do mesmo conjunto de tarefas. O mesmo trabalho traz o alerta que interessa ao contrato: todo verificador é uma aproximação da intenção humana, e conforme a capacidade do agente cresce, a distância entre a aproximação e a intenção aumenta. Nenhuma régua fixa continua eficaz para sempre, o que significa que a revisão da régua precisa ter data no contrato, e não boa vontade.
O fornecedor propõe um ciclo de melhoria do agente por seis meses. A proposta traz um gráfico de evolução e uma cláusula dizendo que a qualidade das entregas será avaliada continuamente. Na reunião, o gerente de contas explica que a avaliação fica com o time deles, que já conhece o padrão da sua casa.
O que você faz com a proposta nesta semana?
O verificador cobre o que foi escrito e fica em silêncio sobre o resto. Esse silêncio é ausência de informação, e tratar ausência de informação como aprovação é o erro mais caro desta parte do curso. Bateria verde prova que nenhum dos problemas procurados apareceu. Ela não prova que o sistema é seguro, barato de manter ou correto onde ninguém escreveu teste. O mercado já sabe disso: apenas 5% das empresas declaram confiar plenamente na avaliação automatizada de agentes, e a limitação mais citada, por 29% delas, é que a avaliação não se alinha com o resultado no mundo real.
Verificação rápida
Uma proposta de melhoria de agente chega com a seguinte frase: a evolução será acompanhada por um segundo modelo de IA, que dará nota de 1 a 5 para cada entrega do agente, e a média mensal dessas notas vai ao relatório. Qual é a sua decisão?
As quatro linhas que uma proposta responde antes de passar
O mecanismo, por escrito
0/2A evidência, antes do pagamento
0/2Três perguntas para testar a decisão antes da próxima reunião: (1) A proposta que chegou à sua mesa promete melhoria contínua e não diz o que o verificador executa. Você veta, devolve ou aprova com condição, e qual é a condição escrita? (2) O time apresenta uma bateria de testes toda verde como prova de que a entrega está pronta. O que você ainda pergunta antes de liberar, e por quê? (3) A área que escreve o código se oferece para manter também o verificador, alegando que ninguém conhece melhor o sistema. Você aceita, aceita com salvaguarda ou recusa, e quem passa a manter?
Guia prático: tirar as avaliações do OpenAI Evals antes do desligamento. Se o seu verificador mora no painel do Evals, ele tem data para sumir. A OpenAI avisou em 03/06/2026 que as avaliações existentes ficam só para leitura em 31/10/2026 e que o painel e a API saem do ar em 30/11/2026. O Cookbook da empresa publicou o caminho de migração para o Promptfoo, ferramenta de código aberto que roda no seu repositório.
Migrar um verificador do Evals para o repositório da empresa
Cinco passos. Faça até 31/10/2026, enquanto a avaliação ainda aceita edição e nova rodada.
Passo 1: Liste cada avaliação ativa com dono, conjunto de dados e grader
Anote o tipo de cada grader: string_check, text_similarity, score_model, python ou multi.
Deu certo quando: Inventário com uma linha por avaliação e o nome de quem responde por ela.
Erro comum: Descobrir em dezembro que o juiz da copy só existia no painel.
Passo 2: Exporte os dados e a última rodada de resultados
Os resultados antigos são a linha de base que a avaliação migrada precisa reproduzir.
Deu certo quando: Arquivos de dados e de resultados guardados no repositório, com data.
Erro comum: Migrar só a configuração e perder a linha de base.
Passo 3: Traduza cada grader para uma asserção do Promptfoo
Regra exata vira asserção de igualdade ou JavaScript; nota de modelo vira llm-rubric com o mesmo texto de rubrica.
Deu certo quando: Uma asserção por grader, com o mesmo limiar de aprovação.
Erro comum: Reescrever a rubrica durante a migração, o que muda a medida e o resultado ao mesmo tempo.
Passo 4: Valide, rode e compare com a linha de base
Os comandos do Cookbook são validate config, eval com --no-cache e view.
Deu certo quando: Taxa de aprovação próxima da última rodada no Evals, com as diferenças explicadas.
Erro comum: Aceitar diferença grande sem investigar se o juiz mudou de modelo.
Passo 5: Separe a escrita do verificador da escrita do código
O arquivo de configuração fica numa pasta que só o dono do verificador altera, com revisão obrigatória.
Deu certo quando: Regra de proteção no repositório exigindo aprovação do dono para mudar a pasta.
Erro comum: O mesmo agente que escreve o código editar o verificador que o julga.
No fim você tem: O verificador sai do painel de um fornecedor e passa a viver no repositório, com dono, histórico e linha de base.

Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Devolva hoje qualquer proposta aberta que não declare o verificador nas quatro linhas desta aula. Anexe a lista de verificação ao modelo de proposta da área de compras. No próximo trimestre, conte quantas propostas chegaram completas na primeira tentativa; a meta é a maioria.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Explore os conceitos e compare abordagens em outros cursos. As conexões indicam assuntos relacionados; a sequência de estudo continua no índice do curso.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Do Agile ao Agentic Operating ModelO que exigir antes de aprovar uma entrega feita por agenteExaminar conexões de O que exigir antes de aprovar uma entrega feita por agente
- Prompt Engineering para ExecutivosAvaliar a IA com uma planilha de 20 a 50 tarefasExaminar conexões de Avaliar a IA com uma planilha de 20 a 50 tarefas
- Software e IA para executivosPagar pela camada de teste que pega o defeito certoExaminar conexões de Pagar pela camada de teste que pega o defeito certo
Voltar ao capítulo anterior: Exigir prova executada no lugar de nota dada
Capítulos vizinhos em Agentes de código para executivos
- 06Separar treino por consequência de instrução bem escrita
- 07Exigir prova executada no lugar de nota dada
- 08Vetar proposta que não nomeia o verificador
- 09Transformar promessa de melhoria em cláusula de contrato
- 10Recusar as métricas que o agente aprende a burlar