Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics

Este estudo identifica uma desconexão entre a pesquisa acadêmica, as prioridades da indústria e o comportamento observado dos modelos de linguagem, revelando que a otimização de características de qualidade não funcional em código gerado por IA é instável e exige a integração de mecanismos de garantia de qualidade para evitar o acúmulo de dívida técnica.

O essencial

Imagine que você contratou um estagiário superinteligente, mas inexperiente, chamado "IA", para escrever o código de um novo aplicativo para sua empresa.

Este estagiário é incrível: ele lê suas instruções em linguagem natural e escreve o código muito rápido. Se você pedir para ele criar uma calculadora, ele faz. Se pedir para ele criar um site, ele faz. Ele parece um gênio.

Mas aqui está o problema: O estagiário só se preocupa em fazer o código funcionar (passar nos testes). Ele não se importa se o código é seguro, se é fácil de ler no futuro ou se vai deixar o computador lento.

Este artigo de pesquisa é como uma auditoria que descobriu exatamente o que acontece quando deixamos esse estagiário trabalhar sozinho. Os pesquisadores da Universidade de Linköping (Suécia) olharam para três coisas principais: o que a academia estuda, o que os profissionais da indústria se preocupam e o que realmente acontece quando a IA gera código no mundo real.

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Estagiário e a "Casa de Papel" (O Problema)

A maioria das pesquisas atuais foca apenas em saber se o código da IA funciona. É como se você testasse se uma casa de papel aguenta o vento por 5 segundos. Se aguenta, a casa é considerada "boa".

Mas a qualidade real de um software não é só sobre funcionar agora. É sobre:

• Segurança: A casa tem portas trancadas ou qualquer ladrão pode entrar?
• Manutenção: Se você quiser pintar a parede daqui a 5 anos, consegue achar onde está a tinta, ou o código é um emaranhado de fios?
• Desempenho: A casa é tão pesada que o chão começa a rachar?

O estudo descobriu que a academia foca muito em "segurança" (trancar a porta), mas os profissionais da indústria (os donos da casa) estão mais preocupados com a manutenção. Eles dizem: "Se esse código for difícil de ler, vamos acumular uma 'dívida técnica' gigante. Daqui a dois anos, ninguém vai conseguir mexer nisso sem quebrar tudo."

2. A Tentativa de "Ajuste Fino" (O Experimento)

Os pesquisadores decidiram testar se podiam "ensinar" o estagiário a fazer um trabalho melhor. Eles usaram uma técnica chamada Prompting (dar instruções mais detalhadas).

• O Cenário: Eles pegaram 300 problemas reais de software (como consertar um bug em um site famoso) e pediram para três IAs diferentes (Claude, GPT-4o e DeepSeek) resolverem.
• A Tática: Depois que a IA gerou o código, os pesquisadores disseram: "Ei, esse código funciona, mas está muito bagunçado. Tente de novo, mas faça ele ser mais seguro" ou "Faça ele ser mais rápido".

O Resultado Surpreendente (e Assustador):
Funcionou? Às vezes, sim. Mas quase sempre custou caro.

• O Efeito Balanço: Quando você pede para a IA focar em segurança, ela às vezes faz o código funcionar menos. É como pedir para um cozinheiro fazer um prato mais seguro (menos veneno), e ele acaba colocando menos sal e o prato fica sem graça (não funciona).
• O Efeito Espelho: Quando você pede para focar em velocidade, o código pode ficar mais rápido, mas consumir mais memória (como um carro de corrida que é rápido, mas bebe muita gasolina).
• A Instabilidade: Não há garantia. Às vezes, a IA melhora um aspecto e piora outro. Às vezes, ela piora tudo.

3. A Metáfora do "Conserto de Carro"

Imagine que você tem um carro velho (o software antigo) e um mecânico robô (a IA).

• O robô conserta o motor perfeitamente (o código funciona).
• Mas, para consertar o motor, ele usou peças de outro carro que não combinam, deixou parafusos soltos e pintou tudo de uma cor que não existe na fábrica.
• O carro anda? Sim.
• É seguro? Talvez não.
• É fácil de consertar no futuro? Não, porque ninguém sabe como ele foi montado.

O estudo mostrou que, se você apenas pedir para o robô "consertar o motor" sem supervisionar a qualidade, você está criando um carro que funciona hoje, mas que será um pesadelo amanhã.

