Riepilogo Tecnico: Gli LLM possono produrre design orientati agli oggetti migliori rispetto allo sviluppo con intervento umano?

Enunciato del Problema

Sebbene i Modelli Linguistici di Grandi Dimensioni (LLM) siano sempre più capaci di generare codice, la loro abilità nel produrre design orientati agli oggetti (OOD) di alta qualità per progetti multi-classe rimane incerta. Le ricerche precedenti si sono concentrate principalmente su:

1. Correttezza funzionale a livello di problema (singoli metodi o classi) piuttosto che sull'architettura a livello di progetto.
2. Linee di base pre-LLM, non tenendo conto dell'impatto dello sviluppo umano assistito da LLM (PostAI).
3. Artefatti di alto livello (ad esempio, diagrammi UML) piuttosto che sulla manutenibilità e sulla qualità strutturale del codice implementato.

Questo studio colma il divario nella comprensione di come la qualità OOD nei progetti generati end-to-end dagli LLM (PureAI) si confronti con i progetti con intervento umano prodotti prima (PreAI) e dopo (PostAI) la diffusione capillare degli LLM.

Metodologia

Gli autori hanno condotto uno studio di caso comparativo utilizzando un compito universitario di livello magistrale in Java: l'implementazione del gioco da tavolo Kalah. Lo studio ha analizzato 11 dataset attraverso tre condizioni di paternità:

1. PreAI (Con intervento umano, Pre-LLM): 93 elaborati di marzo 2021, precedenti al rilascio pubblico dei principali assistenti di codifica basati su LLM.
2. PostAI (Con intervento umano, Post-LLM): 57 elaborati di agosto 2024, dopo che gli strumenti LLM sono diventati mainstream.
3. PureAI (Generato da LLM): Oltre 810 esecuzioni di generazione utilizzando tre modelli contemporanei (gpt-5.4, gemini-2.5-pro, gemini-3.1-pro-preview) su tre varianti di prompt che variavano nella specificità delle indicazioni OOD (Nessuna, Generale, Specifiche). Sono state conservate solo le esecuzioni che hanno superato tutti i 19 casi di test funzionali (dopo fino a cinque iterazioni di riparazione).

Metriche di Valutazione

Lo studio ha adottato un framework di valutazione multidimensionale:

• Metriche OOD: 13 metriche che catturano le caratteristiche strutturali, tra cui Metodi Ponderati per Classe (WMC), Accoppiamento tra Classi di Oggetti (CBO), Mancanza di Coesione nei Metodi (LCOM), Profondità dell'Albero di Ereditarietà (DIT), Numero di Classi (#Cl) e Righe di Codice (LOC).
• Densità degli Odori di Codice: Densità a livello di progetto di 30 tipi di odori rilevati (11 a livello di metodo, 19 a livello di classe), normalizzata per dimensione (KLOC).
• Modellazione del Dominio:
  • Rappresentazione dei Concetti: Se sei concetti chiave del dominio (Board, Game, Player, Pit, House, Store) sono stati modellati esplicitamente come classi.
  • Conformità al Runtime: Se il numero di oggetti istanziati corrispondeva ai requisiti implicati dai concetti del dominio.

Analisi Statistica

I confronti hanno utilizzato il test U di Mann–Whitney con il delta di Cliff ($\delta$) per la dimensione dell'effetto sulle metriche non binarie, e test Chi-quadro/Fisher esatti con Rapporti di Probabilità (OR) per le metriche binarie. I risultati sono stati corretti per confronti multipli utilizzando la procedura di Benjamini–Hochberg.

Contributi Chiave

1. Prima Analisi Comparativa: Questo è il primo studio a confrontare la qualità OOD tra le condizioni PreAI, PostAI e PureAI in un contesto a livello di progetto.
2. Valutazione Multidimensionale: Lo studio combina metriche OOD quantitative, analisi degli odori di codice e modellazione del dominio basata sui requisiti per fornire una visione olistica della qualità del design.
3. Evidenze Empiriche sulla Sovrasemplificazione: Il documento fornisce prove che, sebbene il codice generato dagli LLM appaia spesso "più pulito" (minore densità di odori), ciò è frequentemente associato a sovrasemplificazione (mancanza di astrazioni, separazione delle responsabilità più debole).
4. Approfondimenti sulle Tendenze PostAI: Lo studio dimostra che i progetti con intervento umano nell'era degli LLM (PostAI) mostrano tendenze di design più vicine a PureAI (semplificazione) rispetto a PreAI, ma senza la stessa riduzione degli odori di codice.

