I titoli continuano a dirci che l'IA renderà obsoleti gli sviluppatori di software. Non ci credo. Il vero rischio non è che le mac...

I titoli continuano a dirci che l'IA renderà obsoleti gli sviluppatori software. Io non ci credo. Il vero rischio non è che le macchine prendano il sopravvento sull'ingegneria. Il rischio è che gli ingegneri smettano di compiere il faticoso lavoro di pensare.

Il software non è mai stato una questione di digitazione di sintassi. Si è sempre trattato di mantenere la complessità nella propria testa, comprendere le modalità di guasto e compiere compromessi quando nessuna opzione è perfetta. L'IA ha cambiato la velocità con cui produciamo codice, ma non ha cambiato il motivo per cui abbiamo bisogno dell'intervento umano. Se non altro, ha reso il pensiero chiaro più prezioso e più scarso.

La prima bozza non è ingegneria

Vedo un numero crescente di sviluppatori junior trattare ChatGPT o Claude come l'ingegnere senior seduto sulla sedia accanto. Incollano la descrizione di un ticket, copiano la risposta, eseguono i test e fanno il commit. Se compila, il task è chiuso. Il ciclo è veloce, privo di attriti e pericoloso.

Usare l'IA non è il problema. Io la uso. La maggior parte degli ingegneri più produttivi che conosco la usa. Il problema inizia quando l'IA diventa l'unico ingegnere nella stanza. Accettare la prima soluzione solo perché funziona non è ingegneria. È l'esternalizzazione del giudizio a un modello che non comprende i tuoi utenti, i tuoi vincoli aziendali o l'ultima volta che il tuo stack è andato in crash alle 2 del mattino.

I grandi modelli linguistici forniscono risposte con un'inquietante sicurezza, anche quando sono completamente errate. Un ingegnere ha chiesto a un'IA di progettare un'architettura scalabile. Il modello ha restituito una proposta dettagliata e autorevole, costruita interamente attorno a una funzionalità che non esisteva nel prodotto reale. Sembrava corretta. Era internamente coerente. Era anche inutile. Il pericolo non è solo che l'IA allucini. Il pericolo è che troppe persone ora si fidino di quelle allucinazioni perché non hanno più il contesto per individuare la menzogna.

Si impara dall'attrito

Quando penso a ciò che mi ha trasformato da sviluppatore junior a qualcuno in grado di gestire un sistema, non ricordo la sintassi che ho memorizzato. Ricordo i blackout. Ricordo le query lente che ho dovuto tracciare a mano, le race condition che apparivano solo sotto carico di produzione e i deployment che fallivano perché il mio ambiente locale non somigliava affatto al mondo reale.

Il debugging è il luogo in cui avviene l'apprendimento. Quando esegui il codice passo dopo passo manualmente, vedi perché i sistemi falliscono realmente. Scopri dove appaiono i colli di bottiglia. Impari come si comporta un'architettura quando passi da una demo con dieci utenti a un sistema di produzione che gestisce diecimila richieste concorrenti. Assorbi, fin nelle ossa, come la produzione differisca da una demo ben sceneggiata.

Nessuna di quelle conoscenze deriva dall'accettare una risposta generata. Deriva dal lottare con il problema. Se l'IA elimina ogni difficoltà, se scrive il codice, corregge i bug e giustifica i fallimenti, come farà esattamente la prossima generazione di sviluppatori a guadagnarsi la propria seniority? L'esperienza non è un certificato che si scarica. È il tessuto cicatriziale che si costruisce attraverso gli incidenti in produzione e i deployment falliti. Elimina l'attrito e eliminerai la crescita.

Il giudizio batte la generazione

Per un po', l'industria ha trattato il prompt engineering come la nuova competenza di tendenza da inserire nel curriculum. Questo ha mancato completamente il punto. La capacità più preziosa in un ambiente saturo di IA non è generare opzioni. È sapere quali suggerimenti rifiutare.

I migliori ingegneri con cui lavoro non scrivono il maggior numero di prompt. Pongono le domande più difficili. Sanno quando un refactoring introduce una dipendenza nascosta. Riconoscono quando un test generato copre il happy path ma ignora l'edge case che corromperà i dati dei clienti. Possono guardare del codice perfettamente valido e dire: "Questo codice è corretto, ma l'architettura è sbagliata".

Quest'ultima frase è la linea di demarcazione tra due culture molto diverse. L'ingegneria assistita dall'IA significa che usi la macchina per bozzare lo scaffolding, esplorare pattern o automatizzare il boilerplate, mentre il tuo cervello si occupa delle decisioni. L'ingegneria dipendente dall'IA significa che ti affidi alla macchina per guidare. Molte organizzazioni stanno scivolando silenziosamente verso la dipendenza perché sembra più veloce nel breve termine. Veloce non significa giusto.

Il lavoro che appartiene ancora agli esseri umani

L'IA può accelerare quasi ogni fase del ciclo di vita dello sviluppo, eppure esistono pratiche fondamentali che dovrebbero rimanere saldamente umane. La progettazione dei sistemi richiede di bilanciare vincoli contrastanti: costi, latenza, affidabilità e manutenibilità futura. Le revisioni dell'architettura dipendono dalla memoria istituzionale e dalla capacità di prevedere gli effetti di secondo ordine. Il mentoring richiede qualcuno che abbia effettivamente affrontato le modalità di guasto di cui ti sta avvertendo. Una profonda comprensione del prodotto deriva dal parlare con gli utenti e dall'osservare il loro comportamento nel mondo reale, non dal leggere dati di addestramento.

Il giudizio ingegneristico è la somma di quelle esperienze. È quella voce sottile che ti dice che una migrazione è troppo rischiosa per essere rilasciata un venerdì pomeriggio, anche se la code review è passata. È l'intuizione che un'ottimizzazione delle prestazioni fatta ora potrebbe creare una falla di sicurezza in seguito. Un LLM non ha intuizione. Ha dei pattern. I pattern sono utili, ma non sono giudizio.

Le aziende che assumono in questo momento devono smettere di cercare persone che siano semplicemente brave a usare strumenti di IA. Assumete persone che sappiano mettere in discussione l'IA. Cercate candidati che si fermino, leggano attentamente l'output generato e spieghino perché non sono d'accordo. Sono questi gli ingegneri che manterranno i vostri sistemi in salute quando il codice generato si scontrerà con la disordinata realtà della produzione.

Accelerazione senza bussola

Pensate all'IA come a un pedale dell'acceleratore. In un'auto con un