🤖 AI

A Tertiary Review of Large Language Model-Based Code Generating Tasks: Trends, Challenges, and Future Directions

Esta revisão terciária sintetiza 30 estudos secundários sobre geração de código baseada em modelos de linguagem de grande escala para revelar um campo em rápido crescimento, mas avaliado de forma desigual, onde o forte desempenho em benchmarks contrasta com desafios significativos na generalização do mundo real, robustez, eficiência e integração sócio-técnica.

Autores originais: Muslim Chochlov, Michael English, Jim Buckley

Publicado 2026-05-26

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Muslim Chochlov, Michael English, Jim Buckley

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine o mundo do desenvolvimento de software como um canteiro de obras massivo e movimentado. Por anos, os trabalhadores (programadores) construíram edifícios (software) à mão, tijolo por tijolo. Recentemente, um novo tipo de robô chegou: o Modelo de Linguagem de Grande Escala (LLM). Esses robôs podem ler uma planta (uma descrição) e, instantaneamente, assentar tijolos, escrever código ou até mesmo consertar paredes quebradas.

Este artigo não é um relatório sobre o desempenho de um único robô. Em vez disso, é uma "Revisão Terciária". Pense nisso como um meta-relatório. Os autores não saíram para testar os robôs pessoalmente. Em vez disso, eles reuniram e analisaram 30 relatórios existentes (estudos secundários) que haviam testado esses robôs. Eles queriam ver o quadro geral: Quão rápido esse campo está crescendo? O que os relatórios dizem que funciona? Onde os robôs estão falhando? E o que os especialistas acham que precisamos fazer a seguir?

Aqui está a divisão de suas descobertas, traduzida para a linguagem cotidiana:

1. O Cenário: Um Campo Explodindo de Atividade

Os autores observaram o "canteiro de obras" da pesquisa.

O Boom: Em 2022, havia apenas um relatório sobre esses robôs. Até 2024, esse número saltou para 17. É como uma corrida do ouro súbita, onde todos estão escrevendo sobre os novos robôs.
Amadurecendo: No início, os relatórios eram apenas "pesquisas" (olhando ao redor e dizendo: "Uau, há muitos robôs!"). Agora, os relatórios estão se tornando "revisões sistemáticas" (investigações profundas e rigorosas). Isso sugere que o campo está amadurecendo de uma moda passageira para uma ciência séria.
A Armadilha da Redundância: Embora o número de relatórios tenha triplicado, o número de testes reais de robôs que eles cobriram não cresceu tanto. É como ter 100 pessoas escrevendo resenhas das mesmas 10 filmes. Os autores alertam que os pesquisadores podem estar repetindo o mesmo trabalho em vez de descobrir coisas novas.

2. O Desempenho: O Cartão de Notas "HELM"

Os autores usaram um cartão de notas especial chamado HELM (Avaliação Holística de Modelos de Linguagem) para classificar os robôs. Imagine avaliar um aluno não apenas pelas suas notas em provas, mas também pela sua segurança, velocidade e justiça.

Precisão (A Nota da Prova): Os robôs estão tirando A's em exames práticos (benchmarks). Eles conseguem resolver quebra-cabeças de codificação específicos muito bem. No entanto, os relatórios de alta qualidade alertam que essas notas podem estar infladas. É como um aluno que decorou o gabarito, mas pode reprovar se as perguntas mudarem ligeiramente. No mundo real, eles frequentemente cometem erros.
Robustez (O "Teste de Estresse"): É aqui que os robôs são frágeis. Se você mudar ligeiramente a redação de um pedido ou pedir que trabalhem em uma linguagem de programação diferente, eles frequentemente quebram. Eles são como um carro esportivo de alto desempenho que dirige maravilhosamente em uma pista, mas falha em uma estrada lamacenta.
Eficiência (A Conta de Luz): Os robôs são caros. Eles exigem quantidades massivas de poder de computador, eletricidade e dinheiro para funcionar. Usá-los em um pequeno escritório ou em um telefone móvel é atualmente como tentar alimentar uma torradeira com um reator nuclear.
Toxicidade e Viés (O Perigo de Segurança): Os robôs às vezes geram código que é inseguro, vaza senhas privadas ou copia material protegido por direitos autorais. Eles também tendem a favorecer certos estilos de codificação em relação a outros, apenas porque foi isso que viram com mais frequência em seus dados de treinamento.

3. Os Cenários: Onde Eles Estão Trabalhando?

Os relatórios focam principalmente nos robôs realizando tarefas básicas de construção:

