Verificação, testes e avaliação: construir confiança em escala

7.1. Duas coisas diferentes precisam ser avaliadas

O software produzido precisa atender aos requisitos e preservar propriedades importantes. O processo com agentes precisa resolver tarefas de forma consistente, com custo e intervenção aceitáveis.

Uma execução pode gerar uma mudança correta depois de muitas tentativas e horas de supervisão. Isso valida aquele resultado, mas deixa um problema no processo. Outra execução pode ser rápida e elegante e produzir uma alteração errada. Por isso, testes do software e avaliações do sistema de agentes se complementam.

O guia de evals da Anthropic distingue tarefa, tentativa, trajetória e estado final, e recomenda avaliar o conjunto formado por modelo e harness. Também ressalta a necessidade de múltiplas execuções e de calibrar avaliadores baseados em modelos. F20

7.2. Definir o oráculo de correção

Um oráculo é o critério usado para decidir se o resultado está correto. Pode ser uma regra matemática, um contrato, uma restrição de dados, um comportamento de referência ou uma avaliação humana estruturada.

O engenheiro deve identificar de onde vem esse critério. Se implementação e testes forem derivados da mesma interpretação incompleta, ambos podem concordar e falhar no requisito real. Solicitar uma segunda opinião a outro agente ajuda a explorar, mas a independência mais forte vem de evidências com origens diferentes.

Exemplo: um endpoint de exportação só deve incluir dados do cliente autenticado. Um teste que verifica “retornou um CSV” cobre uma propriedade muito pequena. Um cenário com dois clientes, dados semelhantes e tentativas de cruzar identificadores testa a fronteira de autorização que realmente importa.

Pergunta operacional: qual erro relevante passaria despercebido se esse teste fosse o único sinal de qualidade?

7.3. Escolher a forma de evidência

O quadro abaixo é uma proposta de decisão, a ser adaptada ao risco e ao domínio.

Propriedades e relações metamórficas podem ser particularmente úteis. Em uma transformação sem perdas, transformar e desfazer deve preservar o dado. Em uma busca, acrescentar um filtro conjuntivo ao mesmo conjunto, antes da paginação, não deve aumentar o conjunto de resultados. O valor vem da relação testada e de suas condições de validade.

7.4. A economia dos testes precisa ser reconsiderada

O manifesto observa que a redução do custo de escrever e manter testes pode alterar decisões anteriores sobre cobertura. A aplicação competente é reavaliar o custo total de cada estratégia.

Se gerar testes ficou barato, ainda é necessário pagar sua execução, investigar falhas intermitentes e manter ambientes. A equipe deve ampliar evidência onde isso reduz risco ou trabalho humano, preservando feedback rápido. Pode valer a pena produzir muito mais testes de contrato, casos adversos e jornadas críticas, desde que o resultado continue interpretável.

No experimento de compilador com agentes paralelos, Nicholas Carlini relata que seu trabalho se concentrou no ambiente, nos verificadores e no feedback; referências externas ajudaram a isolar problemas para execução independente. É uma experiência de capacidade, com limitações reconhecidas pelo autor, e ilustra o valor de boas condições de verificação. F22

7.5. A revisão humana muda de distribuição

Há espaço para automatizar verificações de estilo, políticas repetitivas, consistência local e muitas revisões rotineiras. O investimento humano deve migrar para requisitos, fronteiras de confiança, mudanças sem boa evidência e decisões com consequências maiores.

Isso permite estabelecer políticas por classe de alteração. Atualizar documentação ou realizar uma refatoração mecanicamente verificável pode exigir um fluxo diferente de modificar autorização ou remover dados. A aprovação deve corresponder ao risco e à qualidade dos controles disponíveis.

Para reduzir revisão manual de forma sustentável, a equipe precisa saber quais defeitos seus mecanismos detectam, acompanhar falhas que escapam e ter capacidade de recuperação. O objetivo prático é eliminar a necessidade de inspeção repetitiva em classes bem controladas e concentrar julgamento nas exceções.

7.6. Criar uma pequena suíte de avaliação do fluxo com IA

Uma proposta inicial é selecionar tarefas reais representativas: correção localizada, mudança que atravessa módulos, investigação, alteração de interface, migração e caso com requisito ambíguo. Não é necessário começar com um benchmark grande.

Registre para cada tarefa: estado inicial, resultado esperado, critérios de avaliação, versão do código, configuração do agente, tempo, custo e intervenções. Cada tentativa deve começar de um estado conhecido e restaurado, para evitar contaminação por dados, caches ou efeitos de uma execução anterior. Inclua tarefas que falharam anteriormente. Reserve alguns casos para avaliar mudanças sem adaptar o processo diretamente a eles.

Compare configurações em condições suficientemente semelhantes e repita execuções quando a variabilidade puder mudar a decisão. Meça resultado correto, custo, tempo humano, regressões e ações fora do escopo. Uma única demonstração favorável é um ponto de partida para investigação.

O sucesso narrado pelo agente deve ser confirmado no artefato ou estado pertinente: arquivo, testes, banco, aplicação ou implantação. O registro final precisa distinguir verificações executadas, verificações impossíveis e hipóteses ainda abertas.