🤖 AI

AI-Generated Code Is Not Reproducible (Yet): An Empirical Study of Dependency Gaps in LLM-Based Coding Agents

Este estudo empírico revela que o código gerado por agentes de LLMs (Claude Code, OpenAI Codex e Gemini) frequentemente falha na reprodutibilidade em ambientes limpos, com apenas 68,3% dos projetos executando corretamente e uma discrepância média de 13,5 vezes entre as dependências declaradas e as reais, variando significativamente conforme a linguagem de programação.

Autores originais: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

Publicado 2026-03-25

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

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 que você pediu a um chef de cozinha de inteligência artificial (IA) para preparar um prato complexo, como um "Bolo de Chocolate com Frutas".

O chef entrega a receita pronta: lista os ingredientes principais (farinha, ovos, chocolate) e diz exatamente como misturá-los. Parece perfeito, certo?

Mas, quando você tenta fazer o bolo na sua cozinha, usando apenas o que o chef escreveu, o bolo não cresce. A massa fica dura ou queima. Por quê?

O chef esqueceu de dizer que você precisa de fermento (um ingrediente que ele usou, mas não listou).
O chef esqueceu de mencionar que o chocolate que ele usou já vem com leite em pó e cacau embutidos, e que você precisa de uma batedeira elétrica específica para funcionar.
Em alguns casos, o próprio texto da receita estava escrito de um jeito que você não conseguia entender (erros de sintaxe).

Este é exatamente o problema que o estudo "AI-Generated Code Is Not Reproducible" descobriu.

Os pesquisadores pegaram três "chefs" de IA famosos (Claude, Gemini e o Codex da OpenAI) e pediram para eles criarem 300 projetos de software completos (como sites, aplicativos e ferramentas de dados). Depois, eles tentaram rodar esses projetos em uma "cozinha limpa" (um computador novo, sem nada instalado), usando apenas o que a IA disse que era necessário.

Aqui está o que eles descobriram, traduzido para uma linguagem simples:

1. A Ilusão da "Prontidão" (O Bolo que Não Sobe)

A grande promessa da IA é: "Peça e eu faço, pronto para usar".

A Realidade: Apenas 68% dos projetos funcionaram de primeira, sem que ninguém precisasse mexer em nada.
O Problema: Em quase 32% dos casos, o código falhou imediatamente. Era como se o chef tivesse entregue a receita, mas esquecido metade dos ingredientes ou escrito as instruções de forma confusa.

2. O Efeito "Iceberg" dos Ingredientes (Dependências Ocultas)

Este é o ponto mais curioso. Quando a IA diz: "Você precisa apenas de 3 pacotes para rodar este programa", ela está mentindo (sem querer).

A Analogia: É como se a IA dissesse: "Para fazer o bolo, você só precisa de farinha". Mas, na verdade, para usar essa farinha, você precisa de um saco de plástico, de um caminhão que trouxe o trigo, de um forno que usa gás específico, etc.
O Dado: Em média, para cada 1 pacote que a IA diz que você precisa, na verdade são instalados 13,5 pacotes no seu computador!
- Se você pede um projeto em Java, a IA diz que precisa de 2 coisas, mas o computador instala 20 coisas. É um efeito cascata gigante.
- Em Python, é um pouco melhor (cerca de 3 para 37), mas ainda é um caos oculto.

3. Nem Todos os "Chefs" São Iguais

O estudo mostrou que cada IA tem seus "talentos secretos" e suas fraquezas, dependendo da linguagem de programação:

Gemini: É um gênio em Python (100% de sucesso, o bolo sempre sobe), mas é péssimo em Java (só 28% de sucesso). É como se ele fosse um mestre em confeitaria, mas não soubesse cozinhar carnes.
Claude: É o mais equilibrado. Ele é muito bom em Java (onde os outros falham), mas um pouco menos perfeito em Python.
Codex: É forte em Python, mas comete muitos erros de lógica no código em si.

4. O Verdadeiro Vilão não é só o Ingrediente Faltando

Muitas pessoas acham que o problema é apenas a IA esquecer de listar um pacote (como esquecer o fermento).

A Descoberta: Na verdade, apenas 10% das falhas foram por falta de ingredientes.
O Verdadeiro Problema: 52% das falhas foram porque a IA escreveu o código errado! Ela misturou os ingredientes de um jeito que não faz sentido (erros de sintaxe, caminhos de arquivos errados, variáveis que não existem). É como se o chef escrevesse "adicione 2 xícaras de sal" em vez de "açúcar".

5. Por que isso importa para você?

Se você é um cientista, um desenvolvedor ou um estudante:

