O segundo revisor encontrou um campo de filtro em branco que não correspondia a nada

A revisão voltou limpa. Nada era explorável, cada mudança estava restrita ao lugar certo, e o único risco real que ela apontou já tinha uma correção proposta. Concordamos com tudo. Aí, mais por hábito, mandamos o mesmo trabalho para um segundo revisor independente (Ler em inglês).

Duas perguntas diferentes

A primeira revisão tinha feito uma pergunta, e a fez bem: isso passa nas verificações que já sabemos rodar? Passou. Ela não tinha feito a pergunta mais difícil: o que acontece com cada entrada que uma pessoa de verdade poderia produzir, usando a ferramenta do jeito comum? São perguntas diferentes, e o segundo revisor passou o tempo na lacuna entre elas.

O que uma checklist não enxerga

O único problema que a primeira revisão pegou era real, estava classificado corretamente e já tinha uma correção na mesa. O que ela deixou passar foi se o mesmo padrão arriscado existia em algum outro lugar fazendo o mesmo trabalho. Existia. Ele estava em um segundo ponto que a correção proposta nunca tocava, protegido apenas por um comentário que descrevia um comportamento com o qual o código já não combinava.

O resto do que a segunda passada encontrou não parecia bug à primeira vista. Uma operação recebeu um valor inicial vazio que ela não esperava. Ela não lançou um erro. Produziu em silêncio um resultado vazio e o salvou, trocando algo real por nada. Outra tratava um campo de filtro em branco como “não corresponde a nada” em vez de “corresponde a tudo”. Isso reduziu uma alteração em massa a uma fatia minúscula do que era pretendido, enquanto a mensagem de sucesso ainda informava o número que valeria para o conjunto inteiro.

Nada disso aciona uma página de erro. Todos eles parecem, vistos de fora, uma operação que funcionou.

Uma gravação que dá certo e simplesmente está errada

Uma checklist montada a partir de modos de falha conhecidos é boa para problemas barulhentos: os que lançam uma exceção ou deixam alguém ver dados que não deveria. Ela não foi feita, naturalmente, para pegar uma gravação que dá certo, informa sucesso e está errada. Esse é outro formato de falha. Ele pede uma pergunta diferente, não uma checklist mais longa.

Por que a segunda leitura importou

Teria sido razoável tratar uma revisão limpa como suficiente e seguir em frente. A segunda passada valeu a pena porque “isso passa nas verificações que montamos” e “o que um usuário de verdade consegue fazer com isso” são perguntas diferentes, e nenhuma passada isolada responde às duas por acaso. Dúvida sobre a competência do primeiro revisor não teve nada a ver com isso.

Onde a IA entrou, e onde parou

Ler o mesmo código com a segunda pergunta em mente, e trabalhar o que um campo em branco, um valor vazio ou um segundo ponto de chamada realmente fariam, é um trabalho que um revisor de IA consegue fazer rápido e mostrando o raciocínio. Ele achou o padrão porque lhe perguntaram outra coisa, diferente da primeira revisão.

Decidir que essa mudança merecia uma segunda olhada independente foi um julgamento feito por uma pessoa. Decidir o que fazer com as linhas que os erros já tinham atingido também foi, assim como decidir se algo precisava ser corrigido para quem já usava o recurso. Um agente de IA pode dizer que uma gravação está errada em silêncio. Não deveria ser ele a decidir o que acontece depois com as pessoas que já foram afetadas.

Uma revisão que responde “isso passa no que já verificamos” não é uma revisão que responde “o que acontece com cada entrada que uma pessoa de verdade poderia produzir”. A segunda pergunta é a que pega uma gravação que dá certo, informa sucesso e está errada.