Come l'AI cambia il modo di pensare dei programmatori
Gli assistenti AI non scrivono solo codice più in fretta: cambiano come ragioniamo, facciamo debug e impariamo. Non tutti gli effetti sono positivi.
Sarah Chen
L'ho notato circa sei mesi dopo aver iniziato a usare Copilot regolarmente. Stavo facendo debug di uno script Python e ho cercato l'assistente AI prima ancora di aver letto il messaggio d'errore. Il traceback era lì — KeyError: 'user_id' — ma il mio primo istinto era diventato 'incollalo in chat' invece di 'leggilo e ragiona'. Quel momento mi ha infastidito più di qualsiasi dibattito sull'AI che sostituisce gli sviluppatori.
Gli strumenti di coding con AI stanno cambiando molto più della nostra produttività. Stanno cambiando le nostre abitudini cognitive: come affrontiamo i problemi, quanto a fondo capiamo il nostro codice e come impariamo. Alcuni di questi cambiamenti sono davvero positivi. Altri preoccupano in modi che non compaiono nelle metriche di produttività.
Il framework di Kahneman applicato al codice
La distinzione di Daniel Kahneman tra Sistema 1 (veloce, automatico, intuitivo) e Sistema 2 (lento, deliberato, analitico) si adatta sorprendentemente bene al modo in cui lavorano gli sviluppatori. Leggere pattern di codice familiari, scrivere boilerplate, orientarsi tra API note: questo è Sistema 1. Fare debug di race condition, progettare sistemi distribuiti, ragionare sulle implicazioni di sicurezza: questo è Sistema 2.
Gli strumenti di coding con AI eccellono nei compiti di Sistema 1. Generano boilerplate istantaneamente, completano pattern familiari e gestiscono le parti meccaniche della programmazione che gli sviluppatori esperti fanno in automatico. È davvero utile: liberare risorse cognitive per i problemi difficili è un saldo positivo.
Il rischio è che questi strumenti rendano anche facilissimo evitare del tutto il Sistema 2. Quando l'AI suggerisce una funzione completa, accettarla richiede meno sforzo cognitivo che capirla. Quando propone una correzione per un bug, la tentazione è applicarla e passare oltre invece di capire perché funziona. Col tempo, questo può atrofizzare le capacità analitiche che distinguono un senior engineer da chi sa solo scrivere codice.
Cosa sta migliorando davvero
Sarebbe disonesto presentarla come una questione solo negativa. Gli strumenti AI hanno migliorato davvero alcuni aspetti dello sviluppo.
Esplorare territori sconosciuti
Quando devo lavorare con un linguaggio o un framework che non uso ogni giorno, gli assistenti AI sono trasformativi. Non perché scrivano codice perfetto — non lo fanno — ma perché mi danno un punto di partenza che di solito va nella direzione giusta. Invece di passare un'ora a leggere la documentazione per capire il pattern base di un connection pool PostgreSQL in Go, ottengo una struttura ragionevole in 30 secondi e dedico quell'ora alle parti che richiedono davvero giudizio.
Questo abbassa la barriera per sperimentare nuovi strumenti. Ho esplorato tecnologie che prima avrei saltato solo perché il costo iniziale sembrava troppo alto. È un beneficio concreto: gli sviluppatori che sanno muoversi con disinvoltura in più parti dello stack sono più efficaci.
Ridurre l'attrito del cambio di contesto
Lo sviluppo moderno comporta un continuo cambio di contesto tra linguaggi, framework e paradigmi. Il test runner di questo progetto è Jest o Vitest? Quest'API restituisce promise o usa callback? Questa codebase usa snake_case o camelCase? Gli strumenti AI assorbono questi dettagli e generano codice coerente con il contesto, riducendo l'attrito di passare da un progetto all'altro.
Code review più veloce
Far riassumere a un'AI un diff grande, segnalare potenziali problemi o spiegare pattern di codice sconosciuti ha reso le code review meno noiose per me. Continuo a leggere il codice io stesso — il riassunto dell'AI è un punto di partenza, non un sostituto — ma mi aiuta a concentrare l'attenzione sulle parti importanti invece di dedicare lo stesso tempo ai cambiamenti di boilerplate e a quelli di logica complessa.
Cosa sta peggiorando
Il divario di comprensione
Ho iniziato a notare un pattern nelle code review: gli sviluppatori che usano molto l'AI producono codice che funziona ma che non sanno spiegare fino in fondo. Chiedi 'perché hai usato una WeakMap qui invece di una Map normale?' e la risposta è 'l'AI me l'ha suggerita' invece di una spiegazione sulle implicazioni della garbage collection. Il codice va bene. La comprensione no.
Questo conta perché la comprensione è ciò che ti permette di fare debug sotto pressione, estendere il codice in direzioni impreviste e prendere decisioni architetturali. Puoi rilasciare codice che non capisci — lo fanno in continuazione — ma non puoi mantenerlo, e non puoi insegnare agli altri ciò che non sai tu.
Il muscolo del debug
Il debug è una delle competenze più importanti per uno sviluppatore, e richiede pratica. Leggere con attenzione i messaggi d'errore, formulare ipotesi, restringere il problema, usare un debugger per verificare le assunzioni: sono comportamenti appresi che si rafforzano con l'uso e si indeboliscono se trascurati.
Quando il tuo primo istinto è incollare un errore in una chat AI e applicare qualunque correzione ti venga proposta, non stai esercitando il debug. Stai esercitando un'altra competenza: valutare se il suggerimento dell'AI sembra plausibile. È utile, ma non è la stessa cosa. Lo sviluppatore che sa fare debug in modo sistematico supererà sempre chi dipende dall'AI quando si imbatte in un problema che l'AI non sa risolvere — e durante gli incidenti in produzione succede più spesso di quanto si pensi.
L'attrattore della mediocrità
Gli strumenti di coding con AI generano codice medio. Per definizione: sono addestrati sulla distribuzione del codice esistente, quindi producono il centro statistico di quella distribuzione. Per i compiti semplici la media va bene. Per i compiti che richiedono una soluzione elegante, un approccio creativo o una comprensione profonda del dominio, la media non basta.
Ho visto sviluppatori accettare soluzioni generate dall'AI che funzionavano tecnicamente ma non coglievano l'intuizione di fondo che avrebbe reso il codice più semplice, veloce o manutenibile. L'AI non suggerisce l'osservazione brillante del tipo 'questo è in realtà un problema di ordinamento topologico'. Genera una soluzione brute-force funzionante che nessuno mette in discussione perché passa i test.
Il problema dell'apprendimento
Per gli sviluppatori junior l'impatto è più acuto. Imparare a programmare significa soprattutto costruire modelli mentali: capire come funzionano le variabili, cosa succede quando chiami una funzione, perché alcune strutture dati sono più veloci di altre. Questo apprendimento avviene attraverso la fatica: scrivere codice sbagliato, ricevere errori, capire perché e sviluppare intuito.
Gli strumenti AI accorciano questa fatica. Un junior che riceve risposte istantanee a ogni errore non sviluppa la stessa intuizione di chi ha passato 30 minuti a leggere lo stack trace e a procedere passo passo nel debugger. L'analogia a cui torno sempre è il navigatore GPS: chi usa sempre il GPS sviluppa un ragionamento spaziale più debole di chi ogni tanto si orienta con le mappe. La destinazione è la stessa, ma il modello mentale è diverso.
Non sto sostenendo che gli sviluppatori junior non debbano usare strumenti AI. Quella battaglia è persa, e gli strumenti aiutano davvero la produttività. Ma c'è un motivo per praticare deliberatamente senza assistenza AI — passare del tempo con i messaggi d'errore grezzi, la documentazione, il debugger — proprio per costruire quella comprensione di base che gli strumenti AI tendono a saltare.
Trovare l'equilibrio
Riflettendo su come sono cambiate le mie abitudini, ho definito alcune linee guida che per me funzionano. Non sono regole universali: sviluppatori diversi troveranno equilibri diversi.
- Leggi l'errore prima di ricorrere all'AI. Dai a te stesso 60 secondi con il messaggio d'errore o il comportamento inatteso. Spesso individuerai subito il problema. Se no, chiedi all'AI — ma chiedile di spiegare l'errore, non solo di correggerlo.
- Capisci prima di accettare. Quando l'AI suggerisce del codice, leggilo come faresti con la PR di un collega. Sai spiegare cosa fa ogni riga? Se no, impara cosa fa oppure non farlo entrare. 'Funziona' non basta per il codice di cui sei responsabile.
- Usa l'AI per le parti noiose, non per quelle difficili. Lasciala generare lo scaffolding dei test, il boilerplate delle API, i file di configurazione e la formattazione della documentazione. Architettura, scelta degli algoritmi e debug falli tu. Le parti difficili sono quelle in cui impari e dove il tuo giudizio aggiunge più valore.
- Lavora ogni tanto senza. Come per ogni dipendenza da uno strumento, è sano lavorare occasionalmente senza assistenza AI. Non perché lo strumento sia cattivo, ma perché devi mantenere le competenze che sostituisce. Io provo a fare una sessione di debug significativa a settimana senza aiuto dell'AI.
- Insegna e spiega. Il miglior test della comprensione è riuscire a spiegare qualcosa a qualcun altro. Se non sai spiegare perché il codice generato dall'AI funziona, non lo capisci abbastanza bene.
Il quadro generale
Siamo nella fase iniziale di un cambiamento profondo nel modo in cui si scrive il software. Gli strumenti AI continueranno a migliorare: più accurati, più consapevoli del contesto, capaci di gestire compiti più grandi e complessi. Gli sviluppatori che prospereranno non saranno quelli che resistono agli strumenti né quelli che delegano tutto. Saranno quelli che usano l'AI come leva mantenendo la comprensione profonda che li rende efficaci quando l'AI non basta.
L'analogia che trovo più utile non è l'automazione che sostituisce i lavoratori, ma gli utensili elettrici che affiancano gli artigiani. Una sega da banco non rende obsoleto il falegname. Rende più veloce la parte meccanica del taglio, così il falegname può dedicare più tempo al progetto, alle giunzioni e alle finiture. Però un falegname che non ha mai imparato a tagliare dritto senza la sega da banco è limitato in modi che contano quando il lavoro richiede attrezzi manuali.
La domanda non è se usare gli strumenti di coding con AI. È se li usi come utensili elettrici che amplificano le tue competenze, o come stampelle che impediscono a quelle competenze di svilupparsi. La risposta cambia a seconda del compito, del contesto e della fase della tua carriera. Ma è una domanda da porsi regolarmente, perché i default tendono a scivolare verso la dipendenza, e l'unico antidoto è l'intenzionalità.
