Indice
Introduzione
Negli ultimi mesi nel mondo tech sta accadendo qualcosa di apparentemente positivo, quasi euforico. Scriviamo codice più velocemente che mai. Riduciamo drasticamente i tempi di sviluppo. Superiamo blocchi che prima richiedevano giorni, settimane, a volte mesi. L’intelligenza artificiale promette – e in molti casi mantiene – una produttività senza precedenti.
Eppure, sotto questa superficie brillante, si sta aprendo una frattura più profonda. Una frattura che non riguarda la tecnologia in sé, ma il rapporto che abbiamo con essa. Non stiamo vivendo una crisi di produttività. Stiamo vivendo il suo paradosso.
Il rischio non è che l’AI rallenti lo sviluppo software. Il rischio è che lo renda incomprensibile a chi lo produce.
È da questa tensione che nasce la conversazione con Matteo Baccan, ingegnere del software con oltre trentacinque anni di esperienza, formatore e osservatore privilegiato dell’evoluzione dell’industria IT, oltre che Contributor di Tech 360. Un dialogo che non parla di tool, framework o linguaggi, ma di qualcosa di molto più delicato: la tenuta delle competenze nel tempo.
Velocità contro sedimentazione: cosa perdiamo mentre guadagniamo tempo
Per decenni, lo sviluppo software ha avuto una caratteristica implicita: il tempo di scrittura era anche tempo di apprendimento. Scrivere codice significava abitarlo. Tornarci sopra. Capirlo. Interiorizzarlo.
Oggi questo equilibrio si sta rompendo.
Quando un sistema di AI genera in pochi minuti ciò che prima richiedeva giorni, il tempo di esposizione cognitiva si riduce drasticamente. Il codice funziona, ma non sedimenta. Esiste, ma non viene “fatto proprio” da chi lo ha prodotto.
Questo non è un problema immediato. Il problema emerge quando quel codice va toccato, esteso, mantenuto, difeso nel tempo.
Il punto non è demonizzare l’AI, ma riconoscere una dinamica precisa: accelerando la produzione, accorciamo anche il tempo di comprensione. E senza comprensione profonda, la seniority diventa una maschera.
Il mito del senior nel 2026
Uno dei temi più delicati emersi nella conversazione riguarda proprio il concetto di seniority. Per anni abbiamo associato l’essere senior alla capacità di produrre più codice, più velocemente, con meno errori. Oggi questa metrica non regge più.
Scrivere codice velocemente non è più un segnale di esperienza. In alcuni casi è addirittura un rischio.
L’AI rende possibile a figure junior, o apparentemente tali, di produrre volumi di codice enormi, aggirando la classica “gavetta” che storicamente costruiva competenza profonda. Nasce così una nuova figura ibrida: lo sviluppatore iper-produttivo, ma fragile sul piano della comprensione sistemica.
Matteo Baccan lo dice chiaramente: il vero valore del senior non è più nella scrittura, ma nella capacità di leggere, discriminare, contestualizzare e governare ciò che viene prodotto, anche (e soprattutto) quando è generato da una macchina.
Debug, test e il costo che si sposta in avanti
C’è un’altra illusione diffusa nel dibattito sull’AI: l’idea che stiamo abbattendo i costi dello sviluppo. In realtà, spesso li stiamo solo spostando.
Molti team segnalano un fenomeno ricorrente: il codice generato dall’AI è “quasi corretto”. Funziona in apparenza, ma introduce ambiguità, edge case, debito tecnico difficile da intercettare subito. Il risultato è che il tempo risparmiato in scrittura viene reinvestito – con interessi – in debug, verifica e correzione.
Qui però emerge un punto fondamentale: questo non è un problema nuovo. Anche il codice umano, se non testato, non verificato, non documentato, ha sempre generato debito.
La differenza oggi è la scala. Con l’AI possiamo produrre quantità di codice enormemente superiori. Se i processi di verifica non crescono allo stesso ritmo, la deriva è più rapida, più pericolosa e meno visibile.
AI come outsourcing invisibile del cuore del prodotto
Uno dei passaggi più rilevanti dell’intervista riguarda un concetto spesso sottovalutato: l’AI come nuova forma di outsourcing.
Quando un’azienda affida il cuore del proprio prodotto a sistemi esterni – che siano team delocalizzati o modelli di AI – si espone a un rischio strutturale: perdere il controllo del know-how.
La differenza è che l’AI rende questo outsourcing estremamente facile, immediato, quasi invisibile. Non c’è un contratto, non c’è un fornitore con cui confrontarsi, non c’è una persona da chiamare. C’è solo un output.
Ma governare un prodotto non significa guardare il risultato finale. Significa capire come ci si è arrivati.
Se l’organizzazione non è in grado di leggere, verificare e contestualizzare ciò che l’AI produce, il prodotto resta in piedi solo finché tutto funziona. Al primo problema serio, nessuno sa più dove mettere le mani.
Cultura tech e rischio di desertificazione delle competenze
Qui il discorso si allarga oltre il codice. Tocca la cultura tecnologica delle aziende.
Già prima dell’AI molte organizzazioni faticavano a seguire le best practice: test automatici assenti, analisi statica ignorata, documentazione minima. L’AI non crea questi problemi, ma li amplifica.
Il rischio reale non è l’uso dell’intelligenza artificiale, ma l’abbandono progressivo dell’allenamento cognitivo. Quando smettiamo di fare una cosa, iniziamo a disimpararla. È un processo lento, silenzioso, ma inesorabile.
Se intere generazioni di sviluppatori crescono senza mai dover davvero “entrare” nel codice, la competenza diventa teorica, fragile, non più incarnata. E una cultura tech senza competenza pratica è una cultura di superficie.
Leadership tecnologica: rallentare per non perdere il controllo
In questo scenario, il ruolo del tech leader cambia radicalmente.
Non si tratta di vietare l’AI, né di idolatrarla. Si tratta di governarla. Questo significa introdurre intenzionalmente momenti in cui l’AI viene messa da parte. Spazi di lavoro in cui il team torna a confrontarsi direttamente con il codice, non per nostalgia, ma per allenamento.
Può sembrare inefficiente nel breve periodo. In realtà è un investimento sulla resilienza del sistema.
Un leader tecnologico oggi deve porsi una domanda scomoda: se domani l’AI smettesse di funzionare, sapremmo ancora tenere in piedi il nostro prodotto? Se la risposta è no, allora non stiamo usando l’AI come leva. Le stiamo cedendo il controllo.
Curiosità, non paura: la competenza che non possiamo perdere
Nel finale della conversazione emerge un messaggio chiave: la competenza più importante da preservare non è tecnica, ma cognitiva. La curiosità.
L’AI espone continuamente a soluzioni, approcci e strumenti che non conosciamo. Questo può generare pigrizia o, al contrario, stimolare apprendimento. La differenza la fa l’atteggiamento.
Come ogni grande ondata di automazione, anche questa porta con sé il rischio del “de-skilling”. Un tema affrontato in modo lucido da Nicholas Carr nel libro La gabbia di vetro, citato durante l’episodio. Automatizzare tutto significa spesso rinunciare a capire come funzionano le cose. E nel lungo periodo, questo ha un costo.
Oltre l’hype: usare l’AI senza smettere di pensare
La storia del software è una storia di astrazioni crescenti: dalla riga di comando agli IDE, dai framework al low-code, fino all’AI. Ogni volta qualcuno ha decretato la fine delle competenze. Ogni volta le competenze sono cambiate, non scomparse.
La differenza oggi è la velocità.
Ed è proprio per questo che serve più lucidità, non meno. Più governo, non più delega cieca. L’AI è qui per restare. Ma il valore, ancora una volta, resta umano: nella capacità di comprendere, scegliere e prendersi la responsabilità delle decisioni tecniche.
Perché scrivere codice è sempre stato facile, rispetto a prendere decisioni giuste. E oggi lo è più che mai.
