🤖 AI

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

Questa revisione terziaria sintetizza 30 studi secondari sulla generazione di codice basata su modelli linguistici di grandi dimensioni per rivelare un campo in rapida crescita ma valutato in modo disomogeneo, in cui le elevate prestazioni sui benchmark contrastano con sfide significative nella generalizzazione nel mondo reale, nella robustezza, nell'efficienza e nell'integrazione socio-tecnica.

Autori originali: Muslim Chochlov, Michael English, Jim Buckley

Pubblicato 2026-05-26

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Muslim Chochlov, Michael English, Jim Buckley

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

Immagina il mondo dello sviluppo software come un enorme e affollato cantiere edile. Per anni, gli operai (i programmatori) hanno costruito edifici (il software) a mano, mattone dopo mattone. Recentemente, è arrivato un nuovo tipo di robot: il Large Language Model (LLM). Questi robot possono leggere un progetto (una descrizione) e posare immediatamente i mattoni, scrivere codice o persino riparare muri danneggiati.

Questo documento non è un rapporto sulle prestazioni di un singolo robot. Piuttosto, è una "Revisione Terziaria". Pensala come un meta-rapporto. Gli autori non sono usciti a testare i robot di persona. Invece, hanno raccolto e analizzato 30 rapporti esistenti (studi secondari) che avevano testato questi robot. Volevano vedere il quadro generale: quanto velocemente sta crescendo questo campo? Cosa dicono i rapporti che funziona? Dove falliscono i robot? E cosa pensano gli esperti che dobbiamo fare dopo?

Ecco la sintesi delle loro scoperte, tradotta in linguaggio comune:

1. Il Panorama: Un Campo in Esplosione di Attività

Gli autori hanno osservato il "cantiere" della ricerca.

Il Boom: Nel 2022, c'era solo un rapporto su questi robot. Entro il 2024, quel numero è salito a 17. È come un improvviso boom dell'oro dove tutti scrivono sui nuovi robot.
Maturazione: Inizialmente, i rapporti erano semplici "sondaggi" (guardarsi intorno e dire: "Wow, ci sono molti robot!"). Ora, i rapporti stanno diventando "revisioni sistematiche" (indagini profonde e rigorose). Questo suggerisce che il campo sta maturando da una moda a una scienza seria.
La Trappola della Ridondanza: Anche se il numero di rapporti è triplicato, il numero di effettivi test sui robot che hanno coperto non è cresciuto altrettanto. È come avere 100 persone che scrivono recensioni degli stessi 10 film. Gli autori avvertono che i ricercatori potrebbero ripetere lo stesso lavoro invece di scoprire cose nuove.

2. Le Prestazioni: La Scheda Valutativa "HELM"

Gli autori hanno utilizzato una scheda valutativa speciale chiamata HELM (Valutazione Olistica dei Modelli Linguistici) per valutare i robot. Immagina di valutare uno studente non solo sui suoi voti d'esame, ma anche sulla sua sicurezza, velocità ed equità.

