I tuoi sistemi hanno già punti ciechi. L’IA li rende ancora più gravi.

Nel 2022, prima che gli strumenti di programmazione generativa facessero parte del nostro lavoro quotidiano di ingegneria, ho scritto sulla mia filosofia di selezione degli strumenti. È risultato più valido di quanto mi aspettassi. All’epoca, sostenevo di partire dai problemi che stavi realmente risolvendo, conoscere le tue debolezze e dare priorità a come usi gli strumenti, invece di lanciarti su qualsiasi strumento sembri il migliore sperando che funzioni. Conosci te stesso e i tuoi obiettivi, così potrai fissare aspettative adeguate per i tuoi strumenti.

All’epoca, pensavo alla proliferazione dei SaaS, non al codice generato dall’IA. Ma oggi la mia filosofia è ancora più urgente e più importante da difendere.

Molti di noi hanno letto il 2025 DORA report, che ha rilevato che, a differenza dell’anno precedente, l’adozione dell’IA ora correlazione positivamente con la produttività di consegna. La scoperta sottostante era che l’instabilità della consegna continuava a crescere, e hanno verificato se i guadagni di velocità la compensassero. Non lo fanno. Questo corrisponde alla nostra esperienza. Il nostro team ha adottato lo sviluppo software agentico e ha registrato un aumento del 48% della produttività in due trimestri, seguito da un aumento del 16% dei problemi di stabilità. Dieci persone sono un campione piccolo, ma è anche un campione dal quale posso vedere l’intero quadro, e il modello è rimasto valido. 

L’adozione dell’IA non è più davvero una questione. O sei appena all’inizio o sei già immerso. Ciò che è diverso ora è che ci si aspetta che i leader dell’ingegneria adottino l’IA e dimostrino anche che ne valga la pena. Il CEO, il consiglio di amministrazione e la finanza vogliono tutti sapere come ottimizzare il loro investimento in IA. Stanno chiedendo se gli strumenti che hai scelto stanno risolvendo i problemi reali in modo efficiente.

Il divario è sempre stato lì. L’IA lo ha semplicemente ampliato.

Come CTO, trascorro buona parte del mio tempo parlando con altri leader dell’ingegneria, inclusi clienti, potenziali clienti e colleghi, per confrontare risultati e lamentele su ciò che stiamo vivendo con l’IA. Dopo numerose di queste conversazioni, ho iniziato a vedere schemi nell’adozione dell’IA e nei risultati.

L’osservazione principale non è mia. DORA ne parla da due anni: l’IA amplifica tutto ciò che sta già accadendo nell’organizzazione, sia i punti di forza che le debolezze. Un team con un’architettura pulita e abitudini di revisione sane diventa più veloce. Un team che ha gestito una palla di debito tecnico sufficientemente per rilasciare codice ora scopre che il debito tecnico sta diventando un ostacolo importante. Ciò che questa inquadratura non coglie, però, è il motivo per cui sorprende così tanti team. L’IA non ha nascosto queste debolezze; i sistemi su cui ci siamo affidati non le hanno mai messe in evidenza.

Lo stack di ticket e report su cui la maggior parte delle organizzazioni di ingegneria si basa è stato creato per rispondere alle domande che gli esseri umani hanno, alla velocità umana, da persone che comprendevano approssimativamente cosa significasse “completato” per un determinato lavoro. Non è mai stato un registro perfetto. È sempre stata un’approssimazione, riempita da qualcuno che riassumeva qualcosa di più caotico sottostante. Ora, l’IA aggiunge volume e nuovi input che generano nuove attività. Nessuno dei sistemi (o strumenti) usati per i metodi tradizionali, non IA, di sviluppo è stato mai costruito per questo.

Comunque, siamo ancora responsabili degli stessi obiettivi. Hai ancora il controllo di velocità, qualità, spesa e di come sta realmente il tuo team. Non puoi più dare per scontato i cruscotti dell’anno scorso.

Qui c’è una obiezione legittima. DORA’s 2026 ROI report descrive una curva a J: un calo di produttività subito dopo l’adozione, dovuto alla curva di apprendimento, al costo di verifica del codice generato dall’IA e ai processi a valle che non hanno ancora raggiunto il passo. Lo chiamano il “costo di formazione” della trasformazione e avvertono i leader di non confonderlo con un fallimento. Giusto. Ma il costo di formazione e un problema reale appaiono identici su un cruscotto basato sui ticket. Se non riesci a capire in quale situazione ti trovi, non sei paziente. Stai indovinando.

Dobbiamo tornare alle basi. Conosci te stesso. Conosci il tuo team. Conosci quali problemi stai risolvendo.

Come “conosci te stesso” con l’IA?

Dalle mie conversazioni, ho identificato cinque aree principali in cui i sistemi convenzionali, costruiti per lavoro generato e segnalato dagli esseri umani, sono ciechi. Ignorarle significa rischiare di amplificare le proprie debolezze continuando ad adottare l’IA.

Punto cieco 1: Teatro della velocità

Più commit e più PR possono dare l’impressione di progresso, e spesso lo sono. L’IA aumenta entrambi i conteggi automaticamente. Uno Stanford case study ha mostrato che l’adozione dell’IA ha aumentato il numero di PR del 14%. Ma ciò che manca è capire quanta di quell’attività sia lavoro di funzionalità rilasciato rispetto a manutenzione, rifacimenti o rotazione derivante da una refactoring che non è stato mantenuto.

