C’è una parola nuova per una vecchia paura nascosta nei corridoi dei reparti IT: never-skilling. Non è il semplice decadimento dell’esperto che smette di esercitarsi (quello si chiama deskilling), ma qualcosa di più insidioso: il principiante che non diventa mai competente. La ricerca pubblicata quest’anno mette un punto fermo su un sospetto che i datori di lavoro coltivano da tempo. Quando un junior utilizza un assistente di codice basato su LLM per generare funzioni o correggere errori, non sta imparando a ragionare sui bug. Sta solo applicando un cerotto sintetico.

Il problema non è la produttività immediata — quella sale, e pure in fretta. Il cortocircuito arriva dopo. I sistemi software vivono di manutenzione, refactoring e incidenti imprevedibili. Il debugging non è un’attività accessoria: è il nucleo del pensiero ingegneristico. Se una generazione di sviluppatori non costruisce quella base, l’intero ecosistema si indebolisce. E il colpo più duro lo incassano proprio le organizzazioni che hanno scelto la via del deployment on-premise.

Perché un’azienda dovrebbe portare gli LLM dentro i propri server? Per controllo, sovranità dei dati, prevedibilità del TCO. Ma un modello eseguito in locale, magari quantizzato per contenere la VRAM necessaria o sottoposto a fine-tuning su dati proprietari, non è un elettrodomestico. Ha bisogno di pipeline di inference curate, di diagnosi quando i token generati iniziano a deragliare, di messa a punto quando il contesto normativo cambia. Servono persone che sappiano aprire il cofano, non solo premere il tasto “completa”.

Se i junior non sviluppano mai l’istinto per il debugging — perché l’assistente AI glielo nasconde — chi erediterà quelle competenze? L’azienda si ritrova con uno stack locale gestito da una manciata di veterani, mentre i nuovi assunti sono abilissimi a scrivere prompt ma incapaci di inseguire un segmentation fault in un container. Il paradosso è tagliente: l’adozione massiccia di strumenti che promettono autonomia può invece creare una dipendenza strutturale, sia dai vendor di modelli sia da quei pochi ingegneri che sanno ancora mettere le mani nei log.

C’è poi un effetto di secondo ordine sugli incentivi. Chi sviluppa piattaforme di AI-assisted coding ha tutto l’interesse a rendere l’esperienza sempre più fluida, riducendo l’attrito. L’attrito, però, è anche la frizione cognitiva che fa crescere un professionista. Rimuovendolo del tutto, il mercato rischia di produrre una forza lavoro ad alta produttività apparente ma a bassa resilienza reale — una specie di debito tecnico vivente che matura con gli anni.

Per chi valuta deployment on-premise, la domanda non è “usiamo o no l’IA?”. È “come garantiamo che i nostri team continuino a saper lavorare senza rete?”. La risposta non sta nel rifiutare gli LLM, ma nel progettare percorsi di affiancamento dove il debugging rimanga una pratica deliberata, non un’opzione nascosta. Altrimenti, tra cinque anni, lo stack self-hosted sarà perfettamente configurato e affidato a mani che non sanno ripararlo.