Accuratezza (Il Voto d'Esame): I robot stanno prendendo il massimo dei voti negli esami di pratica (benchmark). Riescono a risolvere molto bene specifici enigmi di programmazione. Tuttavia, i rapporti di alta qualità avvertono che questi punteggi potrebbero essere gonfiati. È come uno studente che ha memorizzato la chiave delle risposte ma potrebbe fallire se le domande cambiano leggermente. Nel mondo reale, spesso commettono errori.
Robustezza (Il "Test di Stress"): È qui che i robot sono fragili. Se cambi leggermente la formulazione di una richiesta o chiedi loro di lavorare in un linguaggio di programmazione diverso, spesso si bloccano. Sono come un'auto sportiva ad alte prestazioni che guida benissimo su una pista ma si blocca su una strada fangosa.
Efficienza (La Bolletta del Gas): I robot sono costosi. Richiedono enormi quantità di potenza di calcolo, elettricità e denaro per funzionare. Utilizzarli in un piccolo ufficio o su un telefono cellulare è attualmente come cercare di alimentare un tostapane con un reattore nucleare.
Tossicità e Bias (Il Pericolo per la Sicurezza): I robot generano talvolta codice che è insicuro, espone password private o copia materiale protetto da copyright. Tendono anche a favorire certi stili di programmazione rispetto ad altri, semplicemente perché è ciò che hanno visto più spesso nei loro dati di addestramento.

3. Gli Scenari: Dove Stanno Lavorando?

I rapporti si concentrano principalmente sui robot che eseguono compiti di costruzione di base:

Generazione di Codice: Scrivere nuovo codice da zero.
Riparazione: Risolvere bug o falle di sicurezza.
Completamento: Terminare una riga di codice iniziata da un umano.

È interessante notare che i rapporti menzionano raramente dove questo codice viene utilizzato (ad esempio: è per un sistema ospedaliero? Un videogioco? Un'auto?). Menzionano anche raramente quali linguaggi di programmazione vengono utilizzati, oltre ai principali come Python e Java. È come sapere che i robot possono posare mattoni, ma non sapere se stanno costruendo una casa, un ponte o un castello.

4. Le Sfide: Perché Non Possiamo Semplicemente Accendere l'Interruttore

Gli autori hanno identificato tre gruppi principali di problemi che impediscono a questi robot di prendere il controllo del cantiere:

L'Economia (Il Cartellino del Prezzo): Costa troppo addestrare ed eseguire questi modelli. Le piccole aziende o gli sviluppatori individuali non possono permettersi la "bolletta del gas".
La Valutazione (I Voti Finti): I test che usiamo per valutare questi robot non corrispondono alla realtà. Sono troppo semplici e non tengono conto della realtà disordinata e complessa della costruzione del software.
L'Integrazione (L'Attrito): I robot non si integrano bene con gli strumenti che gli sviluppatori usano già. Sono lenti, difficili da controllare e talvolta danno risposte confuse o inaffidabili. Gli sviluppatori non si fidano ancora pienamente di loro, e i nuovi sviluppatori potrebbero affidarsi troppo senza comprendere il codice.

5. Il Futuro: Cosa Succede Dopo?

I rapporti suggeriscono una chiara strada da seguire, che gli autori riassumono come:

Specializzare i Robot: Invece di un unico gigante robot che sa un po' di tutto, abbiamo bisogno di robot addestrati specificamente sul codice e sulle regole della nostra azienda.
Test Migliori: Dobbiamo smettere di usare semplici esami di pratica e iniziare a testare i robot in scenari realistici e disordinati.
Lavoro di Squadra: Il futuro non è solo il robot; è il robot che lavora insieme agli strumenti tradizionali e agli esperti umani (un approccio "ibrido").
Sicurezza Prima di Tutto: Dobbiamo risolvere le falle di sicurezza e privacy prima di lasciare questi robot liberi nel mondo reale.

La Conclusione

Questo documento conclude che la generazione di codice basata su LLM è una tecnologia in rapida maturazione che è attualmente valutata in modo disomogeneo.

È come un nuovo motore incredibilmente potente installato in un'auto. Il motore gira veloce sulla pista di prova (benchmark), ma non siamo sicuri che reggerà in una giornata di pioggia (robustezza nel mondo reale), se costerà una fortuna in carburante (efficienza) o se potrebbe accidentalmente precipitare da una scogliera (sicurezza). Il campo si sta muovendo velocemente, ma dobbiamo rallentare, costruire standard di sicurezza migliori e capire come rendere questa tecnologia effettivamente utile per i costruttori di tutti i giorni, non solo per superare i test.

Sintesi Tecnica: Una Revisione Terziaria di Attività di Generazione di Codice Basate su Modelli Linguistici di Grande Dimensione

Enunciato del Problema

I Modelli Linguistici di Grande Dimensione (LLM) sono sempre più applicati alle Attività di Generazione di Codice (CGT) nell'ingegneria del software (SE), mostrando risultati promettenti nei benchmark e in prove specifiche (ad esempio, GitHub Copilot, AlphaCode). Tuttavia, gli effetti più ampi di queste applicazioni, la loro integrazione nei flussi di lavoro di sviluppo reali e la validità dei risultati riportati rimangono insufficientemente compresi. Gli studi secondari e le revisioni terziarie esistenti sono spesso troppo ampi (coprono il ML generale nella SE), troppo ristretti (si concentrano solo su attività specifiche come i test o l'ingegneria dei prompt) o mancano di una definizione unificata delle CGT. Di conseguenza, manca una prova consolidata riguardo al panorama, agli effetti, alle sfide e alle direzioni future specificamente per le CGT basate su LLM. Questo articolo colma tale lacuna conducendo una revisione sistematica della letteratura terziaria (SLR) per sintetizzare le prove secondarie esistenti.

Metodologia

Gli autori hanno seguito le linee guida per le revisioni sistematiche di Kitchenham e gli standard di reporting SEGRESS per una reporting strutturato e trasparente. La metodologia ha coinvolto:

