Intelligenza artificiale e sviluppo software: perché il prompt engineering non sostituirà i programmatori
L’illusione manageriale del “no-code intelligente” e i rischi strategici per le aziende nei prossimi 10 anni
L’intelligenza artificiale nello sviluppo software sta creando una narrativa molto seducente per i livelli manageriali: l’idea che la programmazione possa essere “semplificata” a tal punto da sostituire la scrittura di codice con la scrittura di prompt. Una prospettiva affascinante, perché promette riduzione dei costi, accelerazione delle roadmap, autonomia dei team non tecnici, minore dipendenza da competenze specialistiche e sviluppo “magico” determinato dal linguaggio naturale.
Tuttavia, questa visione è profondamente distorsiva e rappresenta una delle maggiori minacce strategiche per le aziende nei prossimi 5-10 anni, perché è una proiezione, non un futuro realistico.
Prompt engineering e programmazione: una confusione pericolosa
L’idea seducente che sta circolando nell’industria tech è il “prompt engineering” come nuova forma di programmazione. Secondo questa visione, presto non avremo più bisogno di programmatori tradizionali, ma di “orchestratori” capaci di dialogare con l’AI. La logica? La produce l’AI, l’architettura emerge automaticamente, il codice diventa una semplice commodity.
Ma c’è un problema fondamentale: questa narrativa confonde la scrittura del codice con l’ingegneria del software. Quando parliamo di costruire sistemi reali, production-ready, ci troviamo di fronte ad una serie di sfide che nessun prompt, per quanto ben scritto, può affrontare.
Complessità e determinismo nell’ingegneria del software
Un sistema software deve comportarsi in modo prevedibile. La complessità ciclomatica, l’idempotenza delle operazioni, la gestione dello stato distribuito non sono dettagli implementativi: sono decisioni architetturali che richiedono una comprensione profonda del problema e delle sue implicazioni.
Esistono aspetti come sicurezza e affidabilità, dove il threat modeling, la gestione delle eccezioni, i contratti tra servizi e il typing rigoroso rappresentano meccanismi di difesa contro l’entropia dei sistemi complessi. Questi elementi non possono emergere spontaneamente da una conversazione con un modello linguistico.
Sicurezza, scalabilità e compliance dei sistemi informatici
Scalabilità, sostenibilità, compliance e osservabilità non sono temi che possono essere “banalizzati”. Come si scala orizzontalmente un sistema? Come si mantiene nel tempo? Come si modella il dato in modo che resti coerente attraverso anni di evoluzione? Come si gestisce il refactoring senza compromettere funzionalità esistenti?
In contesti regolamentati, ogni decisione architetturale deve essere tracciabile, auditabile, giustificabile. L’osservabilità non è un add-on: è una proprietà emergente di un sistema ben progettato.
Competenze tecniche IT: cosa significa davvero programmare
La programmazione non è mai stata principalmente la scrittura di codice. È progettazione di sistemi, capacità di modellare problemi complessi in strutture gestibili, anticipare casi limite e comportamenti emergenti, bilanciare trade-off tra performance e manutenibilità, pensare in termini di invarianti e garanzie, comprendere le implicazioni di lungo termine nelle scelte architetturali.
L’AI generativa può certamente accelerare la produzione di codice boilerplate, suggerire implementazioni, aiutare con la sintassi. Ma non può sostituire la capacità di pensare il sistema.
Ridurre la programmazione a prompt engineering è come dire che una laurea in architettura serve solo a saper usare AutoCAD, o che la laurea in medicina serve solo a prescrivere farmaci. È una semplificazione che sottovaluta la profondità della disciplina, crea false aspettative nei non-tecnici e rischia di produrre sistemi fragili e non manutenibili.
Il paradosso dell’AI nello sviluppo software: probabilità vs determinismo
Ignorare decenni di best practice nell’ingegneria del software non è la strada giusta. L’AI è uno strumento potente, può democratizzare molti aspetti dello sviluppo software, accelerare processi, ridurre friction, ma come ogni strumento, la sua efficacia dipende da chi lo usa e dalla profondità della sua comprensione.
Michelangelo con martello e scalpello ha creato opere d’arte; se date gli stessi strumenti all’AI creerà la media ponderata di tutte le sculture mai viste. Sicuramente potrà sorprendere, ma è solo qualcosa che assomiglia ad un’opera d’arte, perché è realizzata senza avere la consapevolezza della bellezza.
L’AI non elimina, ma amplifica la necessità di competenze tecniche. L’AI è probabilistica, i sistemi sono deterministici. I modelli generativi operano nella sfera dell’incertezza; i sistemi software moderni richiedono invece determinismo, prevedibilità, riproducibilità. Un paradosso ingegneristico che solo gli sviluppatori possono risolvere stratificando: validazione, normalizzazione, sandboxing, controlli sintattici e semantici.
Nuovi failure modes nell’automazione software aziendale
L’AI introduce failure modes nuovi e più pericolosi. Con l’AI emergono errori silenziosi, allucinazioni strutturate, output formalmente corretti ma semanticamente errati, derive logiche nel tempo, dipendenza dal training data, deterioramento delle performance con il drift dei modelli, senza parlare delle vulnerabilità di prompt-injection.
Queste failure non sono “bug” tradizionali: sono problemi sistemici che richiedono esperienza di ingegneria del caos, modellazione del rischio, governance del ciclo del modello, infrastructure resiliency. Nessun prompt può sostituire queste capacità.
L’AI scrive codice, ma non progetta architetture. Un LLM può produrre funzioni, classi, micro-implementazioni, ma non può progettare un modello di dominio coerente, la gestione concorrente, il modello di error handling, una pipeline di scaling affidabile, la separazione delle responsabilità o boundary tra microservizi. Questi elementi non emergono dal linguaggio naturale: emergono dalla conoscenza profonda dell’ingegneria.
Debito tecnico generativo: il rischio strategico nascosto
Il rischio strategico per manager e amministratori è la decrescita delle competenze. Se un’azienda sposa la narrativa del “codice scritto dall’AI”, vede un vantaggio immediato: riduzione apparente della dipendenza dagli sviluppatori. Nel breve periodo questo può sembrare efficiente; nel lungo periodo è devastante.
Gli sviluppatori diventano operatori di AI, non ingegneri. Si ha inevitabilmente un’erosione delle skill: si perdono le capacità di leggere criticamente il codice, identificare bug strutturali, costruire architetture scalabili, ottimizzare performance o garantire la sicurezza del software.
Ma un aspetto ancora più grave è il lock-in cognitivo: l’azienda diventa progressivamente dipendente da modelli, provider, workflow “opachi”, output non riproducibili. Quando la complessità diventa ingestibile, non esistono più skill interne per intervenire.
Il debito tecnico generativo, codice generato senza governance, cresce in modo esponenziale: sistemi ingestibili, vulnerabilità non tracciabili, performance degradate, dipendenza totale da consulenti esterni. L’incubo di qualsiasi manager coscienzioso.
No-code e low-code: l’illusione del controllo
Negli ultimi anni, piattaforme come n8n, Zapier, Make (ex Integromat) e una miriade di altri strumenti no-code o low-code stanno conquistando aziende e professionisti, che stanno vivendo una specie di speculazione “softeristica”, pensando e avendo l’illusione di poter realizzare, grazie all’AI, qualsiasi software e acquisire tramite essa competenze senza la necessità di una disciplina della materia.
Queste piattaforme promettono automazioni rapide, integrazioni immediate e la possibilità di “programmare senza programmare”. E grazie all’integrazione con l’intelligenza artificiale, la loro narrazione si è rafforzata: creare processi intelligenti senza scrivere codice sembra finalmente possibile. Il tormentone è sempre lo stesso: l’AI scriverà il codice al posto nostro, e questo tipo di applicazioni saranno la nuova normalità.
Il problema è che l’abuso di strumenti superficiali genera un progressivo appiattimento delle competenze: pensiamo che la logica dell’AI sia magica, accettiamo processi che non comprendiamo, smettiamo di approfondire come funzionano i sistemi, ci abituiamo ad un livello di astrazione così alto da non poter più intervenire davvero. È questa la più grande minaccia: una generazione di professionisti convinta di controllare l’AI senza capirne i meccanismi.
Dipendenza dal cloud computing: la lezione dei blackout 2025
Questo fenomeno non è nuovo: lo abbiamo già visto con il cloud computing. Negli ultimi dieci anni è emersa una generazione di sistemisti “cloud-nativi” che sono cresciuti esclusivamente con AWS, Azure o Google Cloud. Sanno gestire container, orchestrare Kubernetes, configurare servizi gestiti, scalare automaticamente le risorse.
Ma se gli chiedi di installare un server Exchange on-premise, configurare una Active Directory su un server Windows fisico, o gestire una SAN tradizionale, vanno letteralmente in crisi. Non è una critica alle loro competenze cloud, che sono spesso eccellenti. È la constatazione di una lacuna fondamentale: questi professionisti hanno saltato completamente i “fondamentali”.
Non hanno mai dovuto configurare manualmente protocolli di rete, debuggare problemi di DNS a livello di sistema, gestire storage fisico, comprendere le implicazioni di latenza su hardware reale, o risolvere conflitti di risorse su macchine condivise. Non sono in grado di rendere autonoma un’organizzazione dal cloud.
Tre blackout devastanti in un mese: AWS, Azure e Cloudflare
Le conseguenze di questa dipendenza totale dal cloud si sono manifestate drammaticamente nel 2025. Tra ottobre e novembre, nell’arco di appena un mese, tre blackout devastanti hanno colpito l’internet globale:
AWS, 20 ottobre 2025: oltre 15 ore di disservizio causate da una race condition nel sistema DNS automatizzato di DynamoDB che ha svuotato i record DNS per l’endpoint regionale. Servizi colpiti: Signal, Snapchat, Lyft, Roblox, Fortnite, Alexa, EC2, Lambda.
Microsoft Azure, 29 ottobre 2025: circa 8 ore di interruzione dovuta a una configurazione errata in Azure Front Door che ha causato il malfunzionamento di numerosi nodi globali. Servizi colpiti: Microsoft 365, Teams, Xbox Live, Minecraft, Azure Portal.
Cloudflare, 18 novembre 2025: circa 6 ore di downtime provocato da una modifica ai permessi del database che ha raddoppiato le dimensioni di un file di configurazione critico per il sistema Bot Management. Servizi colpiti: X, ChatGPT, Spotify, Discord, Claude AI, Truth Social.
La cosa più allarmante? In tutti e tre i casi, i guasti sono derivati da errori interni nella configurazione e nel software delle infrastrutture core dei provider, non da attacchi esterni. E nessuna di queste organizzazioni aveva sistemi di backup on-premise funzionanti.
Quando il cloud è collassato, non c’era piano B. Nessun fallback locale, nessuna ridondanza fisica, nessuna capacità di continuare a operare in autonomia. Intere aziende si sono trovate completamente paralizzate, impotenti, in attesa che giganti tecnologici risolvessero problemi su cui non avevano alcun controllo.
Questo è il rischio concreto di una generazione che ha dimenticato, o mai imparato, come gestire infrastrutture indipendenti. Quando il livello di astrazione fornito dal cloud funziona, sono efficienti. Ma quando qualcosa va storto sotto quel livello di astrazione, quando il problema risiede in qualcosa che il pannello di controllo non mostra, quando è necessario comprendere cosa sta realmente accadendo “sotto il cofano”, si trovano spiazzati. Hanno imparato a orchestrare servizi, non a capire come quei servizi funzionano internamente.
I limiti strutturali delle piattaforme no-code
Similarmente, dietro promesse e sensazionalismi come il “vibe coding” si nasconde una realtà più complessa e molto meno comoda. Questi strumenti rappresentano una parte della gigantesca bolla narrativa dell’AI — una bolla che rischia di farci credere che la programmazione non sia più necessaria, che il controllo dei sistemi possa essere delegato a un’interfaccia visuale e che l’AI possa sostituire la comprensione tecnica.
In realtà, la storia ci insegna che, quando la tecnologia diventa più sofisticata, solo chi padroneggia la logica, l’architettura e il codice è davvero in grado di governarla.
Applicazioni come n8n, osannate sui social network, sono ottime per la didattica, per fare prototipi, piccoli workflow e automazioni operative, ma non possono essere considerate in processi critici, complessi o ad alto carico perché soffrono di limiti evidenti: dipendenza da un engine centrale, gestione delle eccezioni non nativa come nel software scritto a mano, performance legate al design del motore e non alle esigenze del progetto.
È la differenza tra montare Lego e costruire un edificio antisismico: la struttura visuale non è pensata per scenari limite.
La promessa è ridurre la complessità, ma spesso ciò che sparisce dall’interfaccia si ripresenta in altre forme: workflow difficili da versionare, debugging quasi impossibile quando un flusso si espande, logica distribuita tra decine di nodi difficili da tracciare, dipendenza totale dal motore dell’applicazione. Un sistema facile da creare e difficile da mantenere.
Gli strumenti low-code danno una falsa percezione di controllo e di potere: sposti blocchi, colleghi input e output, vedi subito una risposta. Ma si tratta spesso di un controllo superficiale: si lavora dentro limiti stabiliti dallo strumento, non si vedono i veri errori o colli di bottiglia e non si controlla davvero cosa accade negli strati sottostanti. In altre parole: hai le chiavi della macchina, ma il motore è sigillato.
AI-Augmented Engineers: il futuro delle competenze tecniche
L’AI è un moltiplicatore di competenze. Il futuro vincente è molto diverso dalla fantasia del “prompt-only”. Le aziende che prospereranno saranno quelle che comprenderanno che l’AI deve essere integrata come una parte della pipeline, non come sostituto della pipeline.
Gli sviluppatori devono diventare “AI-Augmented Engineers”, non prompt writer. La programmazione non svanirà: si evolverà verso livelli più alti di astrazione.
L’AI potenzia gli ingegneri capaci e penalizza i team privi di visione tecnica. L’AI eleva l’asticella: non abbassa la soglia di ingresso, ma alza la soglia di comprensione richiesta.
La verità tecnica che molti manager non vedono, o non vogliono vedere, è che gli sviluppatori del futuro continueranno a scrivere codice, analizzeranno il codice generato, metteranno guardrail ai modelli, costruiranno architetture e continueranno a fare debugging di pipeline complesse. “Scrivere prompt” è una micro-attività: chi pensa che “basta il prompt” rimarrà schiacciato dalla complessità reale dei sistemi basati su AI.
L’AI non sta eliminando il ruolo degli sviluppatori. Sta eliminando gli sviluppatori che non capiscono cosa stanno facendo. Sta funzionando come un acceleratore evolutivo professionale. Non elimina il valore della cognizione umana: la moltiplica quando è genuina e la elimina quando simulata.
Gli sviluppatori che “googlavano” soluzioni e le incollavano sono sostituibili. Quelli che capiscono architetture, trade-off, contesto di business e sanno usare l’AI come strumento di amplificazione cognitiva sono i nuovi “senior”, anche se giovani.
La discriminante finale non è più “quanti anni di esperienza hai” ma quanto profondamente capisci ciò che fai e sai adattarti a strumenti che cambiano settimanalmente.
Conclusione: il futuro appartiene a chi integra, non a chi delega
Le aziende tech stanno dimostrando nei fatti di preferire dieci professionisti che comprendono a fondo ciò che fanno rispetto a cento che eseguono in modo meccanico. L’AI ha reso economicamente insostenibile mantenere questi ultimi.
Ma l’idea che il software del futuro sarà costruito “solo a colpi di prompt” è una semplificazione pericolosa: rischia di impoverire le competenze, ridurre la resilienza organizzativa e aumentare i rischi, producendo sistemi sempre più opachi e difficili da governare.
Perché alla fine, quando il sistema crasha in produzione alle 3 del mattino, quando i costi cloud esplodono, quando la sicurezza viene compromessa, quando il codice diventa impossibile da manutenere, nessun prompt risolverà quei problemi. Servirà qualcuno che capisca davvero come funzionano i sistemi.
Il futuro appartiene a chi saprà integrare l’AI nella propria professionalità, non a chi immagina di rimpiazzare le competenze umane con una semplice interfaccia testuale o interattiva.
Progettista di sistemi esperti, software developer, network e system engineer, con oltre 30 anni di esperienza nell’ambito della sicurezza delle informazioni, Francesco Arruzzoli è il Resp. del Centro Studi Cyber Defense Cerbeyra, dove svolge attività di R&D, analisi delle cyber minacce e progettazione di nuove soluzioni per la cyber security di aziende ed enti governativi. Esperto di Cyber Threat Intelligence e contromisure digitali, autore di libri ed articoli sue riviste del settore, in passato ha lavorato per multinazionali, aziende della sanità italiana, collaborato con enti governativi e militari. In qualità di esperto cyber ha svolto inoltre attività di docenza presso alcune università italiane.
