L’illusione di costruire software con l’AI senza prima costruire le fondamenta
Da qualche tempo, nelle aziende, si ripete una scena sempre più comune. Qualcuno presenta un’idea, magari ancora poco definita, e prima ancora di discutere requisiti, vincoli e impatto sul sistema esistente arriva la frase: “Che ci vuole? Con l’intelligenza artificiale possiamo farlo in pochi giorni“.
A volte è vero. Con gli strumenti disponibili oggi si può arrivare molto rapidamente a qualcosa che assomiglia a un prodotto: un’interfaccia credibile, alcune API, un database, persino un flusso completo che durante una dimostrazione sembra funzionare perfettamente. È facile rimanerne colpiti. Ancora più facile è convincersi che la parte difficile sia ormai finita.
In realtà, spesso è proprio in quel momento che inizia la parte difficile.
L’AI può generare codice a una velocità impressionante, ma scrivere codice e costruire software non sono la stessa cosa. Un prodotto aziendale non è soltanto un insieme di file che compilano o una schermata che risponde correttamente durante una demo. È un sistema che deve continuare a funzionare quando cambiano i requisiti, aumentano gli utenti, un servizio esterno non risponde, una dipendenza diventa vulnerabile o lo sviluppatore che lo ha avviato passa a un altro progetto.
Deve poter essere compreso, testato, monitorato, aggiornato e, quando qualcosa va storto, diagnosticato. Deve avere un’architettura coerente, responsabilità chiare e un gruppo di persone in grado di prendersene cura. Tutto questo non appare automaticamente solo perché il codice è stato prodotto da un modello molto avanzato.
Il rischio non è l’uso dell’intelligenza artificiale. Il rischio è usarla come scorciatoia per saltare il lavoro di ingegneria.
Quando la demo diventa una promessa
Il primo effetto dell’AI è quello di ridurre enormemente il tempo necessario per produrre qualcosa di visibile. Un’idea che prima avrebbe richiesto settimane per essere trasformata in un prototipo può prendere forma in pochi giorni, a volte anche in poche ore.
Questo è un vantaggio reale. Permette di verificare un’intuizione, raccogliere feedback e capire rapidamente se una direzione ha senso. Il problema nasce quando la velocità del prototipo viene scambiata per velocità di realizzazione del prodotto.
Una demo serve a dimostrare che un’idea può funzionare. Un prodotto deve dimostrare di poter continuare a funzionare nel mondo reale.
La differenza è enorme, ma durante l’entusiasmo iniziale tende a scomparire. Il prototipo viene mostrato al cliente, il cliente lo interpreta come qualcosa di quasi pronto e la direzione commerciale comincia a parlare di una data di consegna. In pochi passaggi, un esperimento diventa una promessa.
A quel punto il team di sviluppo riceve un sistema che è già stato implicitamente venduto. Gli sviluppatori devono renderlo sicuro, stabile e manutenibile, ma senza modificare le aspettative create dalla rapidità della prima demo. Devono aggiungere test, correggere l’architettura, sostituire dipendenze scelte senza criterio, inserire controlli di sicurezza, introdurre logging e monitoraggio. E devono farlo mentre continuano ad aggiungere funzionalità.
È come mostrare al cliente il rendering di un grattacielo e annunciare la data di inaugurazione prima di avere studiato il terreno su cui dovrà essere costruito.
La pressione a consegnare risultati mirabolanti, possibilmente “ieri”, non nasce con l’AI. Le aziende hanno sempre cercato di ridurre tempi e costi. L’intelligenza artificiale, però, rende questa illusione molto più credibile, perché produce rapidamente un risultato che sembra completo anche quando non lo è.
Il costo del lavoro mancante non scompare. Viene semplicemente spostato in avanti. Quello che non viene investito nell’analisi viene pagato durante le correzioni. Quello che si risparmia sui test viene pagato durante gli incidenti. Quello che non si documenta durante lo sviluppo viene ricostruito, con molta più fatica, mesi dopo.
Il software “consegnato ieri” viene quasi sempre pagato domani, e con gli interessi.
Il debito che nessuno vede: non sapere più cosa fa il proprio progetto
Il debito tecnico è un problema ben noto. Ogni volta che si sceglie una soluzione rapida ma fragile, si accetta implicitamente di pagare un costo futuro. È una scelta che può anche essere ragionevole, purché sia consapevole, limitata e gestita.
Con lo sviluppo assistito dall’AI si aggiunge però una forma di debito ancora più insidiosa: il debito di comprensione.
Accade quando il team possiede formalmente il codice, ma non possiede più il modello mentale necessario per governarlo.
Il progetto funziona, ma nessuno sa spiegare con chiarezza perché sia stato strutturato in quel modo. Una libreria è presente perché il modello l’ha proposta. Un componente comunica con un altro attraverso un meccanismo scelto durante una conversazione che nessuno ha conservato. Alcune decisioni architetturali non sono mai state prese davvero: sono semplicemente emerse dalla successione dei prompt.
Lo sviluppatore può leggere ogni singola funzione e, nonostante questo, non comprendere il sistema nel suo insieme. Non sa quali assunzioni siano state fatte, quali compromessi siano stati accettati e quali comportamenti dipendano accidentalmente da altri comportamenti.
Quando arriva una nuova richiesta, non si sa dove intervenire. Quando compare un errore, non si sa se correggere il sintomo o ripensare l’intera soluzione. Ogni modifica diventa pericolosa perché nessuno è certo delle conseguenze.
In queste condizioni, l’AI non ha eliminato la complessità. L’ha prodotta più rapidamente di quanto il team sia riuscito ad assimilarla.
Questo problema è particolarmente difficile da riconoscere perché non appare subito nelle metriche aziendali. La funzionalità risulta completata. La demo è stata approvata. Il cliente ha visto qualcosa che funziona. Nel breve periodo tutto sembra confermare che il progetto stia andando bene.
Il debito di comprensione emerge più tardi: durante la manutenzione, quando entra un nuovo sviluppatore, quando il sistema deve integrarsi con altri prodotti o quando un incidente richiede di ricostruire decisioni che non sono mai state documentate.
A quel punto la velocità iniziale diventa lentezza permanente.
L’AI, del resto, non conosce automaticamente il contesto dell’azienda. Non sa perché dieci anni prima sia stata presa una determinata decisione, quali vincoli normativi debbano essere rispettati, quali sistemi legacy non possano essere modificati o quali competenze siano realmente presenti nel team. Risponde sulla base delle informazioni che riceve e, quando quelle informazioni sono incomplete, colma i vuoti con soluzioni plausibili.
“Plausibile”, però, non significa necessariamente adatto.
Una risposta può essere tecnicamente corretta e al tempo stesso incompatibile con l’architettura aziendale, troppo costosa da gestire, difficile da monitorare o basata su strumenti che nessuno nel gruppo conosce. Il fatto che il codice compili non dimostra che quella sia la decisione giusta.
L’AI amplifica il processo che trova
Si parla spesso dell’intelligenza artificiale come di una tecnologia capace di trasformare qualsiasi organizzazione. In realtà, almeno nello sviluppo software, l’AI tende prima di tutto ad amplificare il processo nel quale viene inserita.
Parliamoci chiaro: in un’azienda con buone pratiche ingegneristiche può diventare uno strumento straordinario. Può aiutare a produrre test, esplorare soluzioni alternative, migliorare la documentazione, individuare problemi nel codice e accelerare attività ripetitive. Le sue proposte vengono sottoposte a revisione, verificate attraverso pipeline automatiche e valutate da persone che conoscono il sistema.
In un’organizzazione priva di queste fondamenta, l’AI accelera soprattutto il disordine.
Se non esistono standard architetturali, produrrà più velocemente soluzioni incoerenti. Se manca una strategia di test, aumenterà la quantità di codice non verificato. Se la documentazione è già trascurata, renderà ancora più ampia la distanza tra ciò che il sistema fa e ciò che il team sa spiegare. Se il processo di revisione è superficiale, diventerà più facile introdurre vulnerabilità, duplicazioni e dipendenze inutili.
L’AI non corregge automaticamente un processo debole. Gli permette di produrre più output.
Per questo l’adozione dell’intelligenza artificiale dovrebbe partire dal basso, dalle fondamenta che rendono sostenibile la velocità. Prima di generare decine di funzionalità, l’organizzazione dovrebbe avere chiarito come vengono definiti i requisiti, come si prendono e si documentano le decisioni architetturali, quali controlli devono superare le modifiche e chi è responsabile dei componenti.
Dovrebbe disporre di build riproducibili, test automatizzati, analisi statica, controllo delle dipendenze, procedure di distribuzione e possibilità di rollback. Dovrebbe sapere come osservare il sistema in produzione attraverso log, metriche e tracciamento degli errori.
Non sono attività spettacolari. Non producono la stessa impressione di una nuova applicazione costruita in un pomeriggio. Sono però ciò che permette a quell’applicazione di sopravvivere oltre la dimostrazione iniziale.
Dal prompt al processo
In questo contesto diventano interessanti metodi come BMAD Method, che cercano di inserire l’AI all’interno di un processo più strutturato, ispirato anche ai principi Agile.
L’idea di fondo è semplice: non chiedere a un singolo agente di passare direttamente da una frase generica al codice finale, ma organizzare il lavoro attraverso fasi, ruoli e artefatti comprensibili. Prima si analizza il problema, poi si chiariscono i requisiti, si definisce una soluzione, si suddivide il lavoro e infine si procede con l’implementazione e la verifica.
In un flusso di questo tipo, l’AI può assumere di volta in volta il ruolo di supporto all’analisi, alla definizione del prodotto, all’architettura, allo sviluppo o ai test. Non perché gli agenti virtuali possano sostituire completamente queste competenze, ma perché la separazione dei compiti riduce la tentazione di saltare direttamente al codice.
Il punto non è adottare obbligatoriamente BMAD o trasformare ogni progetto in una macchina burocratica piena di documenti. Anche un metodo ben strutturato può essere usato male. Può produrre specifiche formalmente impeccabili ma prive di valore, user story inutilmente dettagliate o architetture che nessuno ha davvero verificato.
Nessun framework elimina la necessità del giudizio umano.
Il suo valore sta piuttosto nel ricordare che tra l’idea e il codice devono esistere passaggi espliciti. Il contesto deve essere costruito, non immaginato. Le decisioni devono essere visibili. I criteri di accettazione devono essere definiti prima di dichiarare completata una funzionalità. Il lavoro deve essere suddiviso in unità che possano essere comprese, verificate e corrette.
Questa è anche la parte più importante dell’approccio Agile, spesso frainteso come una giustificazione per iniziare a sviluppare senza pianificare.
Agile non significa procedere senza una direzione. Significa pianificare e verificare in modo iterativo, mantenendo la capacità di correggere il percorso. Non elimina l’architettura, i requisiti o la responsabilità tecnica. Evita piuttosto di trattarli come documenti immutabili scritti una volta per tutte.
Applicato all’AI, questo principio è fondamentale. Non occorre progettare ogni dettaglio prima di scrivere una riga di codice, ma è necessario sapere quale problema si sta risolvendo, entro quali confini e con quali criteri si valuterà il risultato. Ogni iterazione dovrebbe aumentare non soltanto il numero di funzionalità, ma anche la comprensione condivisa del sistema.
L’AI deve quindi operare all’interno del processo di sviluppo, non sostituirlo.
Un metodo può aiutare a mantenere il contesto, ma non può garantire che quel contesto sia corretto. Può produrre una proposta architetturale, ma non può assumersi la responsabilità delle sue conseguenze. Può generare test, ma qualcuno deve stabilire se quei test rappresentino davvero il comportamento atteso.
La responsabilità finale rimane dell’organizzazione e delle persone che mettono il software in produzione.
Veloci rispetto a che cosa?
Quando un’azienda afferma di essere diventata più veloce grazie all’intelligenza artificiale, dovrebbe chiarire che cosa stia misurando.
Se misura il tempo necessario per arrivare a una demo, il miglioramento può essere enorme. Ma il time-to-demo racconta soltanto quanto rapidamente si riesca a produrre qualcosa di visibile.
Esiste un’altra misura, meno appariscente ma molto più importante: il tempo necessario per arrivare a un sistema sostenibile.
Un sistema è sostenibile quando può essere distribuito in modo prevedibile, quando dispone di test affidabili, quando i suoi problemi possono essere diagnosticati e quando il team sa modificarlo senza affidarsi alla fortuna. È sostenibile quando la sua manutenzione non dipende dalla presenza della persona che ha scritto il prompt originario.
L’AI può ridurre il tempo della demo da tre settimane a tre giorni e, contemporaneamente, aumentare il tempo necessario per rendere il prodotto sostenibile da tre mesi a sei. Può accadere quando il codice cresce più velocemente della documentazione, quando le decisioni vengono prese senza essere registrate o quando il team deve riscrivere ampie parti del prototipo per renderle adatte alla produzione.
In quel caso non abbiamo davvero accelerato il progetto. Abbiamo anticipato la parte visibile e posticipato il costo.
La vera produttività non si misura nella quantità di codice generato o nel numero di schermate mostrate al cliente. Si misura nella capacità dell’organizzazione di consegnare software affidabile e continuare a modificarlo senza perdere il controllo.
Per questo una regola dovrebbe rimanere non negoziabile: un team non dovrebbe mettere in produzione un sistema che non sia in grado di spiegare, diagnosticare e mantenere.
Non significa che ogni sviluppatore debba conoscere a memoria ogni riga. Significa che la conoscenza fondamentale deve appartenere al gruppo, non alla cronologia di una conversazione con un modello.
L’intelligenza artificiale rappresenta un’accelerazione straordinaria. Può liberare tempo, ridurre il peso delle attività ripetitive e permettere agli sviluppatori di concentrarsi su problemi più importanti. Ma proprio perché consente di costruire più rapidamente, richiede maggiore disciplina, non minore.
Prima di chiedere all’AI di aggiungere nuovi piani, dobbiamo assicurarci che qualcuno abbia progettato le fondamenta. Dobbiamo sapere quali materiali stiamo usando, chi controllerà la struttura e chi sarà in grado di intervenire quando comparirà la prima crepa.
L’AI ha cambiato gli strumenti con cui costruiamo software. Non ha eliminato la necessità di sapere ed essere in controllo di che cosa stiamo costruendo.