All’inizio del 2026, alcuni ricercatori che cercavano di misurare l’effetto dell’IA sulla produttività degli sviluppatori si sono imbattuti in un problema profondamente umano: c’erano sviluppatori che non volevano più accettare attività per le quali avrebbero potuto dover lavorare senza IA.
I ricercatori lo hanno chiamato effetto di selezione. Io continuo a pensarlo come una piccola confessione.
Non molto tempo fa, l’IA era un esperimento confinato in un pannello laterale. La aprivamo quando l’autocompletamento falliva o quando un’espressione regolare iniziava a metterci in imbarazzo. Oggi, per molti sviluppatori, è semplicemente parte della stanza. È lì quando apriamo l’editor al mattino, quando ereditiamo un repository che nessuno tocca da anni e quando un test diventa rosso a tarda notte.
Possiamo chiudere il pannello. Possiamo spegnere l’agente. Sappiamo ancora programmare.
Allora perché lavorare senza IA sembra già come lavorare con una mano in meno?
L’IA si è presa le pause
L’IA non è entrata nello sviluppo software annunciando che ci avrebbe sostituiti. È arrivata portando un piccolo sollievo alla volta.
Prima ha completato la riga che stavamo per scrivere. Poi ha preparato il test che continuavamo a rimandare. Ha spiegato una funzione sconosciuta, trasformato uno stack trace in parole comprensibili e trovato un’impostazione sepolta in una documentazione che non volevamo leggere di nuovo.
Niente di tutto questo sembrava dipendenza. Sembrava slancio.
Ripensa all’ultima volta in cui il tuo assistente non era disponibile. Probabilmente non ti ha turbato l’idea di aver dimenticato il linguaggio. È stato il silenzio prima della prima mossa. Dovevi decidere da solo dove cercare. Dovevi reggere l’incertezza senza aiuto. Dovevi fissare l’errore abbastanza a lungo perché prendesse forma un’ipotesi.
Quelle pause un tempo erano normali. Ora sembrano attrito.
Forse è questo il cambiamento più profondo portato dall’IA. Non ha trasformato soltanto il modo in cui produciamo risposte. Ha cambiato il tempo che siamo disposti a trascorrere da soli con una domanda.
Il sollievo è reale
È facile parlare di dipendenza dall’IA come se gli sviluppatori stessero scambiando la disciplina con la pigrizia. Ma così si perde ciò che lo strumento rappresenta quando lo si vive dall’interno del lavoro.
Lo sviluppo software contiene una quantità sorprendente di vergogna privata. C’è il senior engineer che ha dimenticato la sintassi di un comando elementare. La nuova collega che teme che un’altra domanda confermi i dubbi di tutti. Lo sviluppatore che lavora in una seconda lingua, sa esattamente cosa non va ma non riesce a spiegarlo abbastanza in fretta. La persona che entra in una codebase vecchia di dieci anni, dove ogni decisione importante vive soltanto nella memoria di qualcun altro.
L’IA è paziente con tutti loro.
Non sospira quando ripetiamo una domanda. Non dice: «Questo dovresti già saperlo». È disponibile alle due di notte e può trasformare uno schermo vuoto in qualcosa con cui discutere. Anche una risposta imperfetta cambia il peso emotivo dell’inizio.
Questo conta. A volte ciò che sembra produttività è soprattutto sollievo: meno paura di rimanere bloccati, meno imbarazzo, meno solitudine davanti a una macchina che si rifiuta di spiegarsi.
Per molti sviluppatori, l’IA ha anche restituito energia alle parti del lavoro che amano. Può occuparsi del codice ripetitivo, dei test di routine, dell’impalcatura di una migrazione e dell’ennesima variante di un client API. La mente arriva meno stanca al problema interessante.
Non dovremmo liquidarlo come una semplice scorciatoia. Uno strumento che dà alle persone più coraggio per esplorare sta creando qualcosa di realmente prezioso.
Il problema è che conforto e dipendenza crescono dalla stessa radice.
Usiamo ciò di cui non ci fidiamo fino in fondo
Le indagini tra gli sviluppatori continuano a mostrare la stessa strana relazione: usiamo continuamente l’IA, ma restiamo sospettosi di ciò che ci consegna.
Chiunque abbia visto una risposta sicura crollare davanti a un solo caso limite conosce questa tensione. Il codice sembra corretto. I nomi sono puliti. La spiegazione è tranquilla. Solo dopo il terzo test fallito scopriamo che il modello ha inventato un metodo, frainteso una regola di business o risolto un problema più semplice del nostro.
Eppure, la volta successiva in cui ci blocchiamo, chiediamo ancora.
Non è ipocrisia. La fiducia non è una cosa sola.
Forse non affidiamo all’IA la decisione finale, ma le chiediamo una prima direzione. Non ci fidiamo della patch, ma della conversazione capace di sciogliere un nodo nel pensiero. Dubitiamo della risposta, ma sappiamo che sullo schermo apparirà qualcosa invece del nulla.
L’IA è diventata il collega a cui non permetteremmo mai di fare merge direttamente su main, e che tuttavia ci manca appena lascia la stanza.
Avanziamo più velocemente perché il prossimo passo appare subito. Verificare che regga il nostro peso resta una nostra responsabilità.
Ciò che scompare quando scompare la fatica
Esiste una conoscenza che nasce soltanto quando rimaniamo bloccati.
Prima dell’IA, un errore sconosciuto poteva portarci dallo stack trace al chiamante, poi alla documentazione e infine a un’ipotesi che non sapevamo nemmeno di aver fatto. Il percorso era inefficiente. Era anche il modo in cui una codebase diventava un luogo, non soltanto una raccolta di file.
Ricordiamo i sistemi che una volta ci hanno opposto resistenza.
Il bug che ci ha preso un pomeriggio insegna dove vive davvero lo stato. L’incidente in produzione spiega perché esiste una protezione apparentemente noiosa. La libreria che abbiamo frainteso tre volte diventa quella che un giorno sapremo spiegare a qualcun altro.
Quando l’IA rimuove la resistenza, può rimuovere anche la storia che permette alla lezione di rimanere.
Un primo studio su sviluppatori alle prese con una libreria sconosciuta ha mostrato qualcosa di intuitivo: chi delegava l’intero compito imparava meno di chi usava l’IA per porre domande concettuali e verificare la propria comprensione. La distinzione importante non era «IA o niente IA», ma se lo strumento sostituiva il pensiero o vi partecipava.
La questione è particolarmente delicata per chi è all’inizio. Gli ingegneri esperti riconoscono un’astrazione sospetta perché in passato hanno costruito quella sbagliata. Sentono che una patch ordinata non appartiene al sistema perché ne conoscono le cicatrici. Ma dove svilupperà questo istinto la prossima generazione, se ogni asperità viene smussata prima che possa toccarla?
Il mentoring non è mai stato soltanto trasferire risposte. Era un lento passaggio di giudizio: di cosa preoccuparsi, quando fermarsi, quale compromesso diventerà costoso e perché una soluzione funzionante non è ancora pronta.
L’IA può spiegare tutte queste idee. Non può ancora riprodurre la sensazione di un’altra persona che sceglie di restare al tuo fianco mentre le impari.
La scorciatoia può essere reale. La comprensione deve comunque attraversare la distanza.
Il codice portava delle impronte
C’è un altro cambiamento ancora più difficile da misurare, perché avviene tra le persone.
Il codice scritto da un essere umano conserva spesso tracce del suo autore. Una funzione di supporto insolita può portare il ricordo dell’incidente che l’ha resa necessaria. Un commento goffo può mostrare il punto in cui qualcuno era incerto. Durante una review non ispezioniamo soltanto la modifica: ricostruiamo il pensiero che l’ha prodotta. Facciamo domande e un’altra persona risponde dal percorso che ha seguito.
Il codice generato dall’IA può arrivare senza quel percorso.
Può essere elegante e tecnicamente plausibile, ma sembrare stranamente senza proprietario. L’autore sa descrivere ciò che ha chiesto, ma non sempre perché il risultato abbia preso proprio quella forma. Chi fa la review si ritrova allora a svolgere parte del lavoro che un tempo apparteneva a chi scriveva: ricostruire l’intento, verificare le ipotesi e scoprire i margini nascosti di una decisione che nessuno ricorda di aver preso.
È questa l’inquietudine che attraversa molte discussioni della community sulle pull request generate dall’IA. Il problema non è soltanto che il codice possa essere cattivo. Il cattivo codice ci è familiare. Il disagio più profondo nasce dal fatto che è cambiato il contratto sociale.
Una persona può produrre una modifica enorme in pochi minuti. Un’altra deve ancora spendere attenzione umana per capirla. Il tempo risparmiato alla tastiera ricompare silenziosamente nella review, nella manutenzione, nella sicurezza o nella notte in cui il sistema si rompe e qualcuno deve spiegare cosa cercava di fare quella patch generata.
Il codice è sempre stato comunicazione. Quando generarlo diventa quasi gratuito, l’attenzione diventa la risorsa scarsa. E l’attenzione appartiene alle persone.
Forse il mestiere si sta spostando
Per alcuni sviluppatori, niente di tutto questo assomiglia a una perdita. Sembra finalmente la possibilità di lavorare al livello che hanno sempre desiderato.
Scrivono meno righe e dedicano più tempo a dare forma al problema. Confrontano più progetti prima di sceglierne uno. Pensano all’utente, all’architettura, ai modi in cui il sistema può fallire e ai confini che un agente non deve superare. Il mestiere si sposta dalla costruzione di ogni singolo pezzo alla direzione dell’insieme.
Può essere una vera evoluzione. Non abbiamo smesso di essere sviluppatori quando l’assembly ha sostituito il codice macchina o quando i framework hanno sostituito le infrastrutture costruite a mano. Il software si è sempre mosso verso l’alto grazie all’astrazione.
Ma ogni astrazione dipende da qualcuno che capisce ciò che c’è sotto.
Uno sviluppatore che dirige l’IA ha ancora bisogno di gusto. Chi fa review ha ancora bisogno di un modello mentale. Un architetto deve ancora sapere cosa succede quando il diagramma pulito incontra una rete lenta, un messaggio corrotto, un team esausto o un utente spaventato.
Se l’IA scrive una parte maggiore dell’implementazione, il giudizio umano non diventa meno importante. Diventa più facile da ignorare e più difficile da coltivare.
La versione fiduciosa di questo futuro non è quella in cui gli sviluppatori contano meno. È quella in cui diventiamo più consapevoli di ciò che soltanto le persone possono portare: contesto, cura, dubbio, responsabilità e la capacità di riconoscere quando una risposta tecnicamente corretta è sbagliata per questo sistema e per queste persone.
Restare, senza scomparire
Possiamo ancora fare a meno dell’IA?
Come individui, sì. Domani possiamo chiudere il pannello. Come professione, la risposta è già più complessa. Le aspettative stanno cambiando. Le codebase si riempiono di lavoro generato. I nuovi sviluppatori incontrano l’IA all’inizio della carriera, non a metà. Anche chi non usa mai un assistente dovrà sempre più spesso rivedere e mantenere codice prodotto da uno.
Non esiste un percorso privato per tornare a un’industria del software precedente all’IA.
Forse, però, andarsene è la misura sbagliata della libertà. La domanda più importante è se riusciamo a rimanere presenti mentre lo strumento resta.
Rimanere presenti significa leggere la patch anche quando tutti i test sono verdi. Chiedere perché dopo che la risposta ha funzionato. Rifiutarsi di fare merge di ciò che non sappiamo spiegare. Dare ai junior il tempo di faticare senza chiamarlo spreco e riconoscere a chi fa review il lavoro invisibile di proteggere un sistema da errori plausibili.
Significa anche conservare momenti in cui nessun assistente risponde subito. Non come rituale di purezza, ma per tornare ad ascoltare il nostro pensiero.
La maggior parte di noi continuerà a usare l’IA. Il sollievo è reale. Le possibilità sono reali. Lo sono anche l’inquietudine, la dipendenza e la paura silenziosa che qualcosa che amavamo di questo lavoro ci stia sfuggendo.
Non dobbiamo scegliere tra negazione e resa.
Il futuro del software non sarà deciso dalla percentuale di codice scritto dall’IA. Sarà deciso in momenti più piccoli: se comprendiamo prima di accettare, se insegniamo invece di inoltrare una risposta, se proteggiamo l’attenzione di un’altra persona e se continuiamo ad assumerci la responsabilità quando il codice generato raggiunge il mondo reale.
L’IA può restare.
Dobbiamo assicurarci di restare anche noi.