Geração de Código: Escrever código novo do zero.
Reparo: Corrigir bugs ou falhas de segurança.
Completamento: Terminar uma frase de código que o humano começou.

Curiosamente, os relatórios raramente mencionam onde esse código está sendo usado (por exemplo: é para um sistema hospitalar? Um videogame? Um carro?). Eles também raramente mencionam quais linguagens de programação estão sendo usadas, além das grandes como Python e Java. É como saber que os robôs podem assentar tijolos, mas não saber se estão construindo uma casa, uma ponte ou um castelo.

4. Os Desafios: Por Que Não Podemos Apenas Ativar o Interruptor

Os autores identificaram três grupos principais de problemas impedindo esses robôs de assumirem o canteiro de obras:

A Economia (O Preço): Custa muito caro treinar e executar esses modelos. Pequenas empresas ou desenvolvedores individuais não podem pagar a "conta de luz".
A Avaliação (As Notas Falsas): Os testes que usamos para classificar esses robôs não correspondem à vida real. Eles são muito simples e não levam em conta a realidade bagunçada e complexa de construir software.
A Integração (O Atrito): Os robôs não se encaixam bem nas ferramentas que os desenvolvedores já usam. Eles são lentos, difíceis de controlar e, às vezes, dão respostas confusas ou não confiáveis. Os desenvolvedores ainda não confiam plenamente neles, e novos desenvolvedores podem depender demais deles sem entender o código.

5. O Futuro: O Que Vem Por Aí?

Os relatórios sugerem um caminho claro a seguir, que os autores resumem como:

Especializar os Robôs: Em vez de um robô gigante que sabe um pouco sobre tudo, precisamos de robôs treinados especificamente no código e nas regras da nossa empresa.
Melhores Testes: Precisamos parar de usar exames práticos simples e começar a testar os robôs em cenários realistas e bagunçados.
Trabalho em Equipe: O futuro não é apenas o robô; é o robô trabalhando com ferramentas tradicionais e especialistas humanos (uma abordagem "híbrida").
Segurança em Primeiro Lugar: Precisamos corrigir as falhas de segurança e privacidade antes de soltar esses robôs no mundo real.

A Conclusão

Este artigo conclui que a geração de código baseada em LLM é uma tecnologia de maturação rápida que está atualmente sendo avaliada de forma desigual.

É como um novo motor incrivelmente poderoso que foi instalado em um carro. O motor funciona rápido na pista de testes (benchmarks), mas não temos certeza se ele aguentará um dia chuvoso (robustez no mundo real), se custará uma fortuna em combustível (eficiência) ou se pode acidentalmente levar o carro para um precipício (segurança). O campo está avançando rápido, mas precisamos desacelerar, construir melhores padrões de segurança e descobrir como tornar essa tecnologia realmente útil para os construtores do dia a dia, e não apenas para passar em testes.

Resumo Técnico: Uma Revisão Terciária de Tarefas de Geração de Código Baseadas em Modelos de Linguagem de Grande Escala

Declaração do Problema

Os Modelos de Linguagem de Grande Escala (LLMs) estão sendo cada vez mais aplicados a Tarefas de Geração de Código (CGTs) na Engenharia de Software (ES), mostrando resultados promissores em benchmarks e ensaios específicos (por exemplo, GitHub Copilot, AlphaCode). No entanto, os efeitos mais amplos dessas aplicações, sua integração em fluxos de trabalho de desenvolvimento do mundo real e a validade dos resultados relatados permanecem insuficientemente compreendidos. Estudos secundários e revisões terciárias existentes são frequentemente muito amplos (cobrindo ML geral em ES), muito estreitos (focando apenas em tarefas específicas como teste ou engenharia de prompts) ou carecem de uma definição unificada de CGTs. Consequentemente, há uma falta de evidências consolidadas sobre o panorama, efeitos, desafios e direções futuras especificamente para CGTs baseadas em LLMs. Este artigo aborda essa lacuna conduzindo uma revisão sistemática da literatura terciária (SLR) para sintetizar evidências secundárias existentes.

Metodologia

Os autores seguiram as diretrizes de revisão sistemática de Kitchenham e os padrões de relatórios SEGRESS para relatórios estruturados e transparentes. A metodologia envolveu:

