Uma aprovação que só prova que a coisa existe

Uma auditoria independente de 10 dos nossos 163 veredictos “aprovado” encontrou 4 sólidos, 6 fracos e 0 errados. Os 6 fracos tinham o mesmo problema. A verificação tinha provado que um arquivo ou um registro de mudança existia, mas a afirmação verificada era sobre algo a mais: um comportamento, um deploy, uma medição, resultados de testes ou um estado de bloqueio declarado.

Veja como chegamos a isso. Mantemos uma fila de unidades, cada uma delas uma afirmação de que algum trabalho foi feito. Um agente de IA percorria essa fila, conferindo cada afirmação com evidências reais e marcando como aprovada ou reprovada. As instruções eram explícitas: o que ele não conseguisse verificar devia ficar sem confirmação, com um motivo de uma linha, e nunca ser marcado como confirmado só por parecer plausível. O primeiro lote teve 34 aprovações, nenhuma refutação, e deixou 15 das 49 unidades mais antigas sem confirmação. A resposta a esse lote foi “bom lote. Continue com o resto da fila.” Restavam cerca de 870 unidades, então ele continuou e acrescentou mais 127 aprovações. O relatório naquele ponto dizia 161 confirmadas, 0 refutadas. A auditoria contou 163 veredictos de aprovação, e o retrabalho que veio depois cobriu todos os 163.

No que uma aprovação realmente se apoiava

Os próprios relatórios do agente descrevem a lacuna. Os registros guardam só os primeiros 200 caracteres ou so de cada afirmação, então algumas unidades só puderam ser verificadas na parte que ele conseguia ver. Ele também disse que a existência de um commit ou de um tíquete não prova o comportamento nem o resultado dos testes. Cada aprovação trazia uma nota de evidência listando o que foi verificado e o que não foi, e a instrução de acompanhamento da auditoria mirava as notas que diziam que algo não foi verificado, não foi executado de novo ou não foi medido de novo.

Revisando os 163

A instrução depois da auditoria foi revisar todos eles. Quando uma nota de evidência dizia que algo não foi verificado, não foi executado de novo ou não foi medido de novo, o agente devia fazer a verificação real, se fosse somente leitura e barata. Caso contrário, devia registrar um veredicto substituto que não fosse aprovação, citando a lacuna.

O resultado: 62 continuam como aprovados. 59 foram registrados de novo como aprovados depois de uma verificação real. 42 agora estão reprovados. O resumo do agente foi que a auditoria estava certa, e que muitas das aprovações só mostravam que um commit ou um arquivo existia.

As verificações reais foram bem comuns:

• Ele rodou a suíte de testes completa de uma das nossas APIs em uma cópia nova do origin/main atual. O resultado foi 2301 aprovados, 1 ignorado, 0 com falha, depois de definir PUBLIC_CURSOR_SECRET com um valor fictício. Sem ela, 296 testes falham com erro 503 porque essa variável está ausente.
• Ele rodou os testes específicos das unidades que antes tinha verificado só pelo commit. 411 aprovados, 0 com falha.
• Ele olhou o que está no ar. O bundle do diálogo de chave de API em produção bate com o origin/master e contém a opção de expiração de 1 ano, o indicador de retorno do foco e o novo texto de dica. O popup da newsletter em produção já traz a correção. Um script de agendamento em produção é idêntico, byte a byte, à sua tag. As páginas /about e /now do dxdev.com trazem o texto final.

A execução da suíte completa é um resultado para a main atual, não para os commits originais. Algumas unidades não têm nenhum teste indicado para a sua mudança, e o agente disse isso nas notas dessas unidades.

Por que os 42 estão rotulados assim

O comando de verificação da CLI só aceita pass ou fail, então cada rebaixamento teve de ser registrado como fail. Cada um está marcado como “DOWNGRADE, NOT REFUTED” e cita a lacuna. Nenhum foi desmentido. Os últimos veredictos por unidade agora são 121 aprovados e 42 reprovados. Qualquer métrica que conte reprovações como refutações vai contar os 42, então ela precisa filtrar pela expressão “DOWNGRADE, NOT REFUTED”.