L’Illusione della velocità nell’Era AI

In un mondo che cambia, dove arrivano ogni giorno nuovi strumenti di intelligenza artificiale, la promessa di velocità e produttività sembra essere la nuova frontiera per CTO e reparti IT.

Il mantra che risuona nella testa dei manager in questo periodo è:

dobbiamo essere più veloci

Il VibeCoding, la promessa che ognuno possa essere in grado di realizzare software senza saper programmare, è lo strumento principe di questa velocità e i vassalli di questo strumento sono gli agenti di decodifica: un plotone di professionisti virtuali che possono arrivare a ondate sui nostri progetti, generando codice e debiti tecnici a velocità impressionanti.

Questa accelerazione potrebbe però nascondere un pericolo insidioso: la creazione di una generazione di senior virtuali, professionisti che, pur essendo in grado di realizzare prodotti rapidamente grazie all’AI, mancano delle competenze profonde necessarie per affrontare le sfide tecniche più complesse.

Un danno o una beffa?

Se fino ad oggi la crescita professionale, da junior a senior, era un percorso lungo e tortuoso, fatto di errori, correzioni e apprendimento manuale, l’AI rischia di saltare questa fase cruciale, dando a tutti strumenti che permettono di bypassare la “gavetta” e diventare da subito iper-produttivi.

Ho già parlato in passato di quanto sia importante la gavetta per la crescita professionale, ma ora questa fase rischia di essere completamente bypassata, e non da un corso, ma da un suggeritore che ci imbocca in ogni nostro passo.

Un meccanismo perverso camuffato da produttività, che potrebbe trasformarsi in un’arma puntata contro la stessa azienda che richiede velocità, creando professionalità apparenti: persone in grado di raggiungere subito ottimi risultati, ma poi incapaci di adeguare quanto richiesto alle esigenze di business più o meno complesse che arrivano dal management.

La domanda che ci dovremmo fare è: come i CTO possono evitare questa deriva? Come possiamo contrastare il processo di de-competenza in atto in questo momento storico? Quali sono gli strumenti che ci possono permettere di evitare di riempire le aziende di scatole vuote?

Riprogettare la mentorship tecnica per evitare il collasso delle competenze

C’è un grande entusiasmo per come l’AI acceleri tutto: dalla scrittura del codice, alla creazione di documenti, di piani di lavoro e via dicendo, ma questa accelerazione non permette una cosa molto importante: l’errore.

È inutile negare che un errore insegna più di mille righe generate dall’AI. Quando deleghiamo tutto a un agente, per troppo tempo, rischiamo solo di perdere la capacità di apprendere, perché non c’è il tempo materiale per assimilare, studiare, sbagliare e imparare.

Questo crea un collasso di competenze che rischia di essere sistemico per le aziende tech. I dati parlano chiaro: secondo lo Stack Overflow Developer Survey 2025, l’84% degli sviluppatori sta usando o pianifica di usare strumenti AI (in crescita dal 76% del 2024), con il 51% dei professionisti che li usa quotidianamente. Tuttavia, la fiducia è crollata: solo il 33% si fida dell’accuratezza dell’output AI, mentre il 46% attivamente non si fida (in aumento dal 31% del 2024). Solo il 3% riporta “alta fiducia” nei risultati. La frustrazione principale? Il 66% degli sviluppatori lamenta che “le soluzioni AI sono quasi corrette, ma non del tutto”, e il 45% trova che debuggare codice generato dall’AI richieda più tempo di quanto ne servirebbe per scriverlo da zero.

Arriviamo da anni dove occorreva rimboccarsi le maniche e imparare, verificare gli errori, studiare nuovamente, e migliorare. Se pensiamo ai prossimi 5 anni, il rischio è che le competenze non si formino più perché l’AI farà il lavoro per noi: in caso di errore si continuerà a reiterare fino a un presunto risultato accettabile (o almeno fino a quando un’AI ci dirà che il risultato è accettabile, o fino a quando il budget ce lo permetterà).

