Comparando seis LLMs para correções de código no mundo real – GPT‑5, Claude Sonnet, Grok e mais

Introdução

Um benchmark recente do blog Kilo Code colocou seis grandes modelos de linguagem (LLMs) líderes de mercado em três desafios de codificação realistas. O objetivo era simples: ver quais modelos conseguiam identificar bugs críticos de segurança, propor correções prontas para produção e fazer isso de forma econômica. Os modelos avaliados foram GPT‑5, OpenAI o1, Claude Opus 4.1, Claude Sonnet 4.5, Grok 4 e Gemini 2.5 Pro.

Os resultados destacam um trade‑off claro entre profundidade técnica bruta e manutenibilidade prática. Embora todos os modelos tenham identificado as vulnerabilidades, a qualidade, completude e custo das correções variaram drasticamente. A seguir, um detalhamento da metodologia, dos três casos de teste e recomendações acionáveis para engenheiros que desejam escolher um LLM para revisão de código ou verificações automáticas de pull‑request.

---

Metodologia de Teste

A Kilo Code construiu um harness de teste consistente para garantir uma comparação justa:

• Entrada: Trechos de código pequenos e arriscados (10‑50 linhas) foram enviados a cada modelo com o mesmo prompt: “Corrija isso. Sem dicas, sem perguntas guiadas.”
• Fase 1 – Avaliação por IA: Um rubric automatizado pontuou cada resposta quanto à correção, qualidade do código, completude, práticas orientadas à segurança e desempenho.
• Fase 2 – Validação Humana: Engenheiros revisaram as correções classificadas pela IA e selecionaram as versões que realmente mesclariam.

Essa abordagem em duas etapas combinou métricas objetivas com o julgamento de desenvolvedores no mundo real, oferecendo uma visão pragmática da utilidade de cada modelo em pipelines de produção.

---

Cenário 1 – Vulnerabilidade de Merge de Configuração em Node.js

Problema: Uma função de deep‑merge propaga inadvertidamente uma flag admin maliciosa de um payload forjado através de cadeias de protótipos, espelhando padrões clássicos de OASP.

Resultados dos Modelos:

• GPT‑5: Implementou salvaguardas em camadas — objetos base com protótipo nulo, bloqueio explícito de chaves arriscadas, verificações hasOwnProperty e congelamento de objetos sensíveis. A correção foi completa e pronta para produção.
• OpenAI o1: Entregou funções auxiliares limpas, uma lista concisa de chaves proibidas e comentários legíveis. A solução foi fácil de auditar em poucos minutos.
• Claude Sonnet 4.5: Usou Object.create(null) e bloqueio de chaves, oferecendo proteção sólida, porém com profundidade ligeiramente menor que a do GPT‑5.
• Gemini 2.5 Pro: Aplicou filtragem de chaves e protótipos nulos, mas deixou escapar alguns casos de borda recursivos.
• Claude Opus 4.1: Baseou‑se em esquemas e verificações de tipo — eficaz, porém adicionou sobrecarga de manutenção.
• Grok 4: Focou em filtragem simples e omitiu a validação hasOwnProperty, resultando em uma correção mais fraca.

Conclusão: Todos os modelos detectaram a falha, mas apenas GPT‑5 e OpenAI o1 produziram correções que pareciam prontas para produção sem complexidade excessiva.

---

Cenário 2 – Workflow de Agente Moderno (Estilo 2025)

Problema: Um agente impulsionado por IA busca uma página web, interpreta seu conteúdo e propõe chamadas de ferramenta a uma API de gerenciamento de nuvem. Sem limites rígidos, o agente pode executar instruções maliciosas, provocando vazamento de tokens entre inquilinos e alterações não autorizadas.

Resultados dos Modelos:

• GPT‑5: Introduziu escopos de ferramenta estreitos, regras de confirmação em duas etapas, limites de confiança estritos (credenciais nunca aparecem no texto do modelo), verificações de proveniência no HTML obtido e tokens baseados em papéis, de curta duração.
• OpenAI o1: Igualou a profundidade do GPT‑5, acrescentando análise RBAC de “shadow‑tenant”, validação de esquema de resposta e uma configuração que elimina totalmente o acesso ao sistema de arquivos.
• Claude Sonnet 4.5: Cobriu limites de confiança e rastreamento de proveniência, mas careceu dos detalhes granulares de implementação do GPT‑5.
• Gemini 2.5 Pro: Definiu escopos de ferramentas e usou validação de esquema; o gating estava presente, porém mais leve que o dos top performers.
• Claude Opus 4.1: Empregou validação Zod e DOM purify, fornecendo diagramas claros, porém com menos defesas em camadas.
• Grok 4: Referenciou o top‑10 de OASP e diretrizes NIST com listas de permissão; a lógica de gating permaneceu simples.

