Scrivere codice è solo una parte dell'ingegneria del software, e la parte che gli LLM fanno meglio. Quello che li limita è la capacità di costruire e mantenere modelli mentali chiari: su questo ruota l'articolo Why LLMs Can't Really Build Software di Conrad Irwin, pubblicato sul blog di Zed il 14 agosto 2025. Riprendo qui i suoi argomenti, con alcune osservazioni.

Cosa fanno gli ingegneri efficaci

L'autore ha avuto occasione di intervistare molti ingegneri del software, e questo lo ha portato a riflettere su cosa facciano davvero quelli efficaci. Osservando chi conosce il mestiere, si vede ripetere un ciclo:

  1. costruire un modello mentale dei requisiti;
  2. scrivere codice che si adatti a quei requisiti;
  3. costruire un modello mentale di ciò che il codice fa effettivamente;
  4. identificare le differenze e aggiornare il codice o i requisiti.

Esistono molti modi di svolgere queste attività. Ciò che distingue gli ingegneri efficaci è la capacità di costruire e mantenere modelli mentali chiari.

Dove gli LLM si confondono

Gli LLM sono bravi a scrivere codice e abbastanza abili ad aggiornarlo quando individuano un problema. Possono fare tutto ciò che fa un ingegnere: leggere il codice, scrivere ed eseguire test, aggiungere log, usare un debugger. Non riescono invece a mantenere modelli mentali chiari, e il risultato è una confusione costante:

  • presumono che il codice che hanno scritto funzioni davvero;
  • quando un test fallisce, devono indovinare se correggere il codice o il test;
  • quando la frustrazione sale, cancellano tutto e ricominciano da capo.

È l'opposto di ciò che si cerca in un ingegnere. Chi lavora bene testa man mano che procede. Quando un test fallisce, consulta il proprio modello mentale per decidere se correggere il codice o il test, oppure se raccogliere altri dati prima di scegliere. Quando la frustrazione si fa sentire, ne parla con altri. Può anche cancellare tutto e ripartire, ma lo fa con una comprensione più chiara del problema.

Il contesto e i tre limiti dei modelli

Cambierà qualcosa con modelli sempre più avanzati? Forse, ma secondo l'autore servirà un cambiamento nel modo in cui i modelli vengono costruiti e ottimizzati, perché l'ingegneria del software richiede molto più che generare codice. Una persona che incontra un problema sa mettere da parte temporaneamente il contesto completo, concentrarsi sul problema e poi richiamare il contesto per tornare alla questione principale. Sa anche allargare lo sguardo sull'insieme, lasciando che i dettagli scompaiano, e approfondire i singoli pezzi quando serve. Non aggiungiamo continuamente elementi al contesto, perché ci renderebbe pazzi.

Anche a prescindere dalla quantità di contesto, i modelli generativi attuali hanno tre problemi che incidono direttamente sui modelli mentali:

  1. Omissione di contesto. Faticano a individuare ciò che manca nel contesto.
  2. Effetto di recentità. Danno un peso eccessivo a ciò che compare per ultimo nella finestra di contesto.
  3. Allucinazioni. Generano comunemente dettagli che non dovrebbero esserci.

Questi problemi non sono necessariamente insormontabili, e si sta lavorando per dare ai modelli una memoria che permetta trucchi mentali simili ai nostri. Al momento però, oltre una certa complessità, i modelli non comprendono davvero ciò che accade: non riescono a tenere due modelli mentali, quello dei requisiti e quello del codice, a confrontarli e a decidere se aggiornare l'uno o l'altro.

Dove gli LLM servono comunque

Gli LLM sono utili agli ingegneri del software. Generano codice rapidamente e sono eccellenti nel sintetizzare requisiti e documentazione. Per alcune attività basta: i requisiti sono abbastanza chiari e il problema abbastanza semplice da risolvere in un colpo solo. Per qualsiasi cosa non banale, però, l'articolo sostiene che i modelli non riescono a tenere abbastanza contesto, con sufficiente precisione, per arrivare iterando a una soluzione funzionante. La responsabilità di requisiti chiari e di verificare che il codice faccia ciò che dichiara resta dell'ingegnere.

Zed immagina persone e agenti che costruiscono software insieme, ma per ora, dice, è l'umano a stare al posto di guida e l'LLM è uno strumento in più a cui ricorrere. La stessa linea si ritrova in Programmare con gli LLM: l'aggiornamento di Antirez.

Il punto pratico

Il consiglio pratico che se ne ricava riguarda la parte umana del lavoro: tenere chiari i requisiti, controllare il codice scritto dal modello contro quei requisiti e non delegare il confronto tra ciò che volevamo e ciò che è stato scritto. È questa la capacità che definisce il programmatore, e nessuno strumento al momento la sostituisce.

Fonte: Conrad Irwin, Why LLMs Can't Really Build Software, blog di Zed, 14 agosto 2025.