Ma a quel punto: chi valuterà la bontà del risultato? Far valutare un risultato a chi il risultato lo ha raggiunto è un controsenso. Chi capirà se quel prodotto è adatto al contesto aziendale?

Fino a quando avremo persone cresciute con la vecchia impostazione di apprendimento, forse andrà bene e riusciremo a fare una corretta analisi, ma tra 5 anni? E fra 10? E no, la risposta non è far valutare il prodotto di un’AI da un’altra AI, perché questo non risolve il problema della competenza umana.

Dovendo essere lungimiranti, dobbiamo pensare a come evitare che le aziende tech si ritrovino con una generazione di senior vuoti, incapaci di gestire sistemi complessi.

Non dovremo quindi concentrare le nostre competenze sul creare prodotti, ma sul calmierare il rischio che le AI assorbano tutte le competenze aziendali svuotando, di fatto, la competenza delle persone ed essendo così inserite all’interno dei processi aziendali da non riuscire più a essere supervisionate o bypassate.

Outsourcing digitale

La direzione nella quale stiamo andando è un outsourcing digitale, dove stiamo dando i nostri asset aziendali in larga parte a terzi: stiamo svendendo cultura in cambio di un’apparenza di velocità.

Siamo pronti a fare questo passo? Siamo pronti a delegare il nostro know-how a un software che non sappiamo come funziona? Ma soprattutto, nel momento in cui quel software sbaglia, come facciamo a capire dove ha sbagliato se non abbiamo le competenze per farlo? Come facciamo a correggere gli errori che ha commesso se non siamo più padroni della tecnologia?

Riflettiamo su questa frase:

Le startup possono lanciare con codice generato da AI, ma non possono scalare senza sviluppatori esperti

Se dobbiamo realizzare un POC: l’AI va benissimo, se dobbiamo creare un MVP forse iniziamo ad avere un problem, ma se dobbiamo costruire un’azienda solida, con basi robuste, non possiamo affidarci a chi non ha le competenze per capire cosa sta facendo.

Strategie proattive per CTO: creiamo degli anticorpi

La soluzione non è vietare l’uso dell’AI, ma ripensare il percorso di crescita dei nostri sviluppatori con un’ingegneria inversa delle competenze. Dobbiamo progettare frizioni positive nel flusso di lavoro che costringano il cervello a non spegnersi.

Proviamo a fare un esercizio di stile e a dare degli spunti a un CTO che vuole evitare la desertificazione delle competenze:

1. Zone prive di AI

Una volta l’uomo doveva correre dietro agli animali per cacciare, ora per mantenersi in forma passa ore su un tapis roulant. Può sembrare un parallelo tirato per i capelli, ma occorre definire dei contorni dove l’uso delle AI venga deliberatamente vietato. I CTO dovrebbero designare specifiche aree di lavoro, magari in contesti critici come i sistemi legacy, come palestre cognitive. In queste zone, per chi deve formarsi, l’uso dell’AI è vietato o limitato alla sola consultazione della documentazione. Questo non rallenta nessun progetto, lo assicura. Obbliga a leggere, comprendere e descrivere la logica, creando quella memoria muscolare che altrimenti andrebbe persa.

2. Ripensiamo le code review: chiediamoci “Perché?”

Ogni modifica software non dovrà essere valutata solo sul fatto che funzioni, che sia pulita, che risponda ai requisiti: è facile creare dei test che rispettino quando viene fatto dal codice che devono validare, ma la nuova domanda deve essere: “Perché?”.
Perché hai scelto questo pattern specifico invece di un altro? Quando la risposta sarà “L’ha suggerito l’AI”, la modifica verrà respinta. Dobbiamo valutare la capacità di difendere le scelte architetturali, non solo la capacità di produrre output.

Ricordo un corso universitario nel quale ho insegnato in passato: dopo aver valutato la qualità degli elaborati chiedevo sempre il motivo delle scelte fatte. A volte gli studenti rispondevano “Perché me lo ha suggerito ChatGPT”. In quel momento sapevo che il frutto del lavoro era prodotto da una macchina e non da loro, e pretendevo che andasse riscritto, analizzato e compreso.

