Cinque competenze che i manager di ingegneria devono rafforzare con l'AI

Il 96% degli sviluppatori non si fida completamente del codice generato dall’AI. LeadDev indica cinque competenze su cui investire: giudizio, mentorship, delega, traduzione e gestione dell’incertezza¹.

Serve validare. Sreenivasa Reddy, staff software engineer in BNSF Railway, lo chiama l’invisible validator: una persona può generare più output con gli agenti, ma qualcuno deve comunque verificarlo. Quel lavoro spesso non compare nei contatori di pull request e commit¹.

Primo punto, giudizio: decidere cosa vale la pena spedire. L’AI propone molte strade in pochi secondi. Un leader deve pesare contesto del cliente, requisiti di sicurezza e, nei settori regolati, la compliance. “L’AI riduce il costo di produrre una risposta, ma non ha ridotto il costo di prendere decisioni sbagliate in produzione”, dice Reddy¹.

Secondo, mentorship: dare ai junior la verifica. Matt Vassar, core lecturer nel Technical Communications Program della Stanford School of Engineering, paragona la situazione a uno specializzando in chirurgia che smette di assistere e guarda un robot operare. Il consiglio è di far scrivere a loro test e criteri di accettazione che l’agente deve soddisfare, così fanno pratica su problemi reali¹. Tiffany Jachja, già senior engineering manager in Yahoo, nota che quando gli agenti producono tanto codice, il lavoro scarso si sposta ai bordi: capire dove gli agenti mancano e come spiegarlo al team¹.

Terzo, delega: smettere di essere il collo di bottiglia. La portata del ruolo cresce, ma saltare dentro e risolvere in prima persona rallenta il team. Jachja segue una regola: mai essere il blocco. Quando sente l’urgenza di accelerare, si chiede cosa sta togliendo a un altro. Reddy descrive il passaggio dalla persona che risolve alla persona che crea le condizioni perché altri risolvano, e pone tre domande: quale contesto manca all’ingegnere, quale domanda lo aiuterebbe a ragionare, dove è giusto che faccia fatica e impari¹.

Quarto, traduzione: spiegare le decisioni come conseguenze. I confronti su budget, organico e roadmap avvengono con chi non condivide il contesto tecnico. Reddy ancora le scelte a metriche già note agli stakeholder, come lead time, change failure rate e time to restore, invece del gergo architetturale. Avverte però contro le semplificazioni eccessive. “Una buona comunicazione tecnica non rimuove la complessità. Seleziona quale parte conta per chi decide, a quel livello”, dice. Jachja lavora sul problema inverso: trovare la frase che faccia percepire l’entità dello sforzo dietro a un tema che sembra una correzione di due minuti¹.

Quinto, gestione dell’incertezza: condividere il piano che esiste. Nessuno sa come saranno i team tra cinque anni. Jachja suggerisce di ascoltare prima, poi condividere il piano che c’è. Vassar invita a dichiarare di non avere tutte le risposte, quindi leggere la stanza: se il team è agitato, portare calma, se è in folle, alzare l’energia. Reddy spiega cosa è noto e cosa no, quale decisione si prende ora e cosa la farebbe rivedere. “Chiarezza non è la stessa cosa di certezza”, conclude¹.

Nel LeadDev 2026 Engineering Leadership Report, il 37% dei manager dice di svolgere più lavoro tecnico hands-on e il 45% lavora più ore rispetto all’anno precedente¹.

Affidare ai junior la proprietà della verifica. Definire test e acceptance criteria per il codice degli agenti. Quando arriva l’impulso di prendere in mano la tastiera, fermarsi e chiedere quale pezzo di crescita si sottrae al team. Raccontare le scelte con lead time, change failure rate e time to restore, senza nascondere la complessità rilevante per chi decide¹.

Man mano che product manager e altri colleghi iniziano a produrre codice, la combinazione di osservazione e comprensione tecnica pesa ancora di più¹.