"Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering

Questo studio analizza come gli ingegneri del software interagiscono con gli assistenti AI, rivelando che l'incapacità dei modelli linguistici di fornire risposte corrette porta spesso all'abbandono dello strumento, nonostante gli utenti tentino di mitigare tali errori con strategie di scaffolding e chiarimento dei prompt.

L'essenziale

Immagina di avere un assistente personale super intelligente, un po' come un genio della programmazione che vive dentro il tuo computer. Questo assistente (chiamato LLM, o "ChatGPT" nel testo) è diventato molto popolare tra gli ingegneri del software perché promette di scrivere codice, risolvere bug e insegnare cose nuove in un attimo.

Tuttavia, questo studio si chiede: "Dovrei arrendermi ora?".

Gli autori hanno messo alla prova questo assistente chiedendo a 26 persone (dai studenti universitari ai programmatori esperti) di costruire un sito web complesso passo dopo passo, usando solo ChatGPT come aiuto. Ecco cosa hanno scoperto, spiegato con parole semplici e qualche metafora.

1. Il Genio che si distrae (I Problemi)

Immagina di avere un assistente che è bravissimo a scrivere una singola frase, ma quando gli chiedi di scrivere un intero romanzo, inizia a dimenticare i personaggi, a inventare fatti che non sono mai accaduti o a darti risposte troppo lunghe e confuse.

Lo studio ha trovato 9 tipi di "incidenti" principali:

• Risposte incomplete: Chiedi "costruiscimi una casa" e l'assistente ti dà le fondamenta e il tetto, ma dimentica le pareti. Devi tu a metterle.
• Risposte sbagliate: L'assistente ti dà istruzioni che sembrano perfette, ma se le segui, la casa crolla (codice pieno di errori).
• Dimenticanze (Perdita di contesto): Se dopo 10 minuti di conversazione chiedi "ricordi che volevo il tetto rosso?", l'assistente fa finta di nulla e ti risponde come se fosse la prima volta. È come parlare con qualcuno che ha una memoria di pesce rosso.
• Sovraccarico cognitivo: A volte l'assistente ti spara addosso 50 pagine di testo invece di dirti semplicemente "cambia questo numero". È come ricevere un'enciclopedia quando volevi solo l'orario del treno.

2. Chi è il colpevole? (Le Cause)

Non è sempre colpa dell'assistente, né sempre tua. È come un duetto di danza dove uno dei due inciampa.

• Colpa dell'utente: A volte le persone chiedono cose troppo vaghe ("Fai un sito bello") o saltano le istruzioni importanti perché leggono troppo velocemente.
• Colpa dell'assistente: Altre volte, anche se chiedi cose precise, l'assistente ignora le tue regole, inventa file che non esistono o non capisce che sei un principiante e ti dà soluzioni da esperto (o viceversa).

3. La danza dei tentativi (Le Strategie di Riparazione)

Quando l'assistente sbaglia, le persone provano a "aggiustare il tiro". Hanno usato strategie come:

• Spezzettare il compito: Invece di chiedere "fai tutto", chiedono "fai prima il menu, poi il footer".
• Riformulare la domanda: "No, intendevo questo..."
• Controllare a mano: Copiare il codice, provarlo e correggerlo da soli.
• Cercare altrove: Quando l'assistente continua a sbagliare, le persone vanno su Google o StackOverflow.

4. Il momento della verità: Quando si arrendono?

Qui arriva il dato più importante. 17 persone su 26 hanno deciso di buttare via l'assistente e finire il lavoro da sole.

Perché?

• La risposta inutile è un killer: Se l'assistente dà una risposta inutile, la probabilità che l'utente si arrende aumenta di 11 volte. È come se ti dessi una mappa sbagliata per 10 volte di fila: alla fine smetti di chiedere indicazioni e cammini a tentoni.
• Più provi, meno ti arrendi: Paradossalmente, chi continua a fare domande (anche se molte) tende a non arrendersi subito. È come se dire "provo ancora" tenesse viva la speranza.
• L'esperienza conta: I programmatori esperti si arrendono prima se vedono che l'assistente non funziona, perché sanno che perdere tempo a correggere errori è peggio che farlo da soli. I principianti, invece, tendono a insistere di più, anche se spesso si perdono in un labirinto di domande senza uscita.

5. Il paradosso del "Nuovo Modello"

Lo studio è stato ripetuto anche con una versione più nuova e potente dell'assistente (GPT-5.1).
Risultato sorprendente: Anche se il nuovo assistente è più intelligente e fa meno errori all'inizio, gli stessi problemi di fondo rimangono. Quando il compito diventa lungo e complesso, il nuovo assistente continua a dimenticare il contesto, a confondersi e a far perdere tempo. È come avere un'auto di lusso che ha un motore potente, ma se il GPS si blocca, arrivi comunque in ritardo.

Conclusione: Cosa dobbiamo imparare?