Conclusão: Para padrões novos e complexos, o raciocínio mais profundo (como demonstrado por GPT‑5 e OpenAI o1) supera a simples correspondência de padrões.

---

Cenário 3 – Injeção de Comando no ImageMagick

Problema: Uma API Express monta um comando shell para o ImageMagick usando fonte e texto fornecidos pelo usuário. Um payload malicioso pode injetar operadores de shell (ex.: ; rm -rf /), levando à execução arbitrária de código.

Resultados dos Modelos:

• GPT‑5: Implementou defesa abrangente — listas de permissão estritas, caminhos absolutos para fontes, evitação de prefixos especiais, execução via vetores de argumentos (sem shell), entrada por stdin, limites de tamanho/taxa e limpeza automática de arquivos temporários.
• Claude Opus 4.1: Similar em rigor, usando spawn, listas de permissão, validação de tamanho, filtragem de caracteres de controle e demos detalhadas para revisores.
• Claude Sonnet 4.5: Utilizou execFile com listas de permissão fortes e limitação de taxa.
• OpenAI o1: Optou por execFile com validação concisa de fontes e sanitização de texto.
• Gemini 2.5 Pro: Adoptou spawn com listas de permissão e validação limpa.
• Grok 4: Explicou armadilhas de parsing de shell (ponto‑e‑vírgula, pipe, e‑commercial, crases) e migrou para spawn com validação de intervalo.

Conclusão: As melhores soluções combinaram execução de processo segura com listas de permissão rigorosas e limites de taxa, eliminando vetores de injeção via shell.

---

Análise de Custos

Executar os três cenários nos seis modelos custou aproximadamente US$ 181 no total. O caso ImageMagick foi o mais caro devido ao tamanho das respostas dos modelos. O cenário Node.js foi o mais barato, com média de US$ 0,60 por avaliação (cerca de US$ 0,10 por execução de modelo).

Recomendações de Orçamento:

• Para varreduras em massa onde o custo importa, Gemini 2.5 Pro ou OpenAI o1 entregam 90‑95 % da qualidade do GPT‑5 por cerca de 72 % a menos.
• Para domínios de alto risco (financeiro, saúde, APIs privilegiadas), o gasto extra com GPT‑5 se justifica pelas guardrails maximalistas.
• Para revisões estilo OASP geral, Claude Sonnet 4.5 oferece um bom equilíbrio entre cobertura e acessibilidade.

---

Recomendações Pragmas

• Sistemas Críticos: Implante GPT‑5. Suas defesas em camadas e correções exaustivas compensam o preço premium.
• Varreduras de Alto Volume e Baixo Risco: Escolha Gemini 2.5 Pro ou OpenAI o1 para obter desempenho quase máximo com fração do custo.
• Meio‑Termo: Claude Sonnet 4.5 fornece proteção sólida em padrões familiares, mantendo a conta sob controle.
• Manutenibilidade Importa: Revisores humanos preferiram OpenAI o1, pois suas correções eram concisas, legíveis em 15 minutos e ainda cobriam os cenários mais complexos.

A ideia central é que a solução mais perfeita nem sempre é a melhor a longo prazo. Uma correção ligeiramente menos abrangente, porém fácil de entender e manter, pode ser mais valiosa em um ambiente de desenvolvimento ágil.

---

Conclusão

O benchmark da Kilo Code demonstra que os LLMs modernos atingiram um nível em que todos os seis modelos detectam de forma confiável bugs críticos de segurança. Os diferenciais agora residem em quão completas são as correções, a profundidade das guardrails em camadas e o custo total de execução.

• GPT‑5 lidera em profundidade técnica e segurança, ideal para código mission‑critical.
• OpenAI o1 oferece um equilíbrio pragmático entre legibilidade, robustez e custo.
• Gemini 2.5 Pro e Claude Sonnet 4.5 funcionam como workhorses capazes para a higiene cotidiana de código.

Ao integrar LLMs ao fluxo de pull‑request, combine o modelo à missão: priorize segurança máxima para serviços de alto impacto e opte por modelos econômicos onde velocidade e volume predominam.

Tratando os LLMs como revisores assistentes e não como oráculos substitutos, as equipes de engenharia podem aproveitar seus pontos fortes enquanto mitigam a sobrecarga de manutenção — entregando código mais seguro em escala.