Strategia di Ricerca: È stata condotta una ricerca completa in cinque biblioteche digitali (IEEE Xplore, ACM DL, Scopus, DBLP, Web of Science) e Google Scholar. La ricerca ha utilizzato un processo di costruzione di query basato su PICOC, validato su un set di test, e ha combinato la interrogazione dei database con la tecnica della "palla di neve" (snowballing) in avanti e all'indietro.
Selezione e Screening: Il processo ha incluso lo screening di titoli/abstract e la revisione del testo completo. Per gestire il volume dei record (in particolare quelli derivanti dalla palla di neve), gli autori hanno adottato un nuovo approccio di screening semi-automatizzato utilizzando GPT-4o come screener di primo passaggio, validato contro il giudizio umano.
Criteri di Inclusione/Esclusione: La revisione si è concentrata su studi secondari (SLR, studi di mappatura sistematica, survey, meta-analisi) pubblicati tra il 2017 e il 2025 (fino a giugno 2025) che coprivano esplicitamente gli LLM applicati alle CGT. Sono stati esclusi gli studi primari, l'IA non basata su LLM e le attività non relative alla generazione di codice (ad esempio, la sintesi del codice).
Valutazione della Qualità: Gli studi selezionati sono stati valutati utilizzando i criteri DARE (Database of Abstracts of Reviews of Effects), risultando in una distribuzione di qualità del 43,3% Alta, 26,7% Media e 30,0% Bassa.
Estrazione e Sintesi dei Dati: I dati sono stati estratti utilizzando un modulo strutturato che copre i metadati delle pubblicazioni, gli ambiti AI/SE e le prove specifiche relative al framework HELM (Holistic Evaluation of Language Models). Gli autori hanno adattato il framework HELM (originariamente per il linguaggio naturale) al contesto SE ridefinendo gli "scenari" per includere attività, linguaggio di programmazione, tipo di applicazione e dominio di applicazione, mappando al contempo le "misure" su interpretazioni specifiche della SE (ad esempio, Accuratezza come correttezza funzionale, Tossicità come vulnerabilità di sicurezza).
Affidabilità: L'accordo inter-valutatore è stato valutato utilizzando il $\kappa$ di Fleiss e il $\kappa$ di Cohen, ottenendo un accordo quasi perfetto (0,86 per lo screening, 0,83 per la validazione dello screening AI e un'alta affidabilità per l'estrazione dei dati).

Contributi Chiave

Sintesi Terziaria delle CGT Basate su LLM: Il documento identifica e sintetizza 30 studi secondari (2017–2025), quantificando il panorama delle pubblicazioni, mappando gli ambiti AI e SE e analizzando le tendenze. Fornisce la prima visione consolidata delle prove specificamente per la generazione di codice basata su LLM.
Nuova Applicazione degli LLM nella Revisione della Letteratura: Lo studio dimostra l'uso affidabile di GPT-4o per migliorare l'efficienza del processo di palla di neve (screening dei riferimenti), raggiungendo alta precisione e richiamo rispetto allo screening umano, potenzialmente risparmiando un significativo sforzo umano.
Adattamento del Framework HELM: Gli autori adattano il framework HELM per i contesti di ingegneria del software. Mantengono il design multi-misura ma ridefiniscono gli scenari per riflettere dimensioni specifiche della SE (attività, linguaggio, tipo/dominio di applicazione) coerenti con SWEBOK v4 e ISO/IEC 25010, fornendo un modo strutturato per valutare le prestazioni degli LLM nelle CGT.

Risultati

RQ1: Panorama degli Studi Secondari

Crescita e Maturità: Il numero di studi secondari è cresciuto rapidamente, triplicando dal 2023 (6 studi) al 2024 (17 studi). Si nota un cambiamento significativo dai survey/review esplorativi verso revisioni sistematiche della letteratura (SLR) e studi di mappatura sistematica (SMS) più rigorosi, con l'83% degli studi del 2025 che sono SLR/SMS.
Ridondanza: Sebbene il numero di studi secondari sia aumentato significativamente, il numero totale di studi primari unici esaminati è cresciuto meno drammaticamente, suggerendo una ridondanza emergente e un campo che matura, dove i contributi futuri potrebbero dover concentrarsi sul raffinamento dell'ambito piuttosto che sul volume.
Ambiti: Il campo è dominato da studi focalizzati sugli LLM (21/30). Per quanto riguarda l'ambito SE, la "Costruzione del Software" è il focus principale (25 studi), seguito da "Manutenzione del Software" (14) e "Sicurezza del Software" (11). La maggior parte degli studi ha un ambito ristretto (copre 1–2 aree di conoscenza SWEBOK).
Luoghi di Pubblicazione: Riviste di alta qualità (ad esempio, TOSEM, TSE) ospitano la maggior parte degli studi revisionati tra pari, sebbene una parte significativa (9/30) appaia su arXiv, riflettendo la natura rapida del campo.

RQ2: Misure HELM Riferite