O Custo Oculto: Quando a IA entrega um código que não funciona, você perde tempo (em média 15 minutos por projeto) tentando descobrir o que deu errado. Isso transforma uma ferramenta que deveria "economizar tempo" em uma que "gasta tempo".
A Ciência em Risco: Se um pesquisador usa uma IA para criar um experimento e o código não roda na máquina do colega, a ciência não pode ser verificada. A descoberta fica presa na "caixa preta" da IA.

Conclusão: A Lição do Dia

A IA hoje é como um assistente de digitação superinteligente, mas ainda não é um engenheiro de software completo. Ela escreve o código, mas não entende o "ecossistema" inteiro necessário para que ele funcione na vida real.

Para que a IA seja realmente útil, ela precisa aprender a não apenas escrever a receita, mas também a listar todos os ingredientes ocultos, garantir que a receita faça sentido lógico e testar se o bolo realmente cresce antes de entregar para você.

Resumo em uma frase: A IA está criando códigos que parecem completos, mas na prática, são como quebra-cabeças com peças faltando e instruções confusas, exigindo que humanos façam o trabalho pesado de consertá-los.

Título do Estudo

Código Gerado por IA Não é Reprodutível (Ainda): Um Estudo Empírico de Lacunas de Dependência em Agentes de Codificação Baseados em LLM

1. O Problema

A ascensão dos Modelos de Linguagem de Grande Escala (LLMs) como agentes de codificação promete acelerar o desenvolvimento de software. No entanto, a reprodutibilidade do código gerado por essas IAs permanece uma questão pouco explorada.

A Crise de Reprodutibilidade: A comunidade de pesquisa computacional já enfrenta uma crise onde grande parte do código publicado não pode ser reproduzido devido a dependências faltantes ou especificações de ambiente incompletas.
A Lacuna Atual: Ferramentas como Claude Code, OpenAI Codex e Gemini Code Assist geram projetos completos (múltiplos arquivos, configurações, dependências), mas frequentemente falham ao especificar todas as dependências necessárias para que o código seja executado em um ambiente limpo.
Definição de Reprodutibilidade no Contexto: Para este estudo, um projeto é considerado reprodutível se um desenvolvedor puder pegar os arquivos gerados pela IA, configurar um ambiente limpo (apenas com pacotes do SO), instalar as dependências listadas pela IA e executar o código com sucesso, sem intervenção manual, correção de bugs ou adição de pacotes não declarados.

2. Metodologia

Os autores conduziram um estudo sistemático avaliando a confiabilidade executável de projetos gerados por três agentes de LLM de última geração.

Agentes Avaliados:
1. Claude Code Agent (Opus 4.1)
2. OpenAI Codex Agent (0.52.0)
3. Gemini Code Agent (2.5 Pro)
Dataset: 300 projetos completos gerados a partir de 100 prompts padronizados, distribuídos entre três linguagens:
- Python (40 prompts)
- JavaScript (35 prompts)
- Java (25 prompts)
Ambiente de Teste: Instâncias AWS EC2 (Ubuntu 22.04) rigorosamente resetadas entre testes, contendo apenas 91 pacotes padrão do sistema. Nenhum outro pacote foi pré-instalado.
Métrica Principal: Confiabilidade Executável (Executable Reliability) – a fração de prompts onde o código executou com sucesso usando exclusivamente as dependências e instruções fornecidas pela IA.
Framework de Análise de Dependências em Três Camadas:
1. Dependências Reivindicadas ( $D_c$ ): O que a IA lista explicitamente (ex: requirements.txt).
2. Dependências Funcionais ( $D_w$ ): O que é necessário após depuração (inclui dependências reclamadas + as faltantes descobertas por erro de importação).
3. Dependências de Runtime ( $D_r$ ): O conjunto completo de dependências transitivas carregadas durante a execução (o grafo total de dependências).
Protocolo de Avaliação:
1. Tentativa de execução imediata com apenas o que a IA forneceu.
2. Se falhar, aplica-se um protocolo iterativo de resolução (Algoritmo 1) para identificar a causa raiz (bugs de código, dependências faltantes, erros de ambiente), mas apenas os sucessos "out-of-the-box" contam como reprodutíveis.

3. Principais Contribuições

Definição de Confiabilidade Executável: Introduz uma métrica direta para medir a reprodutibilidade, focando na capacidade de execução em ambientes limpos sem conhecimento prévio adicional.
Framework de Três Camadas: Propõe uma metodologia para quantificar a complexidade oculta das dependências, distinguindo entre o que é declarado, o que é necessário para funcionar e o que é realmente carregado em runtime.
Análise de Especialização Oculta: Revela que diferentes LLMs possuem especializações distintas por linguagem de programação, contradizendo a noção de desempenho uniforme.
Diagnóstico da Crise: Demonstra que a maioria das falhas de reprodutibilidade não se deve apenas a dependências faltantes, mas a erros fundamentais de geração de código (sintaxe, lógica, estrutura).