Estratégia de Busca: Uma busca abrangente foi realizada em cinco bibliotecas digitais (IEEE Xplore, ACM DL, Scopus, DBLP, Web of Science) e no Google Scholar. A busca utilizou um processo de construção de consulta baseado em PICOC, validado contra um conjunto de testes, e combinou consultas de banco de dados com a técnica de bola de neve para trás e para frente.
Triagem e Seleção: O processo incluiu triagem de título/resumo e revisão de texto completo. Para gerenciar o volume de registros (particularmente da bola de neve), os autores empregaram uma abordagem de triagem semi-automatizada inovadora usando o GPT-4o como triador de primeira passagem, validado contra julgamento humano.
Critérios de Inclusão/Exclusão: A revisão focou em estudos secundários (SLRs, estudos de mapeamento sistemático, pesquisas, meta-análises) publicados entre 2017 e 2025 (até junho de 2025) que cobriam explicitamente LLMs aplicados a CGTs. Estudos primários, IA não-LLM e tarefas não relacionadas à geração de código (por exemplo, sumarização de código) foram excluídos.
Avaliação de Qualidade: Os estudos selecionados foram avaliados usando os critérios DARE (Database of Abstracts of Reviews of Effects), resultando em uma distribuição de qualidade de 43,3% Alta, 26,7% Média e 30,0% Baixa qualidade.
Extração e Síntese de Dados: Os dados foram extraídos usando um formulário estruturado cobrindo metadados de publicação, escopos de IA/ES e evidências específicas relacionadas ao framework HELM (Holistic Evaluation of Language Models). Os autores adaptaram o framework HELM (originalmente para linguagem natural) ao contexto de ES redefinindo "cenários" para incluir tarefa, linguagem de programação, tipo de aplicação e domínio de aplicação, mapeando "medidas" para interpretações específicas de ES (por exemplo, Precisão como correção funcional, Toxicidade como vulnerabilidades de segurança).
Confiabilidade: A concordância entre avaliadores foi avaliada usando o $\kappa$ de Fleiss e o $\kappa$ de Cohen, resultando em concordância quase perfeita (0,86 para triagem, 0,83 para validação de triagem de IA e alta confiabilidade para extração de dados).

Principais Contribuições

Síntese Terciária de CGTs Baseadas em LLMs: O artigo identifica e sintetiza 30 estudos secundários (2017–2025), quantificando o panorama de publicações, mapeando escopos de IA e ES e analisando tendências. Fornece a primeira visão consolidada de evidências especificamente para geração de código baseada em LLMs.
Aplicação Inovadora de LLMs em Revisão de Literatura: O estudo demonstra o uso confiável do GPT-4o para melhorar a eficiência do processo de bola de neve (triagem de referências), alcançando alta precisão e recall em comparação com a triagem humana, potencialmente economizando esforço humano significativo.
Adaptação do Framework HELM: Os autores adaptam o framework HELM para contextos de engenharia de software. Eles mantêm o design de múltiplas medidas, mas redefinem cenários para refletir dimensões específicas de ES (tarefa, linguagem, tipo/domínio de aplicação) consistentes com SWEBOK v4 e ISO/IEC 25010, fornecendo uma maneira estruturada de avaliar o desempenho de LLMs em CGTs.

Resultados

RQ1: Panorama de Estudos Secundários

Crescimento e Maturação: O número de estudos secundários cresceu rapidamente, triplicando de 2023 (6 estudos) para 2024 (17 estudos). Há uma mudança notável de pesquisas/revisões exploratórias para revisões sistemáticas da literatura (SLRs) e estudos de mapeamento sistemático (SMS) mais rigorosos, com 83% dos estudos de 2025 sendo SLRs/SMSs.
Redundância: Embora o número de estudos secundários tenha aumentado significativamente, o número total de estudos primários únicos revisados cresceu menos dramaticamente, sugerindo redundância emergente e um campo em maturação onde futuras contribuições podem precisar focar no refinamento do escopo em vez do volume.
Escopos: O campo é dominado por estudos focados em LLMs (21/30). Em termos de escopo de ES, "Construção de Software" é o foco principal (25 estudos), seguido por "Manutenção de Software" (14) e "Segurança de Software" (11). A maioria dos estudos é estreita em escopo (cobrindo 1–2 áreas de conhecimento SWEBOK).
Veículos: Jornais de alta qualidade (por exemplo, TOSEM, TSE) hospedam a maioria dos estudos revisados por pares, embora uma parte significativa (9/30) apareça no arXiv, refletindo a natureza acelerada do campo.

RQ2: Medidas HELM Relatadas