Accuratezza: La misura più riportata (18 studi). Sebbene molti studi riportino un'alta accuratezza sui benchmark (ad esempio, HumanEval, MBPP), studi di qualità superiore esprimono cautela, notando che i punteggi dei benchmark possono essere gonfiati da perdite di dati e non sempre riflettono la generalizzazione nel mondo reale o la correttezza semantica.
Robustezza: Riferita in 16 studi. Le prove suggeriscono che la robustezza è fragile; le prestazioni variano significativamente tra attività, linguaggi e configurazioni. I modelli spesso non riescono a generalizzare oltre dataset specifici o mostrano sensibilità alle perturbazioni dei prompt.
Efficienza: Discussa in 14 studi. Vi è un riconoscimento costante degli alti costi computazionali, economici ed energetici associati all'addestramento, all'inferenza e alla valutazione, in particolare per i modelli di grandi dimensioni e gli ambienti con risorse limitate.
Tossicità e Bias: La tossicità (8 studi) e il bias (2 studi) sono sottoriferiti ma costantemente identificati come rischi, principalmente legati ai dati di addestramento (ad esempio, perdite di privacy, pattern di codice insicuri e squilibri nei dataset).
Calibrazione ed Equità: Queste misure non sono state affrontate esplicitamente negli studi secondari esaminati.

RQ3: Scenari HELM Riferiti

Attività: Le attività più frequentemente riportate sono la Generazione/Riparazione di Patch (22 studi), la Generazione di Codice (20), la Traduzione del Codice (9) e il Completamento del Codice (8).
Linguaggi: È coperto un'ampia gamma di linguaggi, con Java, Python, C, C++ e JavaScript i più comuni.
Dominî: I domini di applicazione sono raramente riportati e i tipi di applicazione sono menzionati in soli due studi, limitando la validità esterna di molte scoperte.

RQ4: Sfide

La sintesi identifica tre cluster di sfide dominanti:

Fattibilità Economica: Elevati costi relativi ad addestramento, inferenza e consumo energetico, insieme a vincoli hardware.
Validità della Valutazione: I benchmark attuali sono spesso non rappresentativi dello sviluppo reale (ambito ristretto, singolo linguaggio, perdite di dati), portando a una scarsa generalizzabilità.
Integrazione Socio-Tecnica: Le sfide includono un'integrazione insufficiente con gli strumenti esistenti (IDE), mancanza di controlli operativi, problemi di reattività e la necessità di supervisione umana e formazione sulla sicurezza per gli sviluppatori.

Altre sfide includono limitazioni di Dati e Contesto (limiti dei token, spostamenti di dominio), Sicurezza e Sicurezza (vulnerabilità nel codice generato) e Rischi Legali/Privacy.

RQ5: Direzioni Future

Le direzioni future più frequentemente raccomandate sono:

Miglioramento e Addestramento del Modello: Nello specifico, adattamento consapevole del dominio (dataset specializzati, fine-tuning) e miglioramento dell'efficienza e dell'interpretabilità.
Miglioramento dei Benchmark e della Valutazione: Richieste di framework di valutazione completi, multi-metrica e cross-linguaggio che vadano oltre la correttezza funzionale.
Ensemble e Ibridazione: Combinare gli LLM con altri modelli o metodi SE tradizionali (ad esempio, analisi statica) per migliorare prestazioni e affidabilità.
Integrazione nella Pratica: Passare da strumenti autonomi a soluzioni integrate nel flusso di lavoro (ad esempio, RAG, plugin IDE).
Sicurezza, Privacy e Affidabilità: Affrontare vulnerabilità e perdite di dati.

Significato e Affermazioni

Il documento afferma di fornire la prima sintesi terziaria sistematica delle prove secondarie sulle CGT basate su LLM. Sottolinea che il campo è in rapida maturazione ma valutato in modo disomogeneo. Sebbene gli LLM mostrino promesse, gli autori sottolineano che:

I guadagni di accuratezza riportati sono spesso specifici del benchmark e potrebbero non tradursi in scenari reali.
La robustezza è fragile e i vincoli di efficienza sono pervasivi.
C'è un bisogno critico di miglioramenti dei modelli consapevoli del dominio e di framework di valutazione olistici e standardizzati che affrontino efficienza, sicurezza e integrazione socio-tecnica.
Il campo sta passando dalla mappatura esplorativa alla sintesi rigorosa, ma i rischi di ridondanza e la copertura limitata di aree SE sottorappresentate (come i test e la gestione) rimangono.

Gli autori concludono che affinché le CGT basate su LLM siano integrate con successo nell'ingegneria del software reale, la ricerca futura deve affrontare la fattibilità economica, sviluppare benchmark più rappresentativi e concentrarsi sugli aspetti socio-tecnici dell'integrazione uomo-in-the-loop.