A maioria dos relatórios comparando os modelos de IA são baseados em benchmarks de desempenho, mas um Relatório de pesquisa recente Do sonar adota uma abordagem diferente: agrupando modelos diferentes por suas personalidades de codificação e olhando para as desvantagens de cada uma quando se trata de qualidade de código.
Os pesquisadores estudaram cinco LLMs diferentes usando o mecanismo de análise estática do Sonarqube Enterprise em mais de 4.000 atribuições de Java. Os LLMs revisados foram Claude Sonnet 4, OpenCoder-8B, LLAMA 3.2 90B, GPT-4O e Claude Sonnet 3.7.
Eles descobriram que os modelos tinham características diferentes, como o claude Sonnet 4 sendo muito detalhado em suas saídas, produzindo mais de 3x a tantas linhas de código quanto o Opencoder-8b para o mesmo problema.
Com base nessas características, os pesquisadores dividiram os cinco modelos em arquétipos de codificação. Claude Sonnet 4 foi o “arquiteto sênior”, escrevendo um código sofisticado e complexo, mas introduzindo bugs de alta gravidade. “Devido ao nível de dificuldade técnica tentada, houve mais dessas questões”, disse Donald Fischer, vice -presidente de sonar.
O OpenCoder-8b foi o “prototyper rápido” como resultado de ser o mais rápido e conciso, além de criar dívidas técnicas, tornando-o ideally suited para prova de conceito. Ele criou a densidade de problemas mais alta de todos os modelos, com 32,45 problemas por mil linhas de código.
O LLAMA 3.2 90B foi a “promessa não cumprida”, pois sua escala e apoio implica que deve ser um modelo de primeira linha, mas tinha apenas uma taxa de aprovação de 61,47%. Além disso, 70,73% das vulnerabilidades criadas foram a gravidade do “bloqueador”, o tipo de bug mais grave, que impede que os testes continuem.
O GPT-4O period um “generalista eficiente”, um dos dois trades que é uma escolha comum para a assistência de codificação de uso geral. Seu código não period tão detalhado quanto o arquiteto sênior ou tão conciso quanto o prototyper rápido, mas em algum lugar do meio. Também evitou a produção de bugs graves na maior parte, mas 48,15% de seus bugs foram erros de fluxo de controle.
“Isso mostra uma imagem de um codificador que segura corretamente o objetivo principal, mas muitas vezes se atrapalha
os detalhes necessários para tornar o código robusto. É provável que o código funcione no cenário pretendido, mas será atormentado por problemas persistentes que comprometem a qualidade e a confiabilidade ao longo do tempo ”, afirma o relatório.
Finalmente, Claude 3,7 soneto period um “antecessor equilibrado”. Os pesquisadores descobriram que period um desenvolvedor capaz que produziu código bem documentado, mas ainda introduziu um grande número de vulnerabilidades graves.
Embora os modelos tivessem essas personalidades distintas, eles também compartilhavam pontos fortes e fracos semelhantes. Os pontos fortes comuns foram que eles rapidamente produziram o código sintaticamente correto, possuíam fundamentos algorítmicos e da estrutura de dados sólidos e traduzidos com eficiência para diferentes idiomas. As fraquezas comuns foram que todas produziram uma alta porcentagem de vulnerabilidades de alta sexuação, introduziram bugs graves, como vazamentos de recursos ou violações de contrato de API e tinham um viés inerente ao código confuso.
“Como os seres humanos, eles se tornam suscetíveis a questões sutis no código que geram e, portanto, existe essa correlação entre capacidade e introdução de risco, o que eu acho incrivelmente humano”, disse Fischer.
Outra descoberta interessante do relatório é que os modelos mais recentes podem ser mais capazes tecnicamente, mas também são mais propensos a gerar código de risco. Por exemplo, o Claude Sonnet 4 tem uma melhoria de 6,3% em relação ao Claude 3,7 sonetos nas taxas de aprovação de referência, mas os problemas gerados tinham 93% mais probabilities de serem gravidade “bloqueador”.
“Se você acha que o modelo mais recente é superior, pense mais uma vez porque mais novo não é realmente superior; está injetando cada vez mais problemas”, disse Prasenjit Sarkar, gerente de advertising and marketing de soluções da Sonar.
Como os modos de raciocínio afetam o GPT-5
Os pesquisadores seguiram seu relatório esta semana com novos dados no GPT-5 e como os quatro modos de raciocínio disponíveis-minimal, baixo, médio e alto-, desempenho, segurança e qualidade do código.
Eles descobriram que o aumento do raciocínio tem um retorno diminuindo sobre o desempenho funcional. Aumentar de resultados mínimos para baixos na taxa de aprovação do modelo aumentando de 75% para 80%, mas médio e alto tiveram apenas uma taxa de aprovação de 81,96% e 81,68%, respectivamente.
Em termos de segurança, os modos de raciocínio elevados e baixos eliminam ataques comuns como traseira de caminho e injeção, mas substitua-os por falhas mais difíceis de detectar, como manuseio de erros de E/S inadequados. O baixo modo de raciocínio apresentou a maior porcentagem desse problema em 51%, seguido de alta (44%), médio (36%) e mínimo (30%).
“Vimos que a traseira e a injeção se tornam zero por cento”, disse Sarkar. “Podemos ver que eles estão tentando resolver um setor, e o que está acontecendo é que, enquanto eles estão tentando resolver a qualidade do código, estão em algum lugar fazendo essa troca. Se o manuseio inadequado de E/S é outro problema que disparou.
Havia um padrão semelhante com os erros, com erros de fluxo de controle diminuindo além do raciocínio mínimo, mas bugs avançados como simultaneidade / rosqueamento aumentando ao lado da dificuldade de raciocínio.
“As compensações são a coisa principal aqui”, disse Fischer. “Não é tão simples quanto dizer, qual é o melhor modelo? A maneira como isso foi visto na corrida de cavalos entre modelos diferentes é quais completam o maior número de soluções na referência do banco de swe. Como demonstramos, os modelos que podem fazer mais, que ultrapassaram os limites, eles também introduzem mais vulnerabilidades de segurança, introduzem mais problemas de manutenção.”