La capacità di argomentare le proprie scelte è fondamentale per crescere e sarà ancora più importante in un mondo dove l’AI può suggerire mille alternative diverse in pochi secondi, ma non tutte saranno utili al contesto.

3. Giochiamo a wargames

L’AI è bravissima a diagnosticare errori comuni, ma cosa succede quando il sistema crolla in un modo che il modello non ha mai visto? Un limite delle attuali soluzioni è la visione olistica, il riuscire a integrare nel modo corretto vari aspetti dei progetti: non solo il piccolo contesto datogli in pasto da un prompt più o meno lungo.

Organizzate sessioni di gioco dove si rompono intenzionalmente delle parti nell’ambiente di staging in modi subdoli (problemi di rete, race condition, memory leak) e si chiede al team di risolvere il problema senza strumenti AI. La capacità di tracciare un errore attraverso lo stack mentale è l’abilità che distingue un professionista da un semplice prompt engineer.

4. Archeologia digitale

Assegnate dei compiti, lasciando la possibilità di utilizzare un’AI, ma in contesti dove le AI non esistono informazioni, in modo che le risposte siano largamente errate e le persone siano obbligate a studiare meglio quanto richiesto.

Un esempio è la gestione di codice legacy, su piattaforme proprietarie, mal documentate, o con parte di documentazione assente. Questo obbliga le persone a studiare meglio come il vecchio programmatore pensava ed è un esercizio di empatia tecnica fondamentale per la progettazione di sistemi robusti.

5. Parliamo prima di design e poi di prompt

È inutile e controproducente buttarsi sulla tastiera a scrivere prompt se non abbiamo bene in mente il progetto sul quale vogliamo mettere le mani. Costringiamo le persone a scrivere prima un documento di design, un’architettura di massima, un documento che descriva la visione complessiva.

Il pensiero deve precedere la generazione del risultato, che ne è solo una conseguenza. Se l’AI scrive il codice, l’umano deve scrivere l’architettura. Se l’umano abdica anche a questo, diventa un passacarte inutile e probabilmente dannoso.

Recruiting 2.0: assumiamo la capacità cognitiva

Se il modo di lavorare cambia, deve cambiare anche il modo in cui assumiamo. I vecchi test algoritmici sono ormai inutili: qualsiasi modello AI li risolve in una manciata di secondi.

Cosa dobbiamo cercare allora?

La capacità di porre le domande: mio figlio di 7 anni mi tempesta di domande, ma da come me le pone capisco cosa sta imparando, cosa ha capito e in che direzione sta andando. Fate la stessa cosa con i candidati: descrivete un problema vago e mal definito. Non valutate la soluzione, ma il percorso e le domande che fa per chiarire i requisiti. L’AI è pessima nel gestire l’ambiguità umana: non chiarisce, segue una strada come la più logica o probabile, e inizia il lavoro. Per chi ha un po’ di cultura fantascientifica: è come parlare con un vulcaniano.

Fate fare debug su codice rotto: la capacità che serve è quella di capire gli errori. Date ai candidati un sistema complesso che fallisce in modo intermittente. Osservate il processo mentale di indagine.

Architetture offline: date in mano al candidato un gessetto e una lavagna, lo so: fa tanto boomer, ma è una tecnica che ancora funziona. Fategli disegnare una possibile architettura per un progetto di qualsiasi natura, poi aumentate i requisiti e seguite i ragionamenti che usa per adeguare l’architettura.

Distinguere cosa è prodotto da una macchina e cosa è prodotto da un umano

È importante capire la fonte di un dato, distinguendo cosa è prodotto da una macchina e cosa è prodotto da un umano. La ragione è semplice: gli intenti sono diversi. Una persona ha un obiettivo specifico mentre una macchina si basa su probabilità e iterazione.

