La trappola dell'altopiano

Di recente ho ha scritto sulla stanchezza da IA, sostenendo che ciò che gli ingegneri stanno vivendo non è una condizione cronica, ma piuttosto un indolenzimento da allenamento. Bisogna resistere, adattarsi e uscirne più forti.

Tutto ciò è valido e sensato, ma c'è dell'altro, e sta diventando sempre più evidente. Il vero rischio che i team di ingegneri corrono in questo momento non è il burnout, bensì la stagnazione.

La nuova spaccatura

Ormai quasi tutti gli ingegneri senior utilizzano l'IA. Copilot, Claude, Cursor, Codex, e chi più ne ha più ne metta. Da questo punto di vista la questione è consolidata. Se sei a capo di un team di ingegneri, probabilmente avrai notato un'ampia diffusione di queste tecnologie e ne sarai soddisfatto.

Non dovresti.

Il numero di adozioni è irrilevante. Ciò che conta è la divisione che si sta verificando al di sotto di esso. Il tuo team si sta silenziosamente dividendo in due gruppi. Ci sono gli ingegneri che hanno beneficiato di un aumento di produttività e si sono stabilizzati, e gli ingegneri che continuano a spingersi oltre ogni settimana. Nuovi flussi di lavoro, nuove configurazioni degli agenti, nuovi modi per scomporre i problemi da far gestire all'IA.

Entrambi i gruppi compaiono nelle vostre dashboard come "utenti che adottano l'IA". Ma uno sta seguendo un programma di allenamento progressivo. L'altro si è fermato al primo peso che ha trovato comodo.

Sei mesi fa, il divario tra questi due gruppi era appena percettibile. Ora è evidente a chiunque presti attenzione. Tra altri sei mesi, sarà strutturale.

Che aspetto ha realmente un altopiano?

L'ingegnere che ha raggiunto un plateau non sta facendo nulla di sbagliato nel senso tradizionale del termine. È competente. Consegna i progetti. Utilizza il suo agente per i lavori semplici e si occupa della pulizia al termine. Ha ottenuto forse un aumento di produttività del 20-30% e si è accontentato.

Il problema è che l'ingegnere accanto a loro non si è fermato lì. Quell'ingegnere ora gestisce flussi di lavoro multi-agente, migliora i cicli di verifica, scompone intere funzionalità in blocchi eseguibili dall'IA, effettua revisioni a livello architetturale invece che riga per riga e rilascia a una velocità 2-3 volte superiore rispetto a prima. Non perché sia ​​più talentuoso. Perché ha continuato ad allenarsi mentre tutti gli altri si sono presi un giorno di riposo che si è trasformato in un trimestre di riposo.

Non si tratta di entusiasmo per l'IA o di essere tra i primi ad adottarla. La fase iniziale è finita. Si tratta di adattamento continuo contro aggiustamenti una tantum. E la differenza, che si accentua progressivamente, tra questi due approcci sta diventando impossibile da ignorare.

La pressione competitiva è reale e in accelerazione

Se i vostri team avessero la possibilità di adattarsi secondo i propri tempi, il problema della fase di stallo si ridurrebbe a una questione di gestione delle prestazioni. Fastidioso, ma gestibile.

Ma se si guarda alla situazione più ampia nel settore del software, è probabile che non ci si possa permettere questo lusso.

L'industria del software, in generale, è nata per aiutare gli esseri umani nel lavoro digitale: aiutare gli operatori dell'assistenza clienti a visualizzare i casi in entrata, monitorare le risposte ai clienti, gestire i flussi di lavoro. Ora gli agenti basati sull'intelligenza artificiale stanno sostituendo l'intero flusso di lavoro, sconvolgendo le piattaforme SaaS sottostanti. Inoltre, con l'IA che diventa ogni giorno più capace, i vostri clienti iniziano a chiedersi: "Dobbiamo ancora acquistare questo prodotto o possiamo svilupparlo noi stessi?". L'IA ha iniziato a ridurre la barriera tra "acquistare" e "sviluppare" per una gamma sempre più ampia di casi d'uso. La fidelizzazione che un tempo proteggeva i vostri ricavi si sta indebolendo di trimestre in trimestre.

I vostri ingegneri, che hanno raggiunto un punto di stallo, operano a un ritmo calibrato per un contesto competitivo che non esiste più.

La citazione che ha cambiato tutto per me

L'ho sentito più di una volta, da product manager che si sono rimboccati le maniche e hanno programmato funzionalità con entusiasmo, da responsabili dell'ingegneria che hanno riprogettato architetture obsolete, in diverse aziende e in diversi contesti:

"Per me è stato più facile collaborare a questo progetto con i miei agenti che con quell'ingegnere."

La prima volta che l'ho sentito, ho pensato che fosse un'iperbole. La terza volta, ho capito che si trattava di un indicatore anticipatore.

A mio avviso, ci sono ingegneri che prospereranno in questo nuovo mondo e saranno dei "moltiplicatori" delle capacità dell'IA. Per farlo, devono essere forti in due aree, entrambe sviluppabili autonomamente con sufficiente motivazione intrinseca e curiosità intellettuale:

• Operano "sulla stessa lunghezza d'onda" dei loro interlocutori (project manager, responsabili di ingegneria, ecc.). Capiscono cosa significa fare bene, quindi non c'è bisogno di spiegare loro le cose in modo eccessivo. Perché se generano lo stesso numero di incomprensioni del vostro agente di programmazione, quest'ultimo vincerà sempre la battaglia. È disponibile istantaneamente, 24 ore su 24, 7 giorni su 7, e instancabile.
• Migliorano costantemente i loro sistemi di intelligenza artificiale, quindi quando affidi loro un compito, sai che verrà svolto non solo bene (vedi il punto precedente), ma anche abbastanza velocemente da stare al passo con i nuovi ritmi del mercato.