Questo studio ci dice che l'Intelligenza Artificiale nella programmazione non è ancora un "magico sostituto" che lavora al posto nostro. È più simile a un tirocinante molto veloce ma distratto.

• Non è magico: Non puoi affidargli tutto e aspettare che funzioni. Devi essere il "capo" che controlla, corregge e guida.
• Il rischio è la frustrazione: Se l'assistente ti fa perdere più tempo a correggere i suoi errori che a lavorare da solo, la scelta logica è abbandonarlo.
• Il futuro: Per funzionare bene, questi strumenti dovranno imparare a non dimenticare le conversazioni passate, a capire meglio chi li sta usando (principiante o esperto) e a non dare risposte troppo lunghe e confuse.

In sintesi: l'AI è uno strumento potente, ma finché non impara a essere un vero "partner" e non solo un "generatore di testo", gli ingegneri dovranno spesso dire: "Ok, basta, lo faccio io".

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "Should I Give Up Now?" Investigating LLM Pitfalls in Software Engineering, tradotto e strutturato in italiano.

1. Il Problema

L'integrazione di assistenti basati su Large Language Models (LLM) come ChatGPT nei flussi di lavoro degli ingegneri del software promette di aumentare la produttività e ridurre il carico cognitivo. Tuttavia, l'esperienza degli utenti è estremamente variabile: mentre alcuni trovano questi strumenti utili, altri li considerano controproducenti a causa di risposte inaccurate o incomplete.

La ricerca attuale si è concentrata principalmente sulle capacità dei modelli o su compiti isolati e ben definiti (es. problemi di LeetCode). Manca però una comprensione approfondita di come gli utenti interagiscano con gli LLM in scenari reali, complessi e multi-step (come lo sviluppo di applicazioni web) con un basso livello di "scaffolding" (supporto strutturato). Il problema centrale è capire perché, nonostante i potenziali benefici, gli sviluppatori tendano ad abbandonare l'uso dell'LLM durante l'esecuzione di un compito, e quali siano i meccanismi specifici di fallimento che portano a questa decisione.

2. Metodologia

Lo studio ha adottato un approccio misto (qualitativo e quantitativo) basato su osservazioni empiriche.