4. O Que os Pesquisadores Concluíram?

A mensagem principal é: Não confie cegamente no código gerado por IA apenas porque ele "passou no teste".

• Desalinhamento: A academia estuda o que é fácil de medir (segurança, velocidade), mas os engenheiros do mundo real sofrem com o que é difícil de medir (legibilidade, facilidade de manutenção).
• O Risco: Usar código de IA sem verificação é como acumular dívida. Você ganha tempo hoje, mas paga juros altos no futuro quando tiver que refazer todo o trabalho.
• A Solução: Precisamos integrar ferramentas de verificação automática durante o processo de geração. Não basta pedir para a IA escrever; precisamos pedir para ela escrever, verificar, corrigir e verificar de novo, garantindo que o código não só funcione, mas seja bom.

Resumo em uma frase:

A IA é um estagiário brilhante que escreve código rápido, mas que precisa de um supervisor humano (ou ferramentas automáticas) para garantir que o código não seja apenas funcional, mas também seguro, limpo e sustentável para o futuro. Se não fizermos isso, estamos construindo arranha-céus de areia.

Resumo técnico

Título: Garantia de Qualidade de Código Gerado por LLMs: Abordando Características de Qualidade Não Funcionais

1. Problema e Motivação

A integração de Modelos de Linguagem Grandes (LLMs) para geração de código (como GitHub Copilot) revolucionou o fluxo de trabalho de engenharia de software. No entanto, as avaliações atuais focam predominantemente na correção funcional (o código faz o que deve fazer?), negligenciando as Características de Qualidade Não Funcionais (NFQCs).

O problema central identificado é que o código gerado por LLMs pode ser funcionalmente correto, mas apresentar falhas críticas em aspectos como segurança, manutenibilidade e eficiência de desempenho. Existe uma lacuna entre:

1. O que a pesquisa acadêmica avalia (frequentemente focado em segurança e desempenho isolados).
2. O que os profissionais da indústria priorizam (manutenibilidade e legibilidade a longo prazo).
3. O comportamento real dos modelos ao otimizar um atributo de qualidade, que pode degradar outros.

O estudo visa preencher essa lacuna, utilizando o modelo de qualidade ISO/IEC 25010 como referência unificada para investigar como as NFQCs são conceituadas, priorizadas e manifestadas no código gerado.

2. Metodologia

O estudo adota uma abordagem de métodos mistos, combinando três elementos complementares para fornecer uma visão integrada:

A. Revisão Sistemática de Literatura

• Escopo: Análise de 109 artigos publicados entre 2022 e 2025.
• Critérios: Foco em LLMs para geração de código e avaliação de atributos de qualidade além da correção funcional.
• Mapeamento: Os atributos de qualidade foram mapeados para o modelo ISO/IEC 25010 para padronizar a terminologia.
• Objetivo: Identificar tendências, lacunas de pesquisa e métodos de avaliação existentes.

B. Workshops com a Indústria

• Participantes: 15 especialistas de 7 organizações diferentes (membros do Software Center da Suécia), com experiência de 3 a 13+ anos.
• Formato: Dois workshops interativos (online) discutindo tendências da literatura e experiências práticas.
• Objetivo: Capturar as expectativas, prioridades e pontos de dor dos profissionais ao integrar código gerado em sistemas reais.

C. Estudo Empírico (Avaliação Experimental)

• Dataset: Utilização do SWE-bench Lite (300 pares de problemas/pull requests de repositórios Python reais, principalmente Django e SymPy).
• Modelos Testados: Três LLMs distintos:
  • Claude 4 Sonnet (Modelo fechado de médio porte).
  • DeepSeek-Reasoner (Modelo aberto focado em raciocínio).
  • GPT-4o (Modelo aberto da OpenAI).
• Pipeline Experimental:
  1. Avaliação Baseline: Geração de patches para resolver problemas e avaliação de correção funcional, tempo de execução, uso de memória e análise estática (CodeQL) para segurança e manutenibilidade.
  2. Design de Prompt Otimizado: Criação de prompts específicos para otimizar uma NFQC (ex: "melhore a segurança" ou "reduza o tempo de execução") com base em feedback estático (CodeQL).
  3. Regeneração e Análise de Trade-offs: Re-geração dos patches com os novos prompts e comparação dos resultados para identificar melhorias e compensações (trade-offs) entre as qualidades.
