Test-Oriented Programming: rethinking coding for the GenAI era

1. Il Problema

L'emergere di modelli linguistici su larga scala (LLM) ha introdotto strumenti di intelligenza artificiale generativa (GenAI) per lo sviluppo software, come gli assistenti per l'autocompletamento (es. GitHub Copilot), l'uso di agenti multipli o il "vibe coding" (sviluppo basato su conversazione). Tuttavia, l'autore identifica un limite fondamentale in questi approcci attuali: mancano di un reale aumento del livello di astrazione.
Nonostante la velocità di generazione del codice, lo sviluppatore deve ancora ispezionare, comprendere e correggere il codice di produzione generato, che rimane scritto in linguaggi di programmazione convenzionali. Inoltre, i linguaggi naturali, se usati direttamente per specificare il software, soffrono di ambiguità, mentre i LLM mancano di determinismo. L'obiettivo è quindi trovare un paradigma che permetta di delegare completamente la scrittura del codice di produzione, mantenendo però la garanzia di correttezza.

2. Metodologia

Per affrontare questa sfida, l'autore propone un nuovo paradigma chiamato Test-Oriented Programming (TOP) e ne valida la fattibilità attraverso lo sviluppo di uno strumento proof-of-concept chiamato Onion.

• Il Paradigma TOP: In questo modello, lo sviluppatore non scrive il codice di produzione. Il flusso di lavoro si basa su:

  1. Specifiche in linguaggio naturale.
  2. Scrittura e verifica del codice di test (test code) da parte dello sviluppatore.
  3. Generazione automatica del codice di produzione da parte dell'LLM, guidata dalle specifiche naturali e dai test.
     L'idea centrale è che i test risolvano l'ambiguità delle specifiche naturali e fungano da "verifica" per la generazione del codice.

• Strumento Onion:

  • È uno strumento a riga di comando iterativo.
  • Utilizza un file di configurazione in YAML contenente:
    • Descrizione del progetto (obiettivi, dipendenze, output).
    • Descrizione dei test di accettazione (in linguaggio naturale).
  • Flusso di lavoro di Onion:
    1. Genera una struttura del progetto (file YAML) con classi e metodi.
    2. Genera i file dei test di accettazione e dei test unitari per ogni classe.
    3. Lo sviluppatore verifica e modifica i test se necessario.
    4. L'esecuzione dei test guida l'LLM nella generazione del codice di produzione.
    5. Se i test falliscono dopo un certo numero di tentativi, l'LLM riprova o l'utente modifica i test/la struttura.
    6. Una volta passati tutti i test, viene generato il file principale del sistema.

• Valutazione Sperimentale:

  • Caso d'uso: Generazione di uno strumento a riga di comando per gestire voci BibTeX (aggiunta, elenco, ricerca).
  • Modelli LLM confrontati: OpenAI GPT-4o-mini (modello di ragionamento) e Google Gemini 2.5-Flash (modello non di ragionamento).
  • Metriche: Numero di tentativi, intervento umano richiesto, qualità del codice, variabilità dei risultati.

3. Contributi Chiave

• Proposta del Paradigma TOP: Definizione di un nuovo modello di sviluppo che sposta il focus dello sviluppatore dalla scrittura del codice di produzione alla definizione e verifica dei test, sfruttando la GenAI per colmare il divario tra specifiche naturali e codice eseguibile.
• Strumento Onion: Implementazione pratica che dimostra come orchestrare LLM, file di configurazione e cicli di test per generare software funzionante.
• Analisi Comparativa: Confronto empirico tra modelli LLM diversi (ragionamento vs non ragionamento) in un contesto di generazione software guidata dai test.
• Identificazione delle Sfide: Mappatura delle criticità tecniche necessarie per scalare questo approccio a progetti reali.

4. Risultati

L'esperimento ha prodotto risultati promettenti ma ha evidenziato anche ostacoli significativi:

• Successo nella Generazione: In tutti i tentativi, è stato possibile generare codice di produzione funzionante senza mai dover modificare direttamente il codice sorgente (production code). Gli errori sono stati risolti intervenendo sui test o sulla configurazione.
• Intervento Umano: La maggior parte dei fallimenti nella generazione del codice era dovuta a incoerenze nel codice di test. Una volta corretti i test, il codice veniva generato correttamente.
• Variabilità dei Modelli:
  • GPT-4o-mini: Ha generato codice più breve, con meno commenti e ha richiesto meno interventi correttivi sui test (solo un caso su cinque).
  • Gemini 2.5-Flash: Ha generato codice più verboso, ricco di commenti, e ha fallito più frequentemente nella generazione corretta, richiedendo spesso l'aggiunta di commenti guida nei test per orientare il modello.
• Mancanza di Determinismo: Anche con lo stesso modello e le stesse specifiche, i risultati variavano tra le diverse esecuzioni (variabilità del codice generato).
• Sfida della Verifica: La quantità di codice di test generato (specialmente con Gemini) rappresenta un carico cognitivo elevato per lo sviluppatore che deve verificarlo.

5. Significato e Conclusioni

Il paper dimostra la fattibilità teorica e pratica del Test-Oriented Programming come un passo avanti nell'astrazione dello sviluppo software.

• Impatto: TOP permette di trattare il codice di produzione come un dettaglio implementativo delegato alla macchina, elevando il ruolo dello sviluppatore a quello di "architetto dei test" e validatore delle specifiche.
• Limiti Attuali: Onion è attualmente un proof-of-concept non adatto a sistemi complessi senza una scomposizione modulare (es. microservizi).
• Sfide Future: Per l'adozione reale, è necessario affrontare:
  1. La gestione della quantità di codice di test generato (necessità di tool di supporto per la verifica).
  2. La variabilità dei modelli (codice generato molto diverso tra diversi LLM).
  3. La mancanza di determinismo degli LLM, che richiede strategie robuste di verifica.

In sintesi, il paper suggerisce che il futuro dello sviluppo software con la GenAI non risiede nel far scrivere più codice agli umani, ma nel far scrivere test agli umani e lasciare che le macchine generino il codice che li soddisfa.