Se non imponiamo delle regole per capire da quale fonte arriva il dato che stiamo trattando, rischiamo di approcciare in modo sbagliato dati che, per loro natura, nascono in modo diverso. Un CTO deve avere ben presente questo aspetto, circoscrivere l’area d’azione di macchine e persone e introdurre un codice di condotta.

Quando si parla di sviluppo software, questo si traduce in alcune regole pratiche, che per traslazione possono essere applicate in altri ambiti aziendali. Le principali sono: etichettatura e quarantena.

L’etichettatura serve a comprendere in modo immediato la fonte di qualcosa: se il vostro codice, i vostri documenti, le vostre procedure, sono generati per oltre il 50% da una macchina, introducete delle annotazioni specifiche “AI GENERATED” e magari indicate il modello che è stato coinvolto nella realizzazione. Se in futuro ci sarà un problema, dovremo andare a fare dei controlli, e questo tipo di etichettatura ci aiuterà a risalire alla fonte del problema. Come tutti i software, anche le AI non sono perfette, commettono errori e allucinazioni e, in base al contesto e alla versione, hanno dei comportamenti diversi. Etichettare quanto producono ci aiuta a tracciare la fonte di un problema.

La quarantena ci permette di non prendere subito per buono quanto ci viene proposto. Se si tratta di codice, evitate che le AI si occupino direttamente del CORE di prodotto. Utilizzatele per scrivere test, utility, per criticare il codice realizzato, per fare analisi, per darvi idee, ma non per occuparsi pesantemente di quanto dovete scrivere: in questo momento storico le AI usate come aiuto sono un bene, utilizzate per gestire il core business rischiano di trasformarlo in una massa informe senza un vero proprietario.

Cosa dovranno fare i nuovi senior?

Siamo immersi in una vera rivoluzione industriale ed è importante ragionare sul medio termine e non sul breve. Senza essere futurologi, pensiamo a cosa è successo negli ultimi 5 anni e proviamo a traslarlo nei prossimi 5. Il ruolo dei senior cambia. Non è più colui che scrive codice più velocemente o conosce a memoria le API. Non è quello che sa risolvere i problemi più velocemente. La velocità arriverà dagli strumenti, che saranno sempre più efficienti rispetto a una persona. Per questo motivo è necessaria un’evoluzione.

I nuovi senior dovranno sviluppare capacità olistiche trasversali, dovranno capire se si trovano davanti a un’allucinazione o a una verità. Dovranno capire nel modo corretto le specifiche umane, superando quello che dice il testo, e capendo il vero senso di quanto ci viene chiesto, che non è sempre letterale, ma molte volte ha dei risvolti sottintesi che una macchina, ad ora, non è in grado di comprendere.

Dovremo quindi premiare chi sarà in grado di prevenire un debito tecnico generato dall’AI, non chi committa più feature. I KPI devono spostarsi dalla velocità alla stabilità e alla gestione della complessità e del caos.

Non dobbiamo essere più veloci, ma più resilienti

Disinnamoriamoci quindi della velocità: non è l’obiettivo del nostro lavoro. Come CTO dobbiamo pensare a una crescita sostenibile, a un modello di azienda in grado di essere espansa e capita, dobbiamo evitare di essere schiavi di tecnologie che non siamo in grado di governare, mettendoci in una situazione dove le tecnologie sono a servizio dell’azienda e non il contrario.

Investiamo nella formazione, nella comprensione dei processi, nella comprensione delle architetture, facciamo in modo che le persone si specializzino in materie umanistiche in grado di comprendere le persone, rendendole capaci di capire le esigenze del genere umano e di poter criticare in modo intelligente quanto viene proposto e realizzato dalle macchine.

Se l’AI deve entrare nei processi aziendali, facciamolo in modo consapevole, non come un’onda che travolge tutto senza lasciare nulla dietro di sé. Facciamo in modo che l’AI sia essa stessa strumento di crescita e non di distruzione delle competenze: non basta creare, occorre spiegare come e perché si è creato, altrimenti si rischia di costruire castelli di sabbia destinati a crollare al primo soffio di vento.