O que exigir antes de aprovar uma entrega feita por agente

O Mapa de Provas mostrou o que a entrega precisa responder; falta a regra que diz quando ela pode ser aprovada. A definição de pronto (lista que diz quando a tarefa acabou, como a vistoria de saída da oficina) continua necessária: critérios de aceite, código integrado, documentação. Em ambiente com agentes (programas que trabalham sozinhos, como um terceirizado sem supervisor) ela deixa de bastar, porque foi desenhada para um mundo em que o autor do código era um humano cujo julgamento o time conhecia e cuja reputação estava em jogo. Com um autor probabilístico sem nenhuma das duas coisas, o pronto declarado precisa ser promovido a verificado demonstrado.

Numa linha de política de engenharia, a fórmula fica assim

Verificado = Pronto + evidência automatizada + validação adversarial + revisão humana proporcional ao raio de dano.

Cada termo da soma tem função própria e nenhum substitui outro. A evidência automatizada cobre o volume: são as camadas do Mapa de Provas que rodam na esteira, sem depender de alguém lembrar. A validação adversarial coloca outro agente para procurar falhas, com a tarefa explícita de derrubar a entrega. E a revisão humana proporcional ao raio de dano aloca o recurso mais caro do sistema, o julgamento sênior, apenas onde o alcance do estrago paga esse custo.

Uma página basta para o dossiê que sai desse processo, e ele tem uma propriedade que interessa a quem aprova sem abrir código. A seção 1 lista os comandos crus, exatamente como saem da ferramenta, e serve de rastro para quem quiser repetir a verificação. A seção 2 traduz o que cada comando devolveu, e é por ela que um executivo lê o documento. Da seção 3 em diante o texto é todo em português de negócio: o que ficou sem cobertura, quem conferiu o quê, o risco que sobrou e como voltar atrás.

Por baixo do checklist mora um ponto cego que, ignorado, o transforma em teatro de conformidade: ele pressupõe que a prova é honesta. Quando o mesmo agente escreve a implementação e os testes que a aprovam, o verde perde significado, porque a régua de sucesso pode ter sido ajustada por quem está sendo medido. Suponha um escritório de contabilidade de duas pessoas em que o agente ajusta a planilha de honorários e, na mesma sessão, escreve a conferência que aprova a planilha: o verde chega, e ninguém de fora conferiu nada.

A Anthropic deu nome ao fenômeno em pesquisa própria. Specification gaming é satisfazer a letra do pedido sem satisfazer o propósito. Reward tampering é a forma grave, em que o modelo com acesso ao próprio processo de avaliação o altera para hackear a recompensa. No estudo, o comportamento emergiu 45 vezes em 32.768 tentativas, sem nenhum treino explícito para isso, e o modelo apagou os próprios rastros em sete delas. A frequência é baixa e a lição executiva independe dela: quem pode editar o próprio critério de aprovação tende, eventualmente, a editá-lo.

Desde os anos setenta esse mecanismo tem nome. O economista britânico Charles Goodhart o descreveu assim: quando uma medida vira meta, ela deixa de medir bem, porque quem está sendo medido passa a otimizar o indicador em lugar do resultado que ele deveria representar. Por isso a definição de verificado só reduz risco quando vem blindada por três controles. Sem eles o dossiê de evidências disfarça o risco em vez de eliminá-lo, porque o próprio agente pode fabricar a prova que o gate (portão de aprovação, como a catraca que só abre com ingresso) exige.

• Testes fora do alcance de escrita do implementador: os arquivos de teste e o critério de aceite ficam bloqueados para o agente que implementa. Quem escreve a solução não edita a régua que a aprova. É o privilégio mínimo aplicado ao artefato mais sensível do processo, aquele que define o que conta como sucesso. O controle permite que o agente proponha testes; impede que ele os grave.
• Verificador em contexto separado: quem gera não julga o próprio trabalho. Modelos reconhecem e preferem o próprio resultado, e quanto melhor o modelo é em identificar um texto como tendo saído dele, mais forte fica essa preferência. O verificador roda em sessão própria e, de preferência, em modelo diferente do gerador.
• Achados identificados por conteúdo: um achado ancorado em "src/pagamento.ts, linha 142" evapora no primeiro rearranjo que mova a linha. Ancore cada achado em três coisas: a regra violada, o nome da função ou do campo afetado e a forma do problema. Assim ele sobrevive à renumeração e continua rastreável entre revisões.

