Evaluating LLM-Generated Code: A Benchmark and Developer Study

Problematica
Gli attuali metodi di valutazione per i Large Language Models (LLM) nella generazione di codice (NL2Code) si basano prevalentemente su benchmark che misurano la correttezza della soluzione attraverso unit test su compiti isolati a livello di funzione (es. HumanEval, MBPP). Sebbene efficaci per stabilire capacità di base, questi benchmark non riescono a riflettere gli scenari di programmazione del mondo reale. La programmazione nel mondo reale spesso comporta la creazione di progetti multi-componente con dipendenze, richiede il prompting sequenziale e necessita di codice che sia non solo corretto, ma anche leggibile, manutenibile e pronto per la produzione. Inoltre, vi è una scarsità di ricerca che coinvolga esperti umani per valutare la qualità e l'usabilità del codice generato dagli LLM, poiché la maggior parte delle valutazioni si affida esclusivamente a metriche automatizzate o all'approccio "LLM-as-a-Judge", che potrebbero non catturare appieno le preoccupazioni dei developer, come la struttura e la documentazione.

Metodologia
Il documento propone una metodologia di valutazione tripartita personalizzata, progettata per colmare il divario tra il testing di funzioni isolate e la valutazione olistica di un progetto. Questo framework integra il testing della correttezza automatizzato, la verifica della qualità del codice automatizzata e la valutazione umana strutturata.

1. Assignment di Coding: Lo studio utilizza un complesso progetto di informatica multi-componente intitolato "Building the Tree of Life from Scratch", adattato dalla lista NIFTY Assignments. Il compito riguarda la bioinformatica (alberi filogenetici) e richiede l'implementazione di programmazione dinamica, ricorsione, grafi e strutture ad albero. Gli LLM vengono istruiti tramite un set fisso di 14 prompt sequenziali per generare la soluzione da zero, senza codice iniziale, imitando il flusso di lavoro di un vero sviluppatore.
2. Benchmark di Correttezza: È stato sviluppato un benchmark personalizzato per verificare la soluzione in più checkpoint piuttosto che solo sull'output finale. Questo include:
   • La verifica dei punteggi di Needleman-Wunsch.
   • La validazione della sintassi del formato Newick (per la struttura dell'albero e le distanze dei nodi).
   • Il controllo della struttura dell'albero filogenetico.
   • La validazione dei risultati di clustering basati su soglie.
   • La conferma della generazione di un file PNG di un dendrogramma.
   • Verifica Tecnica: È stato incluso un passaggio manuale in cui i ricercatori hanno corretto minori errori di sintassi, compilazione e dipendenze per garantire che il codice potesse essere eseguito, documentando tali correzioni per valutare la "riparabilità" (fixability).
3. Verifica Automatica della Qualità: Il codice generato è stato analizzato utilizzando SonarQube per misurare affidabilità, manutenibilità e sicurezza, e per contare i "code smells" e il debito tecnico.
4. Valutazione della Qualità Basata sull'Uomo (Studio sui Developer): È stato progettato un sondaggio strutturato per raccogliere recensioni del codice da sviluppatori volontari. Il sondaggio ha utilizzato una scala Likert a 5 punti su 14 metriche categorizzate in:
   • Struttura della base di codice (nomi, formattazione, separazione delle responsabilità).
   • Qualità di commenti e spiegazioni (utilità, posizionamento, qualità del README).
   • Facilità d'uso (modificabilità, testabilità).
   • Un campo aperto per commenti aggiuntivi e una domanda finale che chiede quale codice lo sviluppatore sceglierebbe di utilizzare.

Setup Sperimentale
La metodologia è stata applicata a tre LLM general-purpose: GPT-4.1, DeepSeek-V3-0324 e Claude Opus 4. Ogni modello è stato eseguito tre volte con parametri fissi (temperatura 0.2, max token 4096) per tenere conto della non-determinatezza. Per il sondaggio umano, una soluzione per modello (selezionata in base al più alto tasso di successo della correttezza) è stata revisionata da 10 sviluppatori volontari reclutati tramite LinkedIn.

Risultati Chiave

• Correttezza: DeepSeek-V3-0324 ha ottenuto il punteggio di correttezza più alto, superando 5 casi di test su 7 nella sua migliore esecuzione. GPT-4.1 è stato l'unico modello a generare soluzioni che giravano senza intervento manuale in due dei suoi tre tentativi, sebbene abbia superato meno casi di test complessivamente (3-4/7). Claude Opus 4 è stato il peggiore in termini di correttezza, con un tentativo che ha superato zero test.
• Qualità Automatica: Tutti i modelli hanno ricevuto valutazioni 'A' per sicurezza, affidabilità e manutenibilità in SonarQube. Tuttavia, le soluzioni di DeepSeek presentavano il minor numero di code smells e il minor tempo stimato per risolvere i problemi. Le soluzioni di GPT-4.1 avevano il più alto rapporto di debito tecnico e i tempi di riparazione più lunghi.
• Sondaggio Umano: Nonostante DeepSeek avesse le migliori metriche automatizzate, il sondaggio dei developer ha rivelato una divergenza nelle preferenze. I developer hanno valutato GPT-4.1 il peggio, citando commenti scarsi, struttura caotica e argomenti hard-coded. Mentre DeepSeek è stato lodato per la parametrizzazione, Claude Opus 4 ha ricevuto i feedback più positivi riguardo alla facilità di modifica e testing. Notevolmente, quando interrogati su quale codice avrebbero scelto di utilizzare, 6 sviluppatori su 10 hanno scelto la soluzione di Claude, mentre solo 4 hanno scelto DeepSeek.
• Allineamento: Lo studio ha rilevato che le metriche di correttezza automatizzate e le valutazioni qualitative umane si completano a vicenda ma non sempre sono allineate. Un modello con maggiore correttezza (DeepSeek) non era necessariamente preferito dai developer rispetto a un modello con una correttezza leggermente inferiore ma con una migliore struttura e leggibilità (Claude).

Significatività e Contributi
Il documento sostiene di apportare quattro contributi primari al campo:

1. Un framework di valutazione tripartito che combina testing automatizzato, verifica della qualità del codice e sondaggi tra i developer per catturare sia la correttezza che l'usabilità.
2. Un benchmark di correttezza a livello di progetto basato su un complesso assignment multi-file, andando oltre i compiti isolati a livello di singola funzione.
3. Un design di sondaggio strutturato dedicato alla raccolta di recensioni del codice da parte dei developer in modo standardizzato, affrontando la mancanza di valutazione centrata sull'uomo nella ricerca sugli LLM.
4. Una dimostrazione del framework attraverso la valutazione di tre LLM, mostrando che le recensioni dei developer possono fornire risultati critici — in particolare riguardo alla prontezza per la produzione e alla manutenibilità — che i benchmark di correttezza standard trascurano.

Gli autori concludono che, sebbene i benchmark automatizzati siano utili, una valutazione completa degli LLM per la generazione di codice richiede l'integrazione del feedback umano per comprendere l'utilità pratica e l'esperienza dello sviluppatore con le soluzioni generate. Lo studio evidenzia che il codice "corretto" non è sempre codice "buono" in un contesto di produzione.