• Design del Task: I partecipanti hanno dovuto completare un progetto di sviluppo web complesso che richiedeva l'uso di HTML, CSS, JavaScript e il deployment. Il task era strutturato in 13 sottocompiti (es. inserimento immagini, creazione di divisioni, gestione di form, pop-up), simulando un scenario di apprendimento e sviluppo con tecnologie non familiari.
• Partecipanti: Lo studio ha coinvolto 26 partecipanti completi (dopo l'esclusione di alcuni dati pilota):
  • Studenti universitari con esperienza di programmazione limitata.
  • Sviluppatori Software Professionali (SDE) con esperienza variabile.
  • È stata inclusa una replica dello studio utilizzando un modello più recente (GPT-5.1) per verificare la robustezza dei risultati rispetto all'evoluzione dei modelli.
• Protocollo:
  • Sessioni virtuali registrate (audio e schermo) con protocollo "think-aloud" (pensare ad alta voce).
  • Utilizzo di ChatGPT (versioni GPT-4, GPT-4o e GPT-5.1) senza formazione specifica sull'ingegneria dei prompt (prompt engineering), per osservare l'uso naturale e non ottimizzato.
  • Interviste semi-strutturate post-task per raccogliere percezioni e motivazioni.
• Analisi dei Dati:
  • Qualitativa: Analisi tematica induttiva di trascrizioni, registrazioni dello schermo e log di interazione per identificare tipi di fallimento, cause e strategie di mitigazione.
  • Quantitativa: Modellazione di regressione logistica per analizzare i fattori che influenzano la probabilità di abbandono (variabile dipendente: Abandon_ChatGPT).

3. Contributi Chiave

Il paper offre diversi contributi originali alla letteratura sull'interazione uomo-AI e l'ingegneria del software:

1. Dataset di Interazioni: Un dataset dettagliato di storie di interazione con ChatGPT per compiti SE complessi, utile per ricerche future.
2. Tassonomia dei Fallimenti: Identificazione di 9 tipi distinti di fallimento raggruppati in tre categorie macroscopiche.
3. Analisi delle Cause: Distinzione tra cause attribuibili all'utente (es. prompt vaghi) e cause attribuibili al modello (es. perdita di contesto), identificando 12 cause sottostanti.
4. Strategie di Mitigazione: Catalogazione di 7 strategie utilizzate dagli utenti per tentare di recuperare dopo un fallimento.
5. Evidenza Statistica sull'Abbandono: Un modello quantitativo che collega specifiche caratteristiche delle interazioni (utilità della risposta, numero di prompt, esperienza) alla probabilità di abbandono.

4. Risultati Principali

A. Tipologie di Fallimento (RQ1)

I ricercatori hanno identificato 92 casi di fallimento (58% delle interazioni), classificati in:

1. Risposte Incomplete o Errate:
   • Risposta incompleta (F1): Il modello omette dettagli cruciali quando si gestiscono prompt complessi (es. interi file di codice).
   • Mancanza di precondizioni (F3): Omissione di passaggi di setup necessari (es. installazione di pacchetti).
   • Risposta errata (F7): Generazione di codice con bug o errori logici.
2. Sovraccarico Cognitivo e Gestione Inadeguata delle Informazioni:
   • Risposta travolgente (F2): Risposte eccessivamente lunghe senza una struttura chiara, costringendo l'utente a cercare informazioni specifiche.
   • Risposta troppo complessa (F4): Soluzioni eccessivamente elaborate per compiti semplici.
3. Perdita di Contesto e Effetto Ridondante:
   • Mancanza di contesto (F5): Il modello dimentica le informazioni delle turni precedenti in conversazioni lunghe.
   • Risposta irrilevante (F6): Incomprensione delle query ambigue.
   • Non risposta ai cambiamenti del prompt (F9): Il modello continua a generare la stessa risposta nonostante le correzioni dell'utente.

B. Cause Sottostanti (RQ2)

Le cause sono state divise in:

• Contributo Utente (UC): Prompt vaghi, compiti delegati troppo complessi, scorrimento superficiale delle risposte, difficoltà nell'articolare i bisogni tecnici.
• Limiti Tecnici del Modello (CC): Ignorare il livello di competenza dell'utente, scarsa gestione dei file, incapacità di localizzare le modifiche nel codice, mancanza di verifica della correttezza, perdita del contesto conversazionale.
• Nota: Anche con il modello GPT-5.1, sebbene le risposte iniziali fossero migliori, i fallimenti nelle interazioni multi-turno (specialmente perdita di contesto e incoerenza nelle modifiche) sono rimasti prevalenti.

C. Strategie di Mitigazione (RQ3)

Gli utenti hanno tentato di mitigare i fallimenti con:

• Scaffolding del task (scomporre il compito in sottoparti).
• Chiarimento del prompt (riformulazione).
• Debug manuale dell'output del modello.
• Consultazione di fonti esterne (Google, StackOverflow).
• Tuttavia, 17 su 26 partecipanti hanno scelto di abbandonare ChatGPT a causa di fallimenti persistenti.

D. Fattori di Abbandono (RQ5) - Risultati Quantitativi

L'analisi di regressione logistica ha rivelato:

• Impatto delle Risposte Inutili: Le risposte classificate come "inutili" (unhelpful) aumentano la probabilità di abbandono di un fattore di 11 (Odds Ratio = 11) rispetto alle risposte utili.
• Effetto dei Prompt: Ogni prompt aggiuntivo riduce la probabilità di abbandono del 17%, suggerendo che la persistenza nell'iterazione è un indicatore di resilienza.
• Esperienza: Gli sviluppatori con più anni di esperienza coding sono meno propensi ad abbandonare.
• Prestazione del Task: Non è stata trovata una correlazione significativa tra il punteggio di completezza del task e la probabilità di abbandono; l'abbandono è guidato più dalla percezione di inutilità dell'interazione che dal risultato finale.

5. Significato e Implicazioni

• Natura dell'Abbandono: L'abbandono di un LLM non è una decisione binaria basata su un singolo errore, ma un processo dinamico guidato dall'accumulo di fallimenti interazionali e dal rapporto costo-beneficio (sforzo cognitivo vs. guadagno).
• Limiti dei Modelli Attuali: Anche i modelli più recenti (GPT-5.1) non risolvono i problemi fondamentali di coerenza multi-turno, gestione del contesto e localizzazione delle modifiche nel codice. Il miglioramento della qualità della risposta singola non garantisce una collaborazione affidabile in flussi di lavoro complessi.
• Progettazione di Strumenti: I futuri strumenti di IA per l'ingegneria del software devono andare oltre la semplice generazione di codice. Devono includere:
  • Meccanismi per mantenere il contesto a lungo termine.
  • Supporto per la localizzazione precisa delle modifiche nel codice.
  • Rilevamento proattivo di cicli di prompting improduttivi ("prompting rabbit-holes").
  • Adattamento delle risposte al livello di competenza dell'utente.
• Implicazioni Educative: Gli LLM attuali potrebbero ostacolare l'apprendimento profondo se gli utenti si affidano ciecamente alle risposte senza comprenderne la struttura, portando a un "over-reliance" che non sviluppa le competenze di problem-solving.

In conclusione, il paper evidenzia che per integrare efficacemente gli LLM nei flussi di lavoro SE, è necessario affrontare non solo la correttezza del codice generato, ma anche la robustezza dell'interazione, la gestione del contesto e la riduzione del carico cognitivo per l'utente durante le iterazioni di debug e raffinamento.