Per affrontare questo, monitora la suddivisione tra lavoro di funzionalità e manutenzione, e osserva la frequenza di distribuzione e il lead time rispetto al tuo storico personale, non a una media di settore. Senza tale suddivisione, stai segnalando progressi che non puoi realmente dimostrare.

Punto cieco 2: Debito di revisione

La capacità di revisione non si espande automaticamente con la produzione. La tassa di verifica non è una fase da superare; è parte del costo permanente per lo sviluppo agentico. A un recente sondaggio tra i leader ingegneristici ha rilevato che l’80% dei team dedica almeno il 10% del proprio tempo alla revisione, e circa uno su dieci ne dedica più del 40%. Con tale carico, i team oscillano tra un arretrato in crescita e la convalida acritica, e nessuna delle due è una vera soluzione.

Il vincolo alla consegna non è più la velocità con cui il codice viene scritto. È quanto rapidamente un umano può effettivamente essere sicuro che una modifica sia corretta, quanto rapidamente e con precisione i difetti possono essere rilevati e risolti. Osserva come il carico di revisione è effettivamente distribuito nel tuo team; altrimenti rischi di sovraccaricare i tuoi ingegneri senior, ritardare le tue release o causare gravi problemi di produzione.

Punto cieco 3: Lavoro nascosto

I refactoring e i cambiamenti architetturali tendono a nascondersi all’interno di altri ticket, se appaiono nel sistema di ticket. L’IA genera più di questo tipo di lavoro, non meno. Un agente non esita a toccare dodici file per risolvere un bug, mentre un umano potrebbe fermarsi e riconsiderare. Il lavoro che bypassa il sistema di registrazione bypassa anche la pianificazione, il che significa che il tuo modello di capacità è errato, e ogni previsione costruita su di esso è altrettanto sbagliata. 

Per capire quanto lavoro viene effettivamente svolto, è necessario osservare quanto realmente cambia nella codebase e nella cronologia delle pull request. Senza ciò, il tuo piano di capacità si basa su ciò che le persone hanno ricordato di registrare, non su ciò che hanno realmente fatto. 

Punto cieco 4: Deriva di qualità

Lo stesso sondaggio ha rilevato che quasi la metà dei leader ingegneristici fatica a individuare problemi di sicurezza settimana dopo settimana. Complessità, duplicazione e dipendenze fuori luogo si accumulano attraverso numerosi piccoli cambiamenti, ognuno ragionevole singolarmente. Nessuno di essi appare allarmante da solo. Nello stesso studio di Stanford, la qualità del codice è diminuita del 9% e la sua varianza è più che triplicata. Mentre la media è variata poco, la dispersione (la parte che noti) è cambiata molto. Con il volume dell’IA, questi effetti si compongono più velocemente di quanto la maggior parte dei processi di revisione riesca a catturare. La deriva tende a emergere come un avviso on‑call ricondotto a una dipendenza che nessuno ricorda di aver revisionato. Quando ciò accade, è probabile che un cliente se ne sia accorto per primo.

Osserva le tendenze su problemi di sicurezza, dipendenze e fallimenti e recuperi — non il singolo commit. La complessità e la duplicazione che aumentano nel corso di diverse settimane contano più di qualsiasi singola modifica segnalata in revisione. Senza ciò, rilevi la deriva come fanno ancora la maggior parte dei team: dopo che ha già causato un incidente. 

Punto cieco 5: Spesa non provata

Una volta che l’adozione dell’IA smette di essere un dibattito, la spesa e il ROI dell’IA diventano la questione su cui tutti si concentrano. La finanza vuole sapere cosa è capitalizzabile rispetto a ciò che è operativo. La leadership vuole sapere quale risultato ha prodotto l’investimento. La maggior parte dei team prende ancora decisioni su strumenti, licenze e personale basandosi sull’intuizione, non su prove del legame tra denaro e lavoro consegnato.

Osserva dove lo sforzo ingegneristico fluisce realmente nella codebase stessa, trimestre dopo trimestre — non dove la roadmap dice che dovrebbe fluire. Senza quel collegamento, difendi il budget del prossimo anno con aneddoti, e gli aneddoti non resistono a una conversazione dura con il CFO.

Inizia con ciò che non puoi vedere

La domanda della finanza sulla spesa capitalizzata e una pagina on‑call alle 2 del mattino sembrano non correlate, ma non lo sono. Entrambe possono essere “stimate” dall’attività. Ma entrambe sono effettivamente rispondibili, con evidenze, dal codice stesso.

La risposta di DORA a tutto questo è il sistema ingegneristico stesso: qualità della piattaforma, chiarezza del flusso di lavoro, allineamento del team. Esatto, e non è nemmeno il primo passo. Non puoi sistemare un sistema che non vedi. Ognuna di queste cinque aree è qualcosa che devi poter osservare prima di poter argomentare un investimento.

Il primo passo utile non è uno strumento nuovo o un processo nuovo. È conoscere se stessi, onestamente, e determinare quali di queste cinque aree sono punti ciechi dove mancano prove concrete. La maggior parte dei leader può identificare immediatamente (e sta già prestando attenzione) problemi in una di queste aree. Tuttavia, sono le aree in cui hai meno informazioni a essere quelle più propense a emergere e a morderti man mano che continui ad adottare l’IA.