• Ferramentas: CodeQL (análise estática), Docker (isolamento de ambiente), SWE-agent (framework de geração).

3. Principais Contribuições

1. Mapeamento de Lacunas: Identificação de que a pesquisa acadêmica prioriza segurança e eficiência, enquanto a indústria prioriza manutenibilidade e legibilidade, alertando para o risco de acumulação de dívida técnica.
2. Análise de Trade-offs: Demonstração empírica de que otimizar uma única NFQC via prompting é instável e frequentemente leva à degradação de outras qualidades ou da própria correção funcional.
3. Avaliação em Nível de Repositório: Diferente de benchmarks sintéticos (como HumanEval), o estudo avalia mudanças de código em nível de repositório real, capturando interações complexas de dependências.
4. Descoberta de "Cegueira" de Qualidade: Evidência de que os LLMs não possuem uma função de custo intrínseca para qualidade de código; eles priorizam "passar nos testes" em detrimento de boas práticas de engenharia.

4. Resultados Chave

Da Revisão de Literatura

• Tendência: Aumento explosivo de estudos sobre NFQCs entre 2022-2024.
• Foco Desbalanceado: Segurança (33,6%), Eficiência de Desempenho (23,3%) e Manutenibilidade (17,2%) são os mais estudados. Atributos como confiabilidade e modularidade são negligenciados.
• Limitação Metodológica: A maioria das avaliações depende de ferramentas estáticas e métricas isoladas, sem um framework quantitativo unificado para analisar múltiplas qualidades simultaneamente.

Dos Workshops (Indústria)

• Prioridade: Os profissionais enfatizam a manutenibilidade e a legibilidade como críticas para a sustentabilidade de longo prazo de sistemas grandes.
• Preocupação: O código gerado pode acelerar a dívida técnica, especialmente em bases de código legadas complexas.
• Desafio: Falta de ferramentas confiáveis para medir manutenibilidade e legibilidade em escala.

Do Estudo Empírico

• Correção Funcional: Os LLMs têm taxas de resolução significativamente inferiores às patches de referência humanas (Gold Patches). O GPT-4o teve a maior taxa de aplicação (PSA), mas a menor taxa de resolução.
• Qualidade Baseline:
  • O código gerado gatilhou muito mais regras de manutenibilidade no CodeQL do que o código humano (ex: GPT-4o gerou 423 recomendações vs. 30 do código humano).
  • Problema recorrente: Imports cíclicos (cyclic-import), indicando falta de compreensão da estrutura global do projeto.
  • Segurança: O código gerado introduziu mais vulnerabilidades (ex: armazenamento de dados sensíveis em texto claro).
• Instabilidade da Otimização via Prompt:
  • Tentar otimizar uma qualidade específica (ex: segurança) frequentemente reduziu a correção funcional (a taxa de resolução caiu drasticamente, chegando a 12% para o GPT-4o sob prompt de segurança).
  • Trade-offs Observados: Melhorar o tempo de execução muitas vezes aumentou o uso de memória, e vice-versa.
  • Degradação: Em alguns casos, a otimização piorou a métrica que se pretendia melhorar.
• Comportamento dos Modelos: Não há um modelo "superior" universal. O Claude-Sonnet-4 performou melhor em manutenibilidade e segurança, enquanto o DeepSeek-Reasoner foi superior em otimização de memória.

5. Significado e Conclusão

O estudo conclui que a geração de código por LLMs, no estado atual, não deve ser tratada como um processo "pronto para uso" em pipelines de automação sem mecanismos de garantia de qualidade robustos.

• Risco de Dívida Técnica: Aplicar patches gerados por LLMs sem validação rigorosa de NFQCs introduz e amplifica dívida técnica estrutural.
• Necessidade de Alinhamento: Há um desalinhamento crítico entre o foco acadêmico (segurança/desempenho) e as necessidades industriais (manutenibilidade).
• Futuro: A pesquisa futura deve focar em integrar mecanismos de verificação (análise estática, testes dinâmicos) diretamente no pipeline de geração. O objetivo deve evoluir de "passar nos testes" para "passar com qualidade", onde as NFQCs são monitoradas em tempo real e usadas como feedback estruturado para refatoração antes da implantação.

Este trabalho serve como um alerta para a comunidade de engenharia de software: a funcionalidade é apenas o primeiro passo; a qualidade não funcional é o gargalo atual para a adoção segura e sustentável de LLMs em sistemas críticos.