Risultati

RQ1: Differenze tra PreAI, PostAI e PureAI

• Semplicità Strutturale vs. Sovrasemplificazione: I progetti PureAI generalmente presentano meno classi, minore complessità totale, dimensione e accoppiamento rispetto ai progetti umani. Tuttavia, questa "semplicità" è correlata alla sovrasemplificazione:
  • Complessità/accoppiamento medio e percentuale massima per classe più elevati (il carico è concentrato in meno classi).
  • Minore coesione (LCOM più alto), poiché singole classi spesso rappresentano più concetti del dominio.
  • Meno concetti del dominio rappresentati esplicitamente (mancanza di astrazioni).
• Odori di Codice: I progetti PureAI mostrano una densità di odori di codice significativamente inferiore (sia a livello di metodo che di classe) rispetto ai progetti con intervento umano.
• Convergenza PostAI: I progetti PostAI sono statisticamente più vicini a PureAI che a PreAI su molte metriche OOD, mostrando tendenze simili verso la semplificazione e la mancanza di concetti del dominio. Tuttavia, a differenza di PureAI, i progetti PostAI hanno una densità di odori di codice maggiore rispetto a PreAI, in particolare a livello di metodo.
• Conformità al Runtime: Una volta che un concetto del dominio è rappresentato, i progetti PureAI sono generalmente più propensi a conformarsi al runtime rispetto ai progetti umani.

RQ2: Effetto della Specificità del Prompt in PureAI

• Impatto delle Indicazioni: L'aumento della specificità del prompt (da Nessuna $\to$ Generale $\to$ Specifiche) porta generalmente a:
  • Più classi e maggiore complessità totale/dimensione/accoppiamento (allontanandosi dalla sovrasemplificazione).
  • Complessità/accoppiamento medio e percentuale massima per classe più bassi.
  • Riduzione della densità complessiva e a livello di metodo degli odori di codice.
  • Migliore rappresentazione dei concetti del dominio (sebbene gli effetti varino in base al modello).
• Limitazioni: Prompt più specifici non colmano completamente il divario con i progetti con intervento umano. Per alcuni modelli (ad esempio O54), l'aumento della specificità da Generale a Specifiche produce miglioramenti aggiuntivi limitati.

Significato e Implicazioni

Il documento conclude che, sebbene gli LLM possano gestire efficacemente i dettagli di implementazione (producendo codice con meno odori e alta conformità al runtime), faticano con la decomposizione orientata agli oggetti e l'assegnazione delle responsabilità senza una guida umana esplicita.

• Rischio di Sovrasemplificazione: I progetti PureAI spesso appaiono più semplici e meno "odorosi", ma ciò maschera una mancanza di corretta astrazione e separazione delle responsabilità, che può danneggiare la manutenibilità a lungo termine.
• Avvertimento PostAI: La disponibilità di strumenti LLM potrebbe portare gli sviluppatori umani a produrre design che imitano la sovrasemplificazione degli LLM (mancanza di concetti) introducendo al contempo nuovi problemi locali (odori a livello di metodo), potenzialmente annullando i guadagni di produttività.
• Necessità di Intervento Umano: Una guida umana appropriata sulla decomposizione di alto livello e sulla modellazione del dominio rimane fondamentale. Fare affidamento esclusivamente su prompt OOD generici o anche specifici è insufficiente per raggiungere una qualità del design paragonabile a quella umana.
• Strategia di Revisione: Le revisioni del codice in ambienti assistiti da LLM dovrebbero verificare esplicitamente la mancanza di concetti del dominio e strutture sovrasemplificate, piuttosto che limitarsi alla correttezza funzionale o agli odori di codice locali.

Lo studio suggerisce che l'uso più efficace degli LLM nell'OOD è sfruttarli per l'implementazione all'interno di una struttura definita da esperti umani che comprendono il dominio e l'architettura desiderata.