Quando l’intelligenza artificiale incontra la realtà del codice

Immaginate di costruire un grattacielo chiedendo a qualcuno che non ha mai visto un edificio di descrivere come farlo, basandosi solo su fotografie casuali trovate online. Ora immaginate che questa persona abbia anche la tendenza a confondere occasionalmente le istruzioni per fare una torta con quelle per assemblare mobili. Benvenuti nel mondo della generazione automatica di codice tramite intelligenza artificiale.

La rivoluzione che è sempre dietro l’angolo

Dal 2022 viviamo in uno stato di rivoluzione permanente. Ogni sei mesi qualcuno annuncia che “questa volta è diverso”, che “tra poco tutto cambierà”, che “lo sviluppo software come lo conosciamo è già morto”. Eppure, stranamente, le aziende continuano ad assumere sviluppatori, i bug continuano a esistere, e i sistemi critici continuano a essere scritti da esseri umani che capiscono cosa stanno facendo.

L’ecosistema dei social media ha partorito una nuova categoria professionale: l’influencer tecnologico che vende corsi su come l’AI scriverà tutto il codice al posto vostro. Il sospetto che molti di questi corsi siano stati generati dall’AI stessa, senza mai essere testati su progetti reali, è più che legittimo. I segnali sono sempre gli stessi: “sta rivoluzionando”, “sta ridefinendo”, “è già in corso”, “[inserire qui qualsiasi pratica consolidata] è già morta”.

Nel frattempo, nella realtà quotidiana delle aziende tecnologiche, gli sviluppatori continuano a scrivere codice, debuggare sistemi complessi, e rispondere a email con tempi di tre settimane (anche se teoricamente la produttività è aumentata del numero-a-caso percento).

L’approccio probabilistico incontra la logica rigida

La natura probabilistica dell’AI si scontra violentemente con la natura deterministica del codice. Mentre un testo può essere riformulato in mille modi mantenendo lo stesso significato, il codice deve rispettare regole sintattiche e logiche precise per funzionare. Non esistono interpretazioni creative quando un punto e virgola mancante manda in crash un’intera applicazione.

L’AI eccelle quando il problema è circoscritto e ben definito. Serve un algoritmo che ordini un array di stringhe secondo criteri specifici? Perfetto, il codice generato sarà probabilmente impeccabile. Ma il vero lavoro di sviluppo raramente consiste in problemi così isolati e semplici.

Quando la complessità aumenta, l’approccio probabilistico mostra tutti i suoi limiti. L’AI inizia a produrre collage di soluzioni pescate dal suo training set, spesso incompatibili tra loro. Mischia librerie diverse perché “probabilisticamente fanno cose simili”. Invoca funzioni che non esistono perché “nel mondo esiste qualcosa di simile”. Suggerisce dipendenze obsolete perché erano popolari quando i dati di training sono stati raccolti.

Il risultato? Codice che compila solo nella migliore delle ipotesi, che usa API incompatibili, che introduce vulnerabilità di sicurezza replicando pattern non sicuri trovati chissà dove. L’AI non comprende il contesto globale del progetto, non può valutare le implicazioni architetturali a lungo termine, non sa distinguere tra best practice e soluzioni approssimative.

Il catalogo delle giustificazioni

Chiunque abbia sollevato dubbi sull’affidabilità dell’AI per generare codice si è trovato sommerso da un repertorio standardizzato di risposte. Eccone alcune particolarmente popolari.

“Devi imparare a usarlo meglio” trasferisce la responsabilità dell’errore dall’AI all’utente. Se l’output è sbagliato, evidentemente hai formulato male la richiesta. “È solo uno strumento” minimizza i problemi reali presentando l’AI come un martello neutro, ignorando che questo martello a volte decide autonomamente dove piantare chiodi immaginari.

“Sta migliorando continuamente” promette un futuro radioso sempre a sei mesi di distanza. “Anche gli umani sbagliano” è tecnicamente vero, ma gli umani non sbagliano con la sicurezza enciclopedica di un sistema che presenta allucinazioni come fatti consolidati.

Poi c’è il gioco delle tre carte: “Quale AI hai usato?” Qualunque cosa tu abbia provato, esisteva sempre il modello perfetto che non conoscevi, la versione giusta, il parametro magico che avresti dovuto impostare. “Fammi vedere il prompt” trasforma il fallimento in un problema di comunicazione: troppo breve? Dovevi dare più contesto. Troppo dettagliato? L’hai confuso con troppe informazioni.

Il preferito rimane “Un controllo umano ci va sempre”, il perfetto capovolgimento narrativo: quando funziona è una rivoluzione che sostituirà gli sviluppatori, quando fallisce è solo un assistente che ovviamente richiede supervisione umana.

Il vibe coding e la programmazione a intuito

Nasce così una nuova figura professionale: il vibe coder. Copia-incolla blocchi di codice generato dall’AI senza capirne il funzionamento, lo inserisce nel progetto con la nonchalance di chi aggiunge emoji a un messaggio, e spera che funzioni. Non importa comprendere cosa fa quel codice, l’importante è la vibrazione positiva che emana.

