Resumo Técnico: Os LLMs Podem Produzir Designs Orientados a Objetos Melhores do Que o Desenvolvimento Envolvendo Humanos?

Declaração do Problema

Enquanto os Modelos de Linguagem Grandes (LLMs) estão cada vez mais capazes de gerar código, sua capacidade de produzir Design Orientado a Objetos (OOD) de alta qualidade para projetos multi-classe permanece incerta. Pesquisas anteriores focaram-se amplamente em:

1. Correção funcional no nível do problema (métodos ou classes únicos) em vez da arquitetura no nível do projeto.
2. Linhas de base pré-LLM, falhando em contabilizar o impacto do desenvolvimento humano assistido por LLM (PósIA).
3. Artefatos de alto nível (por exemplo, diagramas UML) em vez da manutenibilidade e qualidade estrutural do código implementado.

Este estudo aborda a lacuna na compreensão de como a qualidade do OOD em projetos gerados de ponta a ponta por LLMs (PuraIA) se compara a projetos envolvendo humanos produzidos antes (PréIA) e depois (PósIA) da adoção generalizada de LLMs.

Metodologia

Os autores conduziram um estudo de caso comparativo utilizando uma tarefa de pós-graduação em Java: implementar o jogo de tabuleiro Kalah. O estudo analisou 11 conjuntos de dados em três condições de autoria:

1. PréIA (Envolvendo Humanos, Pré-LLM): 93 submissões de março de 2021, anteriores ao lançamento público dos principais assistentes de codificação com LLM.
2. PósIA (Envolvendo Humanos, Pós-LLM): 57 submissões de agosto de 2024, após as ferramentas LLM se tornarem mainstream.
3. PuraIA (Gerado por LLM): Mais de 810 execuções de geração usando três modelos contemporâneos (gpt-5.4, gemini-2.5-pro, gemini-3.1-pro-preview) em três variantes de prompt variando na especificidade do guia de OOD (Nenhum, Ampla, Específica). Apenas execuções que passaram em todos os 19 casos de teste funcionais (após até cinco iterações de reparo) foram retidas.

Métricas de Avaliação

O estudo empregou um framework de avaliação multidimensional:

• Métricas OOD: 13 métricas capturando características estruturais, incluindo Métodos Ponderados por Classe (WMC), Acoplamento entre Classes de Objetos (CBO), Falta de Coesão em Métodos (LCOM), Profundidade da Árvore de Herança (DIT), Número de Classes (#Cl) e Linhas de Código (LOC).
• Densidade de Odores de Código: Densidade no nível do projeto de 30 tipos de odores detectados (11 no nível de método, 19 no nível de classe), normalizada por tamanho (KLOC).
• Modelagem de Domínio:
  • Representação de Conceitos: Se seis conceitos-chave de domínio (Tabuleiro, Jogo, Jogador, Buraco, Casa, Armazenamento) foram explicitamente modelados como classes.
  • Conformidade em Tempo de Execução: Se o número de objetos instanciados correspondia aos requisitos implícitos pelos conceitos de domínio.

Análise Estatística

As comparações utilizaram o teste U de Mann–Whitney com o delta de Cliff ($\delta$) para tamanho do efeito em métricas não binárias, e testes Qui-quadrado/Exato de Fisher com Razões de Chances (OR) para métricas binárias. Os resultados foram corrigidos para comparações múltiplas usando o procedimento Benjamini–Hochberg.

Principais Contribuições

1. Primeira Análise Comparativa: Este é o primeiro estudo a comparar a qualidade do OOD entre as condições PréIA, PósIA e PuraIA em um cenário no nível do projeto.
2. Avaliação Multidimensional: O estudo combina métricas quantitativas de OOD, análise de odores de código e modelagem de domínio baseada em requisitos para fornecer uma visão holística da qualidade do design.
3. Evidência Empírica sobre Simplificação Excessiva: O artigo fornece evidências de que, embora o código gerado por LLMs frequentemente pareça "mais limpo" (menor densidade de odores), isso está frequentemente associado à simplificação excessiva (abstrações ausentes, separação de responsabilidades mais fraca).
4. Insights sobre Tendências PósIA: O estudo demonstra que projetos envolvendo humanos na era dos LLMs (PósIA) exibem tendências de design mais próximas da PuraIA (simplificação) do que da PréIA, mas sem a mesma redução em odores de código.

Resultados

RQ1: Diferenças entre PréIA, PósIA e PuraIA

• Simplicidade Estrutural vs. Simplificação Excessiva: Projetos PuraIA geralmente exibem menos classes, menor complexidade total, tamanho e acoplamento em comparação com projetos humanos. No entanto, essa "simplicidade" correlaciona-se com simplificação excessiva:
  • Maior complexidade/acoplamento médio e percentual máximo por classe (carga concentrada em menos classes).
  • Menor coesão (maior LCOM), já que classes únicas frequentemente representam múltiplos conceitos de domínio.
  • Menos conceitos de domínio explicitamente representados (abstrações ausentes).
• Odores de Código: Projetos PuraIA mostram densidade significativamente menor de odores de código (tanto no nível de método quanto de classe) em comparação com projetos envolvendo humanos.
• Convergência PósIA: Projetos PósIA estão estatisticamente mais próximos da PuraIA do que da PréIA em muitas métricas de OOD, mostrando tendências semelhantes de simplificação e conceitos de domínio ausentes. No entanto, ao contrário da PuraIA, projetos PósIA têm maior densidade de odores de código do que PréIA, particularmente no nível de método.
• Conformidade em Tempo de Execução: Uma vez que um conceito de domínio é representado, projetos PuraIA são geralmente mais propensos a conformar-se em tempo de execução do que projetos humanos.

RQ2: Efeito da Especificidade do Prompt na PuraIA

• Impacto do Guia: Aumentar a especificidade do prompt (de Nenhum $\to$ Ampla $\to$ Específica) geralmente leva a:
  • Mais classes e maior complexidade total/tamanho/acoplamento (afastando-se da simplificação excessiva).
  • Menor complexidade/acoplamento médio e percentual máximo por classe.
  • Redução da densidade geral e no nível de método de odores de código.
  • Melhora na representação de conceitos de domínio (embora os efeitos variem por modelo).
• Limitações: Prompts mais específicos não fecham totalmente a lacuna com projetos envolvendo humanos. Para alguns modelos (por exemplo, O54), aumentar a especificidade de Ampla para Específica produz melhoria adicional limitada.

Significado e Implicações

O artigo conclui que, embora os LLMs possam lidar efetivamente com detalhes de implementação (produzindo código com menos odores e alta conformidade em tempo de execução), eles lutam com decomposição orientada a objetos e atribuição de responsabilidades sem orientação humana explícita.

• Risco de Simplificação Excessiva: Projetos PuraIA frequentemente parecem mais simples e menos "cheios de odores", mas isso mascara uma falta de abstração adequada e separação de responsabilidades, o que pode prejudicar a manutenibilidade a longo prazo.
• Aviso PósIA: A disponibilidade de ferramentas LLM pode levar desenvolvedores humanos a produzir designs que imitam a simplificação excessiva dos LLMs (conceitos ausentes) enquanto introduzem novos problemas locais (odores no nível de método), potencialmente negando ganhos de produtividade.
• Necessidade de Humano no Loop: Orientação humana adequada sobre decomposição de alto nível e modelagem de domínio permanece crítica. Confiar apenas em prompts genéricos ou mesmo específicos de OOD é insuficiente para alcançar qualidade de design comparável à humana.
• Estratégia de Revisão: Revisões de código em ambientes assistidos por LLM devem verificar explicitamente conceitos de domínio ausentes e estruturas simplificadas excessivamente, em vez de apenas correção funcional ou odores de código locais.

O estudo sugere que o uso mais eficaz de LLMs em OOD é aproveitá-los para implementação dentro de uma estrutura definida por especialistas humanos que entendem o domínio e a arquitetura desejada.