Ogni pochi mesi esce un titolo che annuncia la fine della programmazione: "l'IA scriverà tutto il codice", "tra due anni non serviranno più sviluppatori". Intanto io l'IA la uso ogni giorno, nei progetti per i clienti e su questo stesso sito, e la mia conclusione è diversa: l'IA è uno strumento di lavoro, non qualcuno che fa il lavoro al posto nostro.
Non è una posizione nuova. Il compilatore ha automatizzato l'assembly, l'IDE ha automatizzato la memoria delle API, Stack Overflow ha automatizzato la ricerca delle soluzioni comuni. Ogni volta il mestiere è cambiato, ma non è sparito: si è spostato più in alto, verso i problemi che quegli strumenti non risolvono.
Cosa fa davvero bene
Usata per i compiti giusti, l'IA fa risparmiare ore. Nel mio lavoro quotidiano la uso soprattutto per:
- Codice ripetitivo: DTO, validazioni, scheletri di componenti e di test.
- Capire codice legacy: "spiegami cosa fa questa funzione da 200 righe" è un ottimo punto di partenza.
- Prime bozze: una query, una regex, uno script di migrazione da rivedere.
- Conversioni: da JSON a interfaccia TypeScript, da CSS a SCSS, da callback a async/await.
- Una prima revisione: errori evidenti, nomi poco chiari, casi limite dimenticati.
Un esempio concreto: generare i DTO con le validazioni per un modulo con quindici campi mi richiedeva una ventina di minuti di lavoro meccanico. Con l'IA bastano due minuti, più cinque per rileggere. È il tipo di guadagno che uno strumento deve dare: meno tempo sul ripetitivo, più tempo sul ragionamento.
Dove si ferma
Il limite non è la qualità del codice, che spesso è buona. Il limite è tutto ciò che sta intorno al codice:
- Il contesto: non sa perché il cliente vuole quella funzione, né quali vincoli non sono scritti da nessuna parte.
- Le decisioni: tra due soluzioni corrette, scegliere quella giusta per quel team e quel budget.
- La verifica: il codice generato sembra sempre giusto, anche quando non lo è.
- La responsabilità: quando qualcosa si rompe in produzione, risponde una persona, non un modello.
Un esempio che mi è capitato davvero. Per mostrare la data di un ordine, l'assistente ha proposto questo:
// Suggested code to show an order date
const date = new Date('2026-10-02');
label.textContent = date.getDate() + '/' + (date.getMonth() + 1);
// Rome: "2/10" — New York: "1/10"Il codice compila, i test locali passano e in Italia funziona. Ma una stringa nel formato AAAA-MM-GG viene interpretata come mezzanotte UTC, quindi per un utente negli Stati Uniti l'ordine risulta del giorno prima. L'IA non ha "sbagliato" nel senso stretto: non sapeva che il sito ha utenti in più fusi orari. Accorgersene è il nostro lavoro.
Una giornata di lavoro reale: chi fa cosa
Se guardo una giornata tipo, la divisione dei compiti è abbastanza chiara:
| Attività | Chi la fa |
|---|---|
| Capire cosa chiede davvero il cliente | Io |
| Scegliere architettura e compromessi | Io, con l'IA come interlocutore |
| Scrivere scheletri di componenti, DTO e test | L'IA, e io rivedo |
| Analizzare un errore strano nei log | Insieme |
| Rilascio in produzione e responsabilità | Io |
"Strumento" non vuol dire "innocuo"
Dire che l'IA è uno strumento non significa che non cambi niente. Cambia molto: chi faceva solo lavoro ripetitivo è più esposto, e i junior rischiano di saltare la fase in cui si imparano le basi, perché il codice funzionante arriva senza fatica.
Allo stesso tempo, alcune competenze valgono più di prima:
- Leggere e valutare codice, non solo scriverlo.
- Conoscere il dominio: fatturazione, sanità, logistica, qualunque sia il settore del cliente.
- Comunicare: tradurre una richiesta vaga in requisiti precisi.
- Verificare: test, monitoraggio, revisione critica.
Come usarla come strumento: cinque regole
- Non accettare codice che non sai spiegare. Se non sai dire perché funziona, non sai nemmeno quando smetterà di funzionare.
- Dai contesto. Versione del framework, convenzioni del progetto, vincoli reali: la qualità della risposta dipende da questo.
- Verifica con i test, soprattutto sui casi limite: valori vuoti,
null, fusi orari, errori di rete. - Non incollare dati sensibili: chiavi, password, dati personali dei clienti.
- Misura il guadagno. Se correggere la risposta costa più che scrivere il codice da zero, scrivilo tu.
In sintesi
Io l'IA la vedo come uno strumento: il più potente che abbiamo avuto da molto tempo, ma pur sempre uno strumento. Automatizza il ripetitivo e accelera le prime bozze; non conosce il contesto, non prende decisioni e non si assume responsabilità. Si dice spesso che l'IA non sostituirà gli sviluppatori, ma che gli sviluppatori che la usano bene sostituiranno quelli che la ignorano: secondo me è vero, a patto di aggiungere che "usarla bene" significa restare quelli che capiscono, scelgono e verificano. Ne parlo anche, dal punto di vista dei colloqui, in questo articolo sulle domande da colloquio nell'era dell'IA.