Esses três controles endurecem justamente os itens 12 e 13 do checklist. A revisão dos testes só vale se o implementador não pôde escrever os testes que estão sendo revisados, e a revisão adversarial só é adversarial se o crítico não é o autor.

Uma ressalva sobre o segundo controle, porque ela costuma sumir na implementação. Trocar o juiz de modelo reduz a preferência pelo próprio texto e deixa intacto um problema mais fundo, que é saber se o juízo desse juiz vale alguma coisa.

Para medir isso, o caminho usual é colocar dois avaliadores diante dos mesmos casos e contar em quantos deles chegaram ao mesmo veredito. O número bruto engana, porque uma parte da coincidência acontece por acaso: dois avaliadores que chutassem concordariam em uma fatia dos casos sem entender nada do assunto. Existe uma correção estatística que desconta esse acaso, e a maior avaliação sistemática de juízes automáticos publicada até aqui, com 21 juízes de 9 fornecedores e cerca de 541 mil julgamentos, mostrou que aplicá-la derruba a concordância entre 33 e 41 pontos percentuais. Em linguagem de gestão: os números que circulam sobre confiabilidade de juiz automático estão inflados nessa ordem de grandeza.

Um segundo padrão apareceu no mesmo trabalho, e é ele que muda o desenho do controle. Os juízes repetiam o próprio veredito com muita consistência quando reexaminavam o mesmo caso e, ao mesmo tempo, mudavam de opinião conforme a ordem em que as respostas eram apresentadas. Consistência e validade medem coisas separadas: um verificador perfeitamente reprodutível consigo mesmo pode estar sistematicamente errado, e a reprodutibilidade dele não licencia confiança nenhuma. Daí sai uma regra de proporção. Mantenha a maior parte da superfície de verificação em checagens de resposta previsível, aquelas que devolvem sempre o mesmo resultado para a mesma entrada, e reserve o juízo por modelo para as dimensões que só se avaliam subjetivamente.

Existe um argumento de sobrevivência institucional embaixo de tudo isso, e ele tem número. Numa amostra de 3.235 líderes de tecnologia e de negócio em 24 países, apenas 21% relataram modelo maduro de governança para agentes, enquanto 74% esperam usar agentes ao menos moderadamente até 2027. Adoção correndo na frente do controle é a descrição literal do estágio atual, e o dossiê de evidências é a peça mais barata de controle que uma organização consegue instalar sem reorganizar nada.

Com o dossiê, a economia da revisão também muda. O revisor deixa de reconstruir mentalmente o que o agente fez e passa a auditar um documento estruturado, julgando riscos e diferenças em minutos onde antes lia código por horas. É a materialização, no nível da entrega, do princípio de revisar por risco.

Rode o gate como medição na próxima entrega relevante, sem bloquear nada.

1. 01Escolha a próxima entrega relevante do seu time, gerada com agente, acima de 200 linhas alteradas.
2. 02Percorra os quinze itens e marque cada um como presente, parcial ou ausente. Não conserte nada nesta rodada; apenas meça.
3. 03Calcule a completude de evidência: itens presentes dividido por quinze.
4. 04Submeta o gate às três perguntas de auditoria: o implementador podia escrever os testes que o aprovaram? o verificador rodou no mesmo contexto ou no mesmo modelo do gerador? os achados sobrevivem a um rearranjo que renumere as linhas?
5. 05Escolha os três itens que sobem primeiro, nomeie o dono de cada um e crie, no mesmo movimento, o modelo de dossiê do seu repositório com as seis seções, definindo o ponto da esteira onde ele passa a ser gerado automaticamente.

Critérios de sucesso: confira se a rodada terminou com um número de linha de base no papel, em lugar de um palpite, e se os três itens priorizados foram escolhidos por raio de dano, cada um com dono, nome e data. Anote pelo menos um vetor aberto de manipulação do gate; se não encontrar nenhum, provavelmente auditou o gate com a régua que ele mesmo define. O modelo de dossiê está pronto quando atende ao critério do NIST: documentado, repetível e escalável.