Quando inevitabilmente emergono bug, la soluzione è geniale: si chiede all’AI di risolvere i problemi che ha creato. Si innesca così una spirale discendente dove codice incomprensibile viene rattoppato con altro codice incomprensibile, creando capolavori di opacità stratificata. L’illusione è che dopo qualche ciclo di generazione-debug-fix si ottenga magicamente codice pulito e sicuro. È come credere che mischiando ingredienti a caso prima o poi uscirà un piatto stellato.

Gli sviluppatori senior osservano questo fenomeno con un misto di orrore e rassegnazione. Sanno che toccherà a loro pulire quando il castello di carte crollerà. Sono come genitori che guardano il figlio fare disastri in cucina, consapevoli che dovranno riordinare, ma lasciandolo fare per non spegnere l’entusiasmo.

Le aziende che abbracciano questa filosofia sono riconoscibili: prodotti che funzionano perfettamente nelle demo ma collassano misteriosamente in produzione, war room di emergenza settimanali, repository pieni di codice che funziona per ragioni misteriose e smette di funzionare per ragioni ugualmente incomprensibili.

La scatola nera del debugging impossibile

Dare strumenti di generazione automatica a chi non ha competenze tecniche adeguate è come dare una sega elettrica a chi non ha mai fatto falegnameria. Lo strumento può produrre qualcosa di apparentemente funzionante, ma i pericoli nascosti sono enormi.

Si crea un effetto scatola nera: il sistema funziona ma nessuno sa come o perché. Quando si verifica un problema – e nel software i problemi sono certezza, non possibilità – la mancanza di comprensione profonda diventa un ostacolo insormontabile. Debuggare codice che non si comprende è quasi impossibile. Identificare bug latenti, vulnerabilità di sicurezza, problemi di performance richiede una comprensione che va oltre la capacità di generare righe sintatticamente corrette.

Il fatto che il codice compili non significa che sia robusto, efficiente o sicuro. Potrebbero esserci vulnerabilità che emergeranno solo sotto carico specifico, in condizioni particolari, in combinazioni di input non previste. Senza competenza per anticipare questi scenari, si rischia di distribuire in produzione bombe a orologeria digitali.

Il ruolo insostituibile dello sviluppatore

C’è una battuta ricorrente: “Perché l’AI sostituisca gli sviluppatori, serve che i clienti spieghino chiaramente cosa vogliono. Gli sviluppatori sono salvi”. Dietro l’ironia si nasconde una verità profonda sulla natura dello sviluppo software.

Gli sviluppatori non sono traduttori meccanici da linguaggio naturale a codice. Sono interpreti che comprendono non solo cosa il cliente dice di volere, ma cosa effettivamente necessita. La distinzione tra volere e necessitare è fondamentale. I clienti esprimono desideri in termini di soluzioni (“Voglio un pulsante qui”) invece che di problemi (“Devo permettere agli utenti di fare questo”). Un buon sviluppatore va oltre la richiesta superficiale per comprendere l’esigenza sottostante, proponendo spesso soluzioni che il cliente non aveva immaginato.

L’AI opera nel dominio del “come”, non del “perché”. Può generare codice basato su istruzioni precise, ma non può proporre alternative basate sull’esperienza, non può intuire implicazioni nascoste di richieste apparentemente semplici. Gli sviluppatori sono detective dei requisiti, investigano oltre le parole per scoprire le vere necessità del business. Questo richiede competenze tecniche, capacità di comunicazione, empatia, comprensione del dominio.

La gestione della complessità sistemica è un’altra area dove l’intervento umano rimane cruciale. I sistemi moderni sono ecosistemi intricati dove ogni decisione architetturale ha ripercussioni a lungo termine. L’AI può eccellere nella generazione di componenti isolati, ma fatica a comprendere le implicazioni sistemiche delle sue scelte.

Strumento, non sostituto

La vera forza dell’AI emerge quando viene utilizzata da sviluppatori esperti che possono valutare criticamente l’output, comprenderne le implicazioni, modificarlo secondo necessità. In queste mani diventa uno strumento per aumentare produttività, non un sostituto della competenza.

Gli sviluppatori esperti sanno quando fidarsi del codice generato e quando intervenire manualmente. Sanno riconoscere pattern sospetti, identificare vulnerabilità potenziali, valutare trade-off architetturali. Possono usare l’AI per automatizzare task ripetitivi, liberando tempo per aspetti più creativi e strategici.

Il futuro probabilmente vedrà collaborazione sempre più stretta tra sviluppatori e AI, dove quest’ultima agisce come copilota, non pilota automatico. Ma questo richiede comprensione realistica di ciò che l’AI può e non può fare. Le promesse di rivoluzione imminente sono esattamente identiche a quelle del 2001 sui drag-and-drop che avrebbero creato qualsiasi interfaccia. La storia si ripete con nuovi attori.

La documentazione tecnica? Lì l’AI può aiutare davvero, permettendo di produrre pagine e pagine di testo che probabilmente nessuno leggerà mai. Il paradosso della documentazione – più è importante, meno viene letta – rimane invariato. Almeno ora possiamo generare il doppio della documentazione inutile nella metà del tempo. Un progresso indiscutibile.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider