Dois motores, uma auditoria
Por que um segundo modelo de IA lendo o mesmo código muda o que a auditoria encontra e como dois relatórios viram um sem dobrar o ruído.
· 5 min de leitura · Lina Source LLC
Peça a dois revisores experientes que leiam a mesma pull request e você recebe duas listas diferentes. Um percebe que o identificador na URL nunca é conferido contra a sessão; o outro nota que o laço de retentativa deixa uma conexão de banco aberta a cada falha. Nenhum está errado e nenhum está completo. Modelos de linguagem se comportam do mesmo jeito, pelo mesmo motivo: o que um revisor percebe depende do que ele já viu.
Concordância é sinal
Um modelo sozinho informa a própria confiança. Esse número vale algo, mas é autodeclarado: o modelo corrige a própria prova. Quando dois modelos treinados por laboratórios diferentes, com dados diferentes e fraquezas diferentes, chegam de forma independente à mesma falha no mesmo arquivo, essa concordância é evidência vinda de fora do modelo. É o mais perto de uma segunda opinião que uma revisão automatizada consegue chegar.
O inverso importa tanto quanto. Um achado relatado por apenas um motor não é falso por isso, e descartá-lo seria jogar fora justamente os bugs que um revisor sozinho encontra bem. Ele deve ser relatado e atribuído, para que você mesmo avalie.
Onde um motor fica calado
Na prática os dois motores divergem mais nas classes de bug que exigem raciocínio em vez de reconhecimento de padrões:
- Falhas de lógica: um desconto aplicado duas vezes, uma máquina de estados que aceita reembolso depois de um reembolso, uma checagem de propriedade feita no objeto errado.
- Autorização específica do framework: middleware que protege um grupo de rotas, mas não o handler de API montado ao lado.
- Vazamentos de recurso e memória: listeners, timers e conexões abertos por requisição e liberados apenas no caminho feliz.
- Prompt injection escondida em comentários ou fixtures, que se lê como texto inofensivo se você não estiver procurando.
Como dois relatórios viram um
A junção é onde o segundo motor se paga ou dobra o seu ruído. As regras que adotamos:
- Os achados são casados pelo que identifica o bug, não pela redação: sua classe CWE e o arquivo onde ele está.
- Uma correspondência é relatada uma vez, com a mais rígida das duas severidades, porque a leitura segura é aquela sobre a qual se age.
- Fica a redação com que um desenvolvedor consegue trabalhar: a evidência mais longa, o patch concreto, os passos ordenados.
- Um achado corroborado sobe para confiança alta e recebe o rótulo dos dois motores.
- Um achado visto por apenas um motor é mantido, marcado com o motor que o encontrou.
Os dois motores leem a mesma fonte ao mesmo tempo, então a auditoria não demora o dobro; ela custa o dobro para rodar, e é por isso que pertence ao plano Pro. Se o segundo motor estiver indisponível ou devolver algo inaproveitável, a auditoria termina com o primeiro em vez de falhar.
Nada disso torna um relatório verdadeiro. Dois motores podem concordar e ambos errarem; a evidência citada sob cada achado existe justamente para você conferir em vez de confiar. O que a corroboração dá é uma ordem: quando chegam cem achados e você tem uma tarde, comece pelos que dois revisores independentes viram.