Precisão: A medida mais relatada (18 estudos). Embora muitos estudos relatem alta precisão em benchmarks (por exemplo, HumanEval, MBPP), estudos de maior qualidade expressam cautela, observando que as pontuações de benchmark podem ser infladas por vazamento de dados e nem sempre refletem generalização do mundo real ou correção semântica.
Robustez: Relatada em 16 estudos. A evidência sugere que a robustez é frágil; o desempenho varia significativamente entre tarefas, linguagens e configurações. Os modelos frequentemente falham em generalizar além de conjuntos de dados específicos ou exibem sensibilidade a perturbações de prompts.
Eficiência: Discutida em 14 estudos. Há um reconhecimento consistente de altos custos computacionais, econômicos e energéticos associados ao treinamento, inferência e avaliação, particularmente para modelos grandes e ambientes com recursos limitados.
Toxicidade e Viés: Toxicidade (8 estudos) e Viés (2 estudos) são sub-relatados, mas consistentemente identificados como riscos, principalmente ligados a dados de treinamento (por exemplo, vazamento de privacidade, padrões de código inseguros e desequilíbrios de conjuntos de dados).
Calibração e Equidade: Essas medidas não foram abordadas explicitamente nos estudos secundários revisados.

RQ3: Cenários HELM Relatados

Tarefas: As tarefas mais frequentemente relatadas são Geração/Reparo de Patch (22 estudos), Geração de Código (20), Tradução de Código (9) e Completamento de Código (8).
Linguagens: Uma ampla gama de linguagens é coberta, com Java, Python, C, C++ e JavaScript sendo as mais comuns.
Domínios: Domínios de aplicação são raramente relatados, e tipos de aplicação são mencionados em apenas dois estudos, limitando a validade externa de muitas descobertas.

RQ4: Desafios

A síntese identifica três clusters de desafios dominantes:

Viabilidade Econômica: Altos custos relacionados ao treinamento, inferência e consumo de energia, juntamente com restrições de hardware.
Validade da Avaliação: Benchmarks atuais são frequentemente não representativos do desenvolvimento do mundo real (escopo estreito, linguagem única, vazamento de dados), levando a baixa generalizabilidade.
Integração Socio-técnica: Desafios incluem integração insuficiente com ferramentas existentes (IDEs), falta de controles operacionais, problemas de responsividade e a necessidade de supervisão humana e treinamento de segurança para desenvolvedores.

Outros desafios incluem Limitações de Dados e Contexto (limites de tokens, deslocamentos de domínio), Segurança e Segurança (vulnerabilidades no código gerado) e Riscos Legais/Privacidade.

RQ5: Direções Futuras

As direções futuras mais frequentemente recomendadas são:

Melhoria de Modelos e Treinamento: Especificamente, adaptação consciente de domínio (conjuntos de dados especializados, ajuste fino) e melhoria de eficiência e interpretabilidade.
Melhoria de Benchmark e Avaliação: Chamadas para frameworks de avaliação abrangentes, multi-métricos e multilingues que vão além da correção funcional.
Ensemble e Hibridização: Combinar LLMs com outros modelos ou métodos tradicionais de ES (por exemplo, análise estática) para melhorar desempenho e confiabilidade.
Integração na Prática: Mover de ferramentas autônomas para soluções integradas ao fluxo de trabalho (por exemplo, RAG, plugins de IDE).
Segurança, Privacidade e Confiabilidade: Abordar vulnerabilidades e vazamento de dados.

Significância e Alegações

O artigo afirma fornecer a primeira síntese terciária sistemática de evidências secundárias sobre CGTs baseadas em LLMs. Destaca que o campo está amadurecendo rapidamente, mas é avaliado de forma desigual. Embora os LLMs mostrem promessa, os autores enfatizam que:

Os ganhos de precisão relatados são frequentemente específicos de benchmark e podem não se traduzir em cenários do mundo real.
A robustez é frágil e as restrições de eficiência são pervasivas.
Há uma necessidade crítica de melhorias de modelos conscientes de domínio e frameworks de avaliação holística e padronizada que abordem eficiência, segurança e integração socio-técnica.
O campo está transitando de mapeamento exploratório para síntese rigorosa, mas os riscos de redundância e cobertura limitada de áreas de ES sub-representadas (como teste e gestão) permanecem.

Os autores concluem que, para que as CGTs baseadas em LLMs sejam integradas com sucesso na engenharia de software do mundo real, pesquisas futuras devem abordar a viabilidade econômica, desenvolver benchmarks mais representativos e focar nos aspectos socio-técnicos da integração com humanos no loop.