Perché questo è un problema di leadership, non un problema individuale.

È facile inquadrare la questione come una responsabilità del singolo ingegnere. "O ti adegui o rimani indietro". Ma se sei a capo di un'organizzazione di ingegneri, questo modo di vedere le cose ti esonera da ogni responsabilità.

I vostri ingegneri, che hanno raggiunto un punto di stallo, non l'hanno fatto per caso. Hanno raggiunto un punto di stallo perché nulla nel loro ambiente li ha spinti oltre il livello iniziale di adattamento. Hanno ottenuto un aumento di produttività apparentemente ragionevole, nessuno li ha spronati ad andare oltre e l'inerzia ha fatto il resto.

Gli ingegneri che hanno continuato a insistere? La maggior parte di loro è automotivata. Avrebbero continuato a insistere a prescindere. Ma non si può riempire un'organizzazione di ingegneri interamente con persone automotivate e sempre alla ricerca di nuove frontiere. La domanda per i leader è: come si fa a far progredire chi si trova nel mezzo?

Questo è un problema di gestione del cambiamento, e uno dei miei modelli preferiti per affrontarlo proviene dal libro dei fratelli Heath. InterruttoreIn breve: bisogna dare alle persone una direzione chiara, far capire loro perché è importante e rimodellare l'ambiente in modo che il nuovo comportamento diventi la via di minor resistenza. Applicato ai team di ingegneri, questo si traduce in:

Individua i tuoi punti di forza e rendili visibili. Individuate gli ingegneri che hanno raggiunto i livelli più avanzati nei loro flussi di lavoro di IA e chiedete loro di presentare regolarmente le proprie soluzioni al team. Non si tratta di sessioni di formazione, ma di dimostrazioni pratiche di lavoro reale. Quando i membri del team che si trovano al centro del processo di sviluppo si accorgono della differenza tra il proprio flusso di lavoro e quello dei colleghi più esperti, si crea un disagio produttivo che nessun obbligo può eguagliare.

• Riduci il resto. "Adottare l'IA" è un obiettivo troppo astratto per poterlo concretizzare. In questo sprint, concentriamoci sui test end-to-end dell'agente, nel prossimo sprint implementiamolo in tutta l'organizzazione e così via. I passi specifici e gestibili sono sempre più efficaci dei programmi di trasformazione ambiziosi, e anche le piccole vittorie contano.
• Rimodellare le impostazioni predefinite. Codifica il processo di verifica nelle competenze di IA e assicurati che venga implementato in tutto il team e da tutti i suoi agenti. Definisci i flussi di lavoro e utilizza gli strumenti che li supportano. Fai in modo che il nuovo metodo di lavoro diventi il ​​percorso più semplice, in modo che le persone lo adottino spontaneamente anziché doverlo forzare.

La finestra si sta chiudendo

Ecco la parte che rende la questione urgente, non solo importante.

Al momento, il divario di adattamento si traduce in una differenza di prestazioni. I vostri ingegneri che hanno raggiunto un punto di stallo sono più lenti di quelli che si sono adattati, ma sono comunque produttivi. Continuano a dare il loro contributo. Potete permetterveli.

Quella finestra di opportunità si sta chiudendo. Con l'accelerazione delle capacità dell'IA e l'intensificarsi della pressione competitiva, il ritmo minimo sostenibile del lavoro di ingegneria si sta alzando. L'ingegnere "sufficientemente bravo" di oggi non ha la garanzia di esserlo anche il prossimo trimestre. Non perché sia ​​peggiorato, ma perché il livello minimo richiesto si è alzato.

Le organizzazioni che riusciranno a far progredire l'intero team lungo la curva di adattamento, e non solo i primi ad adottare le nuove tecnologie, godranno di un vantaggio strutturale cumulativo. Quelle che non ci riusciranno si ritroveranno con un organico adeguato a un ritmo competitivo ormai superato.

Tutti i leader di ingegneria con cui parlo lo comprendono a livello intellettuale. Pochissimi, però, hanno modificato il modo in cui gestiscono i loro team di conseguenza. Il divario tra la comprensione e l'azione rappresenta una sorta di ostacolo insormontabile.

Non esiste un ritmo comodo

Nell'articolo sulla fatica da intelligenza artificiale, sostenevo che il dolore muscolare è la prova che l'allenamento sta funzionando. Questo è ancora vero. Ma la verità che segue è più difficile da accettare: il peso continua ad aumentare.

In una normale palestra, puoi scegliere un peso comodo e mantenerlo per sempre. Nessuno aggiunge dischi al tuo bilanciere senza chiedere il permesso. Nell'attuale panorama software, ad ogni nuova versione, ad ogni nuova funzionalità dell'agente, ad ogni nuovo flusso di lavoro che qualcuno scopre e condivide, il limite si alza. Se rimani fermo, prima o poi il peso ti schiaccerà.

Al momento, nel settore del software non esiste un posto sicuro. Né per i singoli ingegneri, né per i team di cui fanno parte, né per le aziende che questi team contribuiscono a costruire. L'unica posizione sicura è il movimento continuo. E l'unica domanda che conta per i leader del settore ingegneristico è se l'intero team si sta spostando, o solo coloro che si sarebbero spostati comunque.