Rankings Medem Taxa de Acerto. Eles Escondem Falhas de Segurança.

Os rankings que todo mundo cita medem uma coisa só: a taxa de acerto. O código gerado passou no teste? Esse número diz que o modelo consegue produzir algo funcionalmente correto. Não diz nada sobre se uma empresa consegue colocar aquilo em produção.

A Sonar rodou o benchmark que preenche o resto. Prasenjit Sarkar apresentou os resultados no AI Engineer em maio de 2026: 4.444 tarefas Java executadas em mais de 53 modelos, cada saída avaliada pelo SonarQube em segurança, complexidade e manutenibilidade. O conjunto completo está aberto em sonar.com/leaderboard. Uma ressalva logo de início, e ela importa: este é o benchmark da própria Sonar, só em Java, avaliado pelo analisador da própria Sonar. Leia os números como evidência publicada pela Sonar, não como lei universal. Mesmo com essa moldura, o formato dos dados é difícil de ignorar.

O Número no Ranking É o Número Errado

Pegue o Gemini 3.1 Pro High. Na taxa de acerto ele parece excelente: 84,17%. É esse o valor que o comprador vê e em que confia. Por baixo, as mesmas execuções produziram cerca de 614 bugs por milhão de linhas de código, em torno de 210 problemas de segurança por milhão de linhas, e complexidade ciclomática de 234 nas 307 mil linhas geradas para o conjunto. O ranking é real. As falhas embaixo dele também.

Esse é o problema central dos rankings por taxa de acerto. Eles premiam a resposta e ignoram o artefato. Uma empresa não paga por uma resposta correta. Ela paga por código que uma equipe vai ler, estender, proteger e operar por anos. A taxa de acerto mede os primeiros dez minutos. Segurança, complexidade e manutenibilidade medem os próximos dez anos.

Já argumentamos antes que produzir código ficou barato enquanto verificá-lo não ficou. O conjunto de dados da Sonar é a prova de terceiros, modelo a modelo, de que a conta chega em segurança e complexidade, não em correção funcional.

A Verbosidade Cresce a Cada Geração de Modelo

A tendência mais clara nos dados é o volume. Modelos novos não escrevem apenas código melhor. Escrevem muito mais dele.

O GPT-4o produziu menos de 250 mil linhas para o conjunto completo de tarefas. O GPT 5.4, no mesmo conjunto, produziu 1,2 milhão de linhas. Isso é um aumento de cerca de cinco vezes na saída para a tarefa idêntica. O Claude Sonnet 4.6 ficou no meio, com 627 mil linhas, e carregou a maior taxa de problemas de segurança da comparação, em torno de 300 por milhão de linhas.

Mais código não é uma vantagem. Cada linha é uma linha que alguém precisa revisar, uma linha que pode esconder uma falha, uma linha que aumenta o custo da próxima mudança. Quando a verbosidade sobe a cada geração de modelo, a carga de verificação sobe junto. O modelo que escreve 1,2 milhão de linhas entregou à sua equipe 1,2 milhão de linhas para confiar.

As Falhas Estão Ficando Mais Difíceis de Ver, Não Mais Raras

A descoberta mais incômoda não está em nenhuma taxa isolada. Está na textura das falhas.

À medida que os modelos amadurecem, os bugs e as vulnerabilidades que produzem ficam mais sutis. Modelos antigos falhavam alto: código que não compilava, lógica obviamente errada, o tipo de erro que um revisor pega em segundos. Modelos novos falham em silêncio. O código compila, passa no teste, lê-se de forma limpa, e carrega um caminho de injeção sutil ou um vazamento de recurso pelo qual um revisor humano vai passar batido.

Isso inverte a suposição confortável de que modelos melhores reduzem o trabalho de verificação. Eles fazem o oposto. Um bug barulhento é barato de pegar. Uma vulnerabilidade silenciosa enterrada em código limpo e plausível é cara de pegar, e o preço de não pegá-la aparece em produção. A dificuldade de verificação está subindo, não caindo, justamente porque os modelos estão melhorando.

A Verificação Precisa Ir Para a Esquerda, Para os Segundos

Se as falhas são mais sutis e o volume é maior, o loop antigo quebra. Pegar problemas na CI, minutos depois de o código ser escrito, significa que o desenvolvedor já seguiu em frente, o contexto se perdeu, e a correção vira um imposto de troca de contexto. Multiplique isso por milhares de linhas geradas por dia e a CI vira o novo gargalo.

A resposta proposta pela Sonar é o framework ACDC: guiar, verificar, resolver. A parte que importa na operação é o tempo. A análise agêntica do SonarQube roda em um a cinco segundos antes do commit, contra um a cinco minutos na CI. Essa diferença, segundos no teclado contra minutos no pipeline, é a diferença entre uma correção que acontece no fluxo e uma correção que fica adiada.

A camada de remediação é a outra metade. Um agente de remediação faz exatamente uma correção por problema, depois reanalisa e recompila. Se a correção causa regressão em qualquer coisa, ela é descartada. Essa disciplina é o ponto: um agente que gera correções sem um portão de verificação só acrescenta mais código não verificado à pilha. O portão, não a geração, é o que torna tudo confiável.

Faça Isso Agora

Pare de ranquear modelos só por taxa de acerto. Antes de padronizar um modelo de codificação para sua equipe, puxe os números de problemas de segurança por milhão de linhas e de complexidade no ranking aberto da Sonar e pese-os contra a taxa de acerto. O modelo que vence o seu benchmark pode ser o que entrega, em silêncio, mais coisa para sua equipe limpar.

Depois mova sua verificação para a esquerda. Se o seu único portão de qualidade roda na CI, você está pegando falhas mais sutis mais tarde do que pode pagar. Coloque a análise no loop de pré-commit, onde ela roda em segundos e o desenvolvedor ainda tem o contexto para agir. A velocidade de geração não é mais a sua restrição. A velocidade de verificação é.

Fontes

Sonar. “Can LLMs generate Enterprise Quality Code?.” Maio de 2026.

A Victorino ajuda equipes a construir verificação no ritmo da geração de código por IA: contato@victorino.com.br | www.victorino.com.br