Evaluating LLM-Generated Code: A Benchmark and Developer Study

Declaração do Problema
Os métodos atuais de avaliação para Modelos de Linguagem de Grande Escala (LLMs) em geração de código (NL2Code) dependem predominantemente de benchmarks que medem a correção da solução por meio de testes de unidade em tarefas isoladas de nível de função (ex: HumanEval, MBPP). Embora eficazes para estabelecer capacidades de base, esses benchmarks falham em refletir cenários de programação do mundo real. A codificação no mundo real frequentemente envolve a criação de projetos de múltiplos componentes com dependências, exigindo prompts sequenciais e necessitando de um código que não seja apenas correto, mas também legível, mantível e pronto para produção. Além disso, há uma escassez de pesquisas envolvendo especialistas humanos para avaliar a qualidade e a usabilidade do código gerado por LLMs, já que a maioria das avaliações depende exclusivamente de métricas automatizadas ou da abordagem "LLM-as-a-Judge" (LLM como Juiz), que podem não capturar totalmente preocupações centradas no desenvolvedor, como estrutura e documentação.

Metodologia
O artigo propõe uma metodologia de avaliação de três frentes personalizada, projetada para preencher a lacuna entre o teste de funções isoladas e a avaliação holística de projetos. Este framework integra testes de correção automatizados, verificação de qualidade de código automatizada e avaliação humana estruturada.

1. Tarefa de Codificação: O estudo utiliza um projeto de ciência da computação complexo e de múltiplos componentes intitulado "Building the Tree of Life from Scratch" (Construindo a Árvore da Vida do Zero), adaptado da lista de Tarefas NIFTY. A tarefa envolve bioinformática (árvores filogenéticas) e exige a implementação de programação dinâmica, recursão, grafos e estruturas de árvore. Os LLMs são instigados através de um conjunto fixo de 14 prompts sequenciais para gerar a solução do zero, sem código inicial, mimetizando o fluxo de trabalho de um desenvolvedor real.
2. Benchmark de Correção: Um benchmark customizado foi desenvolvido para verificar a solução em múltiplos checkpoints, em vez de apenas na saída final. Isso inclui:
   • Verificação de pontuações de Needleman-Wunsch.
   • Validação da sintaxe do formato Newick (para estrutura de árvore e distâncias de nós).
   • Checagem da estrutura da árvore filogenética.
   • Validação de resultados de agrupamento (clustering) baseados em limiares.
   • Confirmação da geração de um arquivo PNG de dendrograma.
   • Verificação Técnica: Uma etapa manual foi incluída onde pesquisadores corrigiram erros menores de sintaxe, compilação e dependências para garantir que o código pudesse ser executado, documentando essas correções para avaliar a "capacidade de correção" (fixability).
3. Verificação de Qualidade Automatizada: O código gerado foi analisado utilizando o SonarQube para medir confiabilidade, manutenibilidade e segurança, além de contar "code smells" (maus cheiros no código) e dívida técnica.
4. Avaliação de Qualidade Baseada em Humanos (Estudo com Desenvolvedores): Um questionário estruturado foi desenhado para coletar revisões de código de desenvolvedores voluntários. O questionário utilizou uma escala Likert de 5 pontos em 14 métricas categorizadas em:
   • Estrutura da base de código (nomeação, formatação, separação de preocupações).
   • Qualidade de comentários e explicações (utilidade, posicionamento, qualidade do README).
   • Facilidade de uso (modificabilidade, testabilidade).
   • Um campo aberto para comentários adicionais e uma pergunta final perguntando em qual código o desenvolvedor escolheria trabalhar.

Configuração Experimental
A metodologia foi aplicada a três LLMs de propósito geral: GPT-4.1, DeepSeek-V3-0324 e Claude Opus 4. Cada modelo foi executado três vezes com parâmetros fixos (temperatura 0.2, max tokens 4096) para considerar a não-determinismo. Para o questionário humano, uma solução por modelo (selecionada com base na maior taxa de aprovação de correção) foi revisada por 10 desenvolvedores voluntários recrutados via LinkedIn.

Principais Resultados

• Correção: O DeepSeek-V3-0324 alcançou a maior pontuação de correção, passando em 5 de 7 casos de teste em sua melhor execução. O GPT-4.1 foi o único modelo a gerar soluções que rodaram sem intervenção manual em duas de suas três tentativas, embora tenha passado em menos casos de teste no total (3-4/7). O Claude Opus 4 teve o pior desempenho em termos de correção, com uma tentativa passando em zero testes.
• Qualidade Automatizada: Todos os modelos receberam classificações 'A' para segurança, confiabilidade e manutenibilidade no SonarQube. No entanto, as soluções do DeepSeek tiveram o menor número de code smells e o menor tempo estimado para corrigir problemas. As soluções do GPT-4.1 tiveram a maior proporção de dívida técnica e tempos de correção mais longos.
• Questionário Humano: Apesar de o DeepSeek possuir as melhores métricas automatizadas, o questionário dos desenvolvedores revelou uma divergência de preferência. Os desenvolvedores avaliaram o GPT-4.1 negativamente, citando comentários pobres, estrutura caótica e argumentos codificados (hard-coded). Enquanto o DeepSeek foi elogiado pela parametrização, o Claude Opus 4 recebeu o feedback mais positivo em relação à facilidade de modificação e teste. Notavelmente, quando questionados sobre qual código escolheriam para trabalhar, 6 de 10 desenvolvedores selecionaram a solução do Claude, enquanto apenas 4 escolheram o DeepSeek.
• Alinhamento: O estudo descobriu que métricas de correção automatizadas e avaliações de qualidade humana se complementam, mas nem sempre se alinham. Um modelo com maior correção (DeepSeek) não foi necessariamente o preferido pelos desenvolvedos sobre um modelo com correção ligeiramente inferior, mas com melhor estrutura e legibilidade (Claude).

Significância e Contribuições
O artigo afirma realizar quatro contribuições primárias para o campo:

1. Um framework de avaliação de três frentes que combina testes automatizados, verificação de qualidade de código e pesquisas com desenvolvedores para capturar tanto a correção quanto a usabilidade.
2. Um benchmark de correção em nível de projeto baseado em uma tarefa complexa de múltiplos arquivos, indo além de tarefas isoladas de nível de função.
3. Um design de questionário estruturado dedicado a coletar revisões de código de desenvolvedores de maneira padronizada, abordando a falta de avaliação centrada no humano na pesquisa de LLMs.
4. Uma demonstração do framework através da avaliação de três LLMs, mostrando que as revisões de desenvolvedores podem gerar descobertas críticas — particularmente em relação à prontidão para produção e manutenibilidade — que os benchmarks de correção padrão ignoram.

Os autores concluem que, embora os benchmarks automatizados sejam úteis, uma avaliação abrangente de LLMs para geração de código requer a integração do feedback humano para entender a utilidade prática e a experiência do desenvolvedor com as soluções geradas. O estudo destaca que código "correto" nem sempre é um código "bom" em um contexto de produção.