🤖 AI

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

Questo studio empirico rivela che il codice generato da agenti LLM presenta significative lacune di riproducibilità, con un tasso di esecuzione immediata del 68,3% e un'espansione media di 13,5 volte tra le dipendenze dichiarate e quelle effettivamente necessarie per l'esecuzione.

Autori originali: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

Pubblicato 2026-03-25

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Bhanu Prakash Vangala, Ali Adibifar, Ashish Gehani, Tanu Malik

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

🍳 Il Cuoco AI e la Ricetta Incompleta: Perché il Codice Generato non Funziona (Ancora)

Immagina di avere un cuoco robot super-intelligente (l'Intelligenza Artificiale) a cui chiedi: "Per favore, preparami una cena completa: antipasto, primo, secondo e dolce. Dammi anche la lista della spesa esatta per ricreare questo pasto a casa mia."

Il robot lavora velocemente, ti consegna un piatto delizioso e una lista di ingredienti che sembra perfetta. Ma quando tu, a casa tua, provi a seguire la sua lista per cucinare lo stesso pasto, succede il disastro: manca un ingrediente fondamentale, o peggio, la ricetta è scritta in modo confuso e il piatto non viene mai fuori.

Questo è esattamente ciò che hanno scoperto gli autori di questo studio. Hanno analizzato 300 "piatti" (progetti software) creati da tre dei migliori cuochi AI del mondo (Claude, Gemini e OpenAI Codex) per vedere se le loro ricette fossero davvero riproducibili.

Ecco cosa hanno scoperto, spiegato con metafore semplici:

1. Il Problema della "Lista della Spesa" (Dipendenze)

Quando un programmatore umano scrive un programma, deve dire al computer: "Ho bisogno di questa libreria per fare i calcoli e di quell'altra per salvare i dati". Queste sono le dipendenze.
L'AI è bravissima a scrivere il codice (la ricetta), ma è terribile nel fare la lista della spesa completa.

La Scoperta: L'AI ti dice: "Ti servono solo 3 ingredienti". Ma quando provi a cucinare, ti accorgi che ne servono 37!
L'Analogia: È come se il cuoco ti dicesse: "Per fare la pasta al pomodoro ti servono solo pomodori e pasta". Ma quando arrivi a casa, scopri che per farli cuocere ti servono anche acqua, sale, olio, pentole, fornello e un coltello. L'AI ha dimenticato di elencare tutto ciò che serve davvero per far funzionare il tutto.
Il Numero Shock: In media, per ogni ingrediente che l'AI dichiara, ne servono 13,5 reali. È un'esplosione di ingredienti nascosti!

2. Non Tutti i Cuochi sono Uguali (Le Specializzazioni)

Lo studio ha scoperto che i tre cuochi AI hanno punti di forza e debolezze molto diversi, a seconda del "tipo di cucina" (linguaggio di programmazione):

Gemini: È il Re della Pasta (Python). Se gli chiedi di cucinare piatti italiani (codice Python), è perfetto: il 100% delle volte funziona. Ma se gli chiedi di cucinare un arrosto complesso (Java), fallisce quasi sempre.
Claude: È lo Specialista dei Pranzi di Stato (Java). Riesce a gestire i piatti complessi e aziendali molto meglio degli altri, anche se a volte sbaglia con la pasta semplice.
Codex: È un po' disordinato. Fa bene la pasta, ma spesso dimentica gli ingredienti o scrive la ricetta in modo illeggibile.

La lezione: Non puoi fidarti ciecamente di un solo AI per tutto. Devi scegliere il cuoco giusto per il tipo di piatto che vuoi preparare.

3. Il Problema è anche la Ricetta, non solo gli Ingredienti

Il titolo dello studio parla di "dipendenze mancanti", ma la verità è ancora più strana.
Molti piatti falliscono non perché mancano gli ingredienti, ma perché la ricetta è scritta male.

L'Analogia: Immagina che il robot scriva: "Metti il sale nell'acqua fredda" (errore di logica) o "Taglia la cipolla a metà, ma non specificare come" (errore di sintassi).
I Numeri: Solo il 10% dei fallimenti è dovuto a ingredienti mancanti. Il 52% è dovuto a errori nella scrittura della ricetta stessa (codice sbagliato, percorsi di file errati, variabili non inizializzate).
Il Risultato: Il 31,7% dei progetti generati dall'AI non funziona subito. Devi metterci le mani sopra, correggere gli errori e aggiungere ingredienti che l'AI ha dimenticato.

4. Il Costo Nascosto (Il Tempo Perso)

Cosa succede quando un'azienda usa questi cuochi AI?
Pensano di risparmiare tempo, ma in realtà lo perdono.

Ogni volta che un progetto non funziona, un programmatore umano deve fermarsi, capire cosa è andato storto e ripararlo.
Lo studio ha calcolato che ci vogliono in media 15 minuti per sistemare un progetto fallito.
Se un'azienda genera 100 progetti, circa 31 falliranno. Questo significa 8 ore di lavoro perse solo a riparare errori che l'AI avrebbe dovuto evitare. È come pagare un cuoco per farti mangiare la pizza, ma poi doverla rifare tu stesso perché si è bruciata.

In Sintesi: Cosa Dobbiamo Imparare?

L'Intelligenza Artificiale è diventata bravissima a scrivere codice (come scrivere una storia), ma non è ancora brava a garantire che quel codice funzioni nel mondo reale (come assicurarsi che la storia abbia senso e sia pubblicabile).

Non è magia: Il codice generato dall'AI sembra completo, ma spesso è un "iceberg": vedi solo la punta (3 ingredienti), ma sotto l'acqua c'è una montagna di cose nascoste (37 ingredienti).
La Reproducibilità è la chiave: Se non puoi far funzionare il codice di qualcun altro (o dell'AI) con la sola lista che ti ha dato, allora quel codice non è affidabile.
Il Futuro: Per migliorare, l'AI non deve solo imparare a scrivere codice, ma deve imparare a testarlo in ambienti puliti, a scoprire da sola gli ingredienti mancanti e a correggere i propri errori prima di consegnarti il lavoro.

In conclusione: L'AI è un assistente molto veloce, ma al momento non è un partner affidabile. Se vuoi usare i suoi progetti, devi essere pronto a fare il "controllore di qualità" e a spendere tempo a sistemare le sue dimenticanze. La promessa di un'automazione perfetta è ancora lontana.

1. Il Problema: La Crisi della Riproducibilità nel Codice Generato da AI

Il documento affronta una questione fondamentale: sebbene i Modelli Linguistici su Grande Scala (LLM) promettano di accelerare lo sviluppo software, il codice da essi generato soffre di una grave mancanza di riproducibilità.
Mentre la comunità scientifica affronta da tempo una crisi di riproducibilità (dovuta a dipendenze mancanti o ambienti non specificati), l'uso di agenti di coding basati su LLM (come Claude Code, OpenAI Codex e Gemini) rischia di amplificare questo problema.
Il problema centrale non è solo la correttezza funzionale del codice, ma la sua eseguibilità in un ambiente pulito utilizzando esclusivamente le dipendenze e le istruzioni fornite dall'AI. Lo studio evidenzia che il codice generato spesso sembra completo, ma fallisce l'esecuzione a causa di:

Dichiarazioni di dipendenze incomplete.
Errori di generazione del codice (sintassi, percorsi file, variabili non inizializzate).
Complessità nascoste delle dipendenze transitiche non catturate dal modello.

2. Metodologia

Gli autori hanno condotto uno studio empirico sistematico su larga scala per quantificare l'affidabilità esecutiva del codice generato.

Agenti Valutati: Tre agenti LLM all'avanguardia:
- Claude Code Agent (Opus 4.1)
- OpenAI Codex Agent (0.52.0)
- Gemini Code Agent (2.5 Pro)
Dataset: 300 progetti completi generati da 100 prompt standardizzati, distribuiti tra tre linguaggi di programmazione:
- Python (40 progetti per agente)
- JavaScript (35 progetti per agente)
- Java (25 progetti per agente)
Ambiente di Test: Ambienti "puliti" su istanze AWS EC2 (Ubuntu 22.04), contenenti solo i pacchetti di sistema predefiniti. Nessun pacchetto aggiuntivo era installato prima della prova.
Metrica Principale: Affidabilità Esecutiva (Executable Reliability): La frazione di progetti che vengono eseguiti con successo senza alcuna intervento manuale, utilizzando solo le dipendenze specificate dall'LLM.
Framework a Tre Livelli di Dipendenze: Per analizzare le lacune, gli autori hanno introdotto una tassonomia delle dipendenze:
1. Dipendenze Dichiarate ( $D_c$ ): Quelle elencate esplicitamente dall'LLM (es. requirements.txt).
2. Dipendenze Funzionanti ( $D_w$ ): Le dipendenze dichiarate più quelle mancanti scoperte durante il debug iterativo.
3. Dipendenze di Runtime ( $D_r$ ): L'intero albero delle dipendenze (incluso il closure transitivo) effettivamente caricato durante l'esecuzione.

3. Risultati Chiave

A. Tasso di Riproducibilità Generale

Solo il 68,3% dei progetti (205 su 300) è stato eseguito con successo "out-of-the-box". Il restante 31,7% ha fallito immediatamente, richiedendo un intervento manuale (debug, aggiunta di pacchetti, correzione di bug).

Tempo di Debug: Ogni progetto fallito ha richiesto in media 15 minuti di intervento manuale per essere risolto.

B. Variazioni per Linguaggio

La riproducibilità varia drasticamente in base all'ecosistema del linguaggio:

Python: 89,2% di successo (gestione delle dipendenze più semplice e lineare).
JavaScript: 61,9% di successo.
Java: 44,0% di successo (gestione complessa delle dipendenze tramite Maven, conflitti di versione, scope multipli).

C. Agenti Specializzati

Ogni modello mostra specializzazioni nascoste non documentate:

Gemini: Eccelle in Python (100% di successo), ma fallisce drasticamente in Java (28%).
Claude: Mostra le prestazioni più bilanciate, con un'eccezionale capacità in Java (80%), dove gli altri modelli falliscono.
Codex: Forte in Python (87,5%), ma con prestazioni inferiori in Java (24%).

D. Il "Gap" delle Dipendenze e l'Esplosione del Runtime

Uno dei risultati più significativi riguarda la discrepanza tra ciò che l'LLM dichiara e ciò che è realmente necessario:

Gap di Completezza: Il 13% dei progetti falliva inizialmente a causa di dipendenze mancanti dichiarate (es. mancata inclusione di bcrypt o lxml).
Moltiplicatore di Runtime: Anche quando il codice funziona, c'è un'enorme espansione delle dipendenze.
- In media, un progetto che dichiara 3 pacchetti ne richiede 37 in runtime.
- Moltiplicatore medio: 13,5x.
- Java: Il moltiplicatore è più alto (9,5x o 18,4x a seconda della misurazione), dovuto alla complessità delle dipendenze transitiche di Maven.
- Python: Moltiplicatore di circa 12,3x.
- JavaScript: Sorprendentemente basso (1,0x), suggerendo che gli LLM tendono a sovrastimare le dipendenze dirette o che l'analisi npm cattura solo quelle dirette.

D. Tipologia degli Errori

Contrariamente all'ipotesi iniziale focalizzata sulle dipendenze, l'analisi degli errori ha rivelato che:

52,6% dei fallimenti è dovuto a Errori di Codice (sintassi errata, percorsi file sbagliati, strutture logiche difettose).
Solo il 10,5% dei fallimenti è dovuto a Dipendenze Mancanti.
Il 16,8% dei fallimenti è dovuto a codice così malformato da non essere nemmeno processabile ("Not Processed").

4. Contributi Principali

Definizione di "Affidabilità Esecutiva": Sposta il focus dai benchmark funzionali (es. HumanEval, che assumono ambienti già pronti) alla capacità reale di un progetto di essere eseguito in un ambiente pulito.
Framework a Tre Strati: Introduce una metodologia rigorosa per distinguere tra dipendenze dichiarate, lavorative e di runtime, permettendo di quantificare la complessità nascosta.
Mappatura delle Specializzazioni degli Agenti: Dimostra che le prestazioni degli LLM non sono uniformi ma dipendono fortemente dal linguaggio di programmazione e dal dominio di addestramento (es. Gemini per data science/Python, Claude per enterprise/Java).
Quantificazione dei Costi Nascosti: Evidenzia che il 31,7% di fallimenti e il tempo di debug associato rappresentano un "costo nascosto" massiccio per lo sviluppo software assistito da AI.

5. Significato e Implicazioni

Lo studio smonta la narrazione ottimistica secondo cui gli agenti AI sono pronti per sostituire i sviluppatori umani in modo autonomo.

Impatto Scientifico: Il codice generato da AI minaccia la validità della ricerca scientifica se non è riproducibile. I ricercatori devono ora pubblicare non solo il codice, ma l'intero closure delle dipendenze (inclusi i 37+ pacchetti nascosti) per garantire la riproducibilità.
Impatto Industriale: L'adozione di questi strumenti introduce un "debito tecnico nascosto". Le organizzazioni non possono affidarsi a benchmark generici ma devono testare gli agenti specifici contro il proprio stack tecnologico.
Futuro degli LLM: Per risolvere il problema, i modelli non devono solo imparare a generare codice sintatticamente corretto, ma devono essere addestrati su progetti completi con specifiche di dipendenze reali (es. file package-lock.json funzionanti) e, idealmente, devono essere in grado di testare iterativamente il proprio codice in ambienti puliti prima di proporlo all'utente.

In conclusione, il paper afferma che, allo stato attuale, gli agenti AI generano codice che "sembra" completo ma non è riproducibile. La sfida non è solo scrivere codice che funziona sulla macchina dello sviluppatore, ma generare codice che altri possano eseguire affidabilmente senza un intervento manuale estensivo.