Usare l’AI per costruire software o costruire software di AI?
Sono due domande diverse e oggi spesso le si confonde: quasi tutta la letteratura risponde alla seconda.
Il post in tre frasi
Sotto l’espressione “costruire software con l’AI” convivono due domande diverse: come usare l’AI nello sviluppo di un sistema informatico e come costruire un prodotto basato su un modello di AI.
Quasi tutta la letteratura degli ultimi due anni risponde alla seconda, e chi cerca risposte alla prima trova indicazioni che sembrano incoerenti.
Rispondere alla prima significa riprendere il patrimonio dell’ingegneria del software e riadattarlo ai nuovi strumenti: un lavoro che non è ancora stato fatto.
Il 12 agosto Matteo Giuliani ha posto su X una richiesta molto interessante che fa emergere una questione chiave:
Sto cercando (forse non esiste ancora) un insieme di BP da utilizzare quando si progetta/scrive sw usando AI. Trovo sul web molte indicazioni, spesso non organiche, che non sempre mi sembrano compatibili. Vorrei una guida sufficientemente sintetica per chiarirmi le idee.
Poco prima aveva usato queste parole: “sto navigando a vista e non mi piace”. E ancora: “leggo di qua, leggo di là (probabilmente troppo) e alla fine ne capisco sempre meno”.
La risposta può risultare banale: quella guida non esiste1. Non è però interessante segnalarne semplicemente l’assenza, quanto discutere la ragione per cui manca. E la ragione è che sotto la stessa espressione “costruire software con l’AI” convivono due domande/risposte diverse.
La prima domanda: usare l’AI mentre si sviluppa
Matteo chiede pratiche da usare quando si progetta e si scrive software e le chiede organiche, coerenti fra loro, componibili, tali da reggere casi industriali e non solo proof of concept. L’AI è lo strumento con cui si lavora. Il prodotto finale può essere un gestionale, un sistema di controllo, un’app mobile o un portale.
Questa prima domanda è quella che si deve costruire e mantenere un sistema e vuol capire come innovare il proprio modo di lavorare alla luce della disponibilità dei nuovi strumenti di sviluppo basati sull’AI. Il materiale che trova online non risponde a queste domande perché è spesso scritto da chi sta risolvendo un problema diverso dal suo.
La seconda domanda: costruire un prodotto fatto di AI
Alla domanda di Matteo ha risposto Mirko Voltolini, suggerendo “AI Engineering: Building Applications with Foundation Models” di Chip Huyen. È un suggerimento ragionevole: quel libro è il testo di riferimento sull’argomento, è ben fatto e il titolo sembra promettere esattamente ciò che Matteo cerca.
L’indice include i seguenti temi: prompting, retrieval, agenti, fine-tuning, dataset, inferenza, valutazione. Sono i passaggi necessari per adattare un LLM a uno specifico scopo applicativo. Il punto è che “costruire applicazioni” in quel contesto significa qualcosa di molto specifico e diverso rispetto al problema sollevato da Matteo. Quel libro discute di come costruire tutto ciò che sta sopra un modello LLM. Non parla di come usare l’AI per la costruzione di applicazioni nell’ampiezza e nell’accezione tipiche dell’ingegneria del software: requisiti, architettura, integrazione con i sistemi esistenti e con i processi aziendali, testing, evoluzione e manutenzione, organizzazione e gestione dei team di sviluppo. Alcuni capitoli si avvicinano a queste tematiche (la scelta dei casi d’uso, il ruolo rispettivo di AI e persone, l’architettura di un sistema in produzione con guardrail e monitoraggio), ma l’impianto e l’approccio restano quelli del progettista di sistemi di AI, anziché quelli dell’architetto di sistemi informatici che vuole usare l’AI per innovare il proprio modo di lavorare.
La ragione è strutturale e non riguarda la bravura di chi ha scritto quel libro. Quasi tutta la letteratura degli ultimi due anni si concentra su applicazioni intese come “strati applicativi basati su un LLM”. Nella realtà organizzativa, le applicazioni basate su componenti di AI fanno parte di un sistema informativo molto più ampio. I costi e i fallimenti risiedono nell’intero sistema, non tanto e non solo nel componente AI.
Matteo non ha cercato male e chi gli ha risposto non gli ha dato un cattivo consiglio. La letteratura disponibile spiega quasi sempre come costruire applicazioni di AI: non è la stessa cosa. I pezzi non si incastrano perché rispondono a due problemi diversi, per due lettori diversi.
La conferma è arrivata da Matteo stesso che, dopo aver guardato l’indice, scrive: “leggendo dettagli sul libro avevo intuito che il focus fosse quello, dunque non proprio ciò che mi interessa ora”.
Cosa succede quando la prima domanda resta senza risposta
Cal Newport ha raccontato pochi giorni fa una storia molto interessante derivata da uno scambio di mail con un suo lettore, un ingegnere senior della Silicon Valley che usa l’AI per scrivere software di tipo generale.
A gennaio aveva ricevuto una prima mail: scettico convertito, l’ingegnere aveva abbandonato l’ambiente di sviluppo tradizionale e lavorava esclusivamente tramite Claude Code. “Overnight, it changed the way I do my job”, aveva scritto: un compito che prima gli costava una settimana ora richiedeva solo due giorni.
Sette mesi dopo lo stesso ingegnere ha scritto di nuovo. Due funzionalità generate secondo queste nuove modalità di lavoro avevano causato il crash del prodotto. Il suo capo gli aveva detto che un terzo incidente avrebbe comportato il licenziamento. “I’ve never had quality issues like this before in my career.”
Il meccanismo che descrive non riguarda la qualità del modello. Il codice prodotto da un agente sembra ragionevole, ma può contenere errori difficili da individuare e va quindi rivisto con attenzione. Tuttavia, capire il codice che non si è scritto è notoriamente faticoso, e la revisione diventa il passaggio che si tende a saltare o sottovalutare, soprattutto se si insegue l’obiettivo della maggiore velocità di sviluppo.
Le esperienze sul campo che si stanno consolidando puntano nella stessa direzione (come ho scritto parlando del ruolo dell'ingegneria del software e della differenza fra coding e ingegneria del software). E chi lavora nelle aziende aggiunge la parte relativa alla responsabilità. In una rassegna di CIO, una manager di un fornitore di sviluppo afferma: “I nostri clienti non pagano per il codice grezzo; pagano per il giudizio, l’architettura, le integrazioni complesse e la responsabilità. Non risolvi tutto questo con un prompt” (traduzione mia).
Cosa cercare, allora
Le due domande hanno risposte diverse e conviene tenerle separate invece di cercare un’unica lettura che le spieghi entrambe.
Se il problema è usare l’AI nello sviluppo di software, cioè la domanda di Matteo, i temi da discutere riguardano il processo di ingegneria del software, rivisto alla luce dei nuovi strumenti.
Se il problema è costruire un prodotto basato sull’AI, cioè la domanda a cui il libro segnalato risponde, i temi riguardano il sistema attorno al modello e sono quelli di cui parla la letteratura corrente.
Ecco perché è necessario essere precisi, ricordare la storia e i risultati della ricerca in informatica (e in ingegneria del software), e valorizzare tutto il know-how sviluppato nei decenni scorsi: si evita di “reinventare la ruota” o, peggio, di confondere i problemi e le relative soluzioni.
Questo post è stato scritto con l’assistenza di Claude. Le idee, le posizioni e il ragionamento sono miei.
Fonti
Matteo Giuliani (@mgiul26), Cristian Mesiano (@Cr1st14nM3s14n0) e Mirko Voltolini (@mvoltoli), scambio su X, 12 agosto 2026
Chip Huyen, AI Engineering: Building Applications with Foundation Models, O’Reilly, dicembre 2024
Cal Newport, On AI Coding and Its Discontents, agosto 2026
AI Is Altering the Economics of Software Development, but Who Gets a Cut?, CIO, 31 marzo 2026
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it
Al Politecnico abbiamo scritto un nuovo libro di ingegneria del software — M. Camilli, E. Di Nitto, A. Fuggetta, A. Margara, M. Rossi, D. A. Tamburri, Software Engineering. A Structured Journey from Inception to Delivery, Bocconi University Press, 2025 — che contiene alcuni commenti sull’uso dell’AI: una prima lettura, che necessita certamente di ulteriori approfondimenti.