4. Resultados Chave

A. Taxa Geral de Reprodutibilidade

Apenas 68,3% dos 300 projetos executaram com sucesso sem nenhuma intervenção manual.
31,7% falharam imediatamente.
Tempo de Depuração: Projetos falhos exigiram, em média, 15 minutos de depuração manual para serem corrigidos.

B. Desempenho por Linguagem

Houve uma variação drástica baseada no ecossistema da linguagem:

Python: 89,2% de sucesso (Ecossistema mais simples, requirements.txt plano).
JavaScript: 61,9% de sucesso (Complexidade intermediária, resolução automática do npm ajuda, mas dependências aninhadas causam problemas).
Java: 44,0% de sucesso (Maior complexidade devido a configurações XML no pom.xml, escopos múltiplos e resolução de conflitos de versão).

C. Especialização dos Agentes (Matriz de Desempenho)

Gemini: Perfeito em Python (100%), mas péssimo em Java (28%).
Claude: Mais equilibrado, com destaque para Java (80%), onde outros agentes falharam.
Codex: Forte em Python (87,5%), mas fraco em Java (24%).
Conclusão: Os agentes não são generalistas uniformes; suas capacidades dependem dos dados de treinamento específicos de cada domínio.

D. Lacuna de Dependências e "Explosão" de Runtime

Lacuna de Completude: Em 87% dos casos, as dependências declaradas estavam corretas. No entanto, nos 13% restantes, faltavam 1 a 3 pacotes.
Causa Real das Falhas: Apenas 10,5% das falhas foram causadas por dependências faltantes (ImportError). A grande maioria (52,6%) foi causada por erros de geração de código (sintaxe inválida, caminhos de arquivo incorretos, variáveis não inicializadas, erros de lógica).
Multiplicador de Runtime: Existe uma discrepância massiva entre o que a IA declara e o que é realmente necessário:
- Média Geral: 13,5x (Um projeto que declara 3 pacotes, na verdade carrega ~40 em runtime).
- Java: 9,5x a 18,4x (Devido à complexidade transitiva do Maven).
- Python: ~12,3x (Exemplo: um projeto de ML declarando 3 pacotes acabou carregando 52 pacotes no total).
- JavaScript: Surpreendentemente 1,0x (Sugere que os LLMs tendem a superespecificar dependências diretas ou a análise do npm capturou apenas dependências diretas).

5. Significado e Implicações

Custo Oculto do Desenvolvimento: A promessa de aceleração da IA é mitigada pelo custo de depuração. Para cada 100 projetos gerados, cerca de 32 falharão, exigindo aproximadamente 8 horas de trabalho humano para corrigir (31,7 projetos × 15 min).
Risco Científico: Na pesquisa científica, o uso de IAs para gerar scripts de análise sem garantir a reprodutibilidade completa (incluindo o grafo de dependências transitivas) pode invalidar descobertas e impedir a revisão por pares.
Débito Técnico Oculto: O código gerado cria um débito técnico significativo, pois os desenvolvedores herdam projetos que funcionam localmente (com dependências ocultas) mas falham em produção ou em ambientes limpos.
Mudança de Paradigma Necessária:
- Para Benchmarks: Métricas atuais (como HumanEval) testam apenas a correção funcional, ignorando a reprodutibilidade. Novos benchmarks devem exigir "Confiabilidade Executável".
- Para Modelos de IA: Os LLMs precisam ser treinados não apenas em fragmentos de código, mas em projetos completos com cadeias de dependências totais e arquivos de bloqueio (package-lock, requirements.lock).
- Para Desenvolvedores: A seleção de um agente de IA deve ser baseada no stack tecnológico específico (ex: usar Claude para Java, Gemini para Python), e não em benchmarks genéricos.

Conclusão

O estudo conclui que, embora os LLMs sejam capazes de gerar código sintaticamente plausível, eles ainda falham em capturar o contexto de execução completo necessário para a reprodutibilidade. A barreira principal não é apenas a falta de declaração de pacotes, mas a geração de código logicamente incorreto e a incapacidade de prever a complexidade transitiva das dependências. Até que os sistemas de IA aprendam a especificar e testar ambientes de execução completos, eles permanecerão como ferramentas de autocompletar sofisticadas, e não como parceiros de desenvolvimento totalmente autônomos.