La Trappola della Pianura

Recentemente ho scritto sulla fatica da AI, sostenendo che ciò che gli ingegneri stanno sperimentando non è una condizione cronica, ma una sorta di dolore muscolare da allenamento. Superatelo, adattatevi, uscite più forti.

Tutto ciò è bene e giusto, ma c’è dell’altro in quella storia, e sta diventando sempre più ovvio. Il vero rischio che le squadre di ingegneria stanno affrontando non è il burnout. È la pianura.

La Nuova Divisione

Quasi ogni ingegnere senior utilizza ora l’AI. Copilot, Claude, Cursor, Codex, come si chiama. Quella parte è risolta. Se sei un leader di un’organizzazione di ingegneria, probabilmente vedi numeri di adozione ampi e ti senti bene al riguardo.

Non dovresti.

Il numero di adozione è insignificante. Ciò che conta è la divisione che sta avvenendo al di sotto di esso. La tua squadra si sta dividendo silenziosamente in due gruppi. Ci sono gli ingegneri che hanno ottenuto un aumento della produttività e si sono stabilizzati, e gli ingegneri che continuano a spingere ogni settimana. Nuovi flussi di lavoro, nuove configurazioni di agenti, nuovi modi per decomporre i problemi in modo che l’AI possa gestirli.

Entrambi i gruppi appaiono nei tuoi dashboard come “adottanti dell’AI”. Ma uno è su un programma di formazione progressiva. L’altro si è fermato al primo peso che gli sembrava comodo.

Sei mesi fa, il divario tra questi due gruppi era a malapena visibile. Ora è ovvio a chiunque stia prestando attenzione. In altri sei mesi, sarà strutturale.

Cosa Sembra la Pianura

L’ingegnere sulla pianura non sta facendo nulla di sbagliato nel senso tradizionale. È competente. Spedisce. Utilizza il suo agente per lavori semplici e pulisce dopo di lui. Ha ottenuto forse un aumento della produttività del 20-30% e ha smesso lì.

Il problema è che l’ingegnere accanto a lui non si è fermato lì. Quell’ingegnere sta ora eseguendo flussi di lavoro multi-agente, migliorando i loop di verifica, decomponendo intere funzionalità in chunk eseguibili dall’AI, esaminando a livello architettonico invece che riga per riga, e spedendo al doppio o triplo del loro ritmo precedente. Non perché siano più talentuosi. Perché hanno continuato ad addestrarsi mentre tutti gli altri si sono fermati.

Non si tratta di entusiasmo per l’AI o di essere un adottante precoce. La fase di adozione precoce è finita. Si tratta di adattamento continuo versus regolazione una tantum. E la differenza composta tra questi due approcci sta diventando impossibile da ignorare.

La Pressione Competitiva è Reale e si Sta Accelerando

Se le tue squadre avessero avuto il lusso di adattarsi al proprio ritmo, il problema della pianura sarebbe stato un problema di gestione delle prestazioni. Fastidioso, ma gestibile.

Ma se guardi alla situazione più ampia nell’industria del software, è probabile che non abbiate quel lusso.

L’industria del software, in generale, è stata creata per aiutare gli esseri umani con il lavoro digitale: aiutare gli agenti di supporto a vedere i casi in entrata, tenere traccia delle risposte ai clienti, gestire i flussi di lavoro. Ora gli agenti AI stanno sostituendo l’intero flusso di lavoro e, con esso, stanno disturbando le piattaforme SaaS sottostanti. Inoltre, con l’AI che diventa sempre più capace ogni giorno, i tuoi clienti iniziano a chiedersi: “Dobbiamo ancora comprarlo, o possiamo costruirlo noi stessi adesso?” L’AI ha iniziato a ridurre la barriera tra “acquisto” e “costruzione” per un insieme in espansione di casi d’uso. L’adesione che un tempo proteggeva i tuoi ricavi si sta indebolendo ogni trimestre.

I tuoi ingegneri sulla pianura stanno operando a un ritmo calibrato per un ambiente competitivo che non esiste più.

La Citazione che Ha Riformulato Tutto per Me

L’ho sentito più di una volta, da manager di prodotto che hanno rimboccato le maniche e hanno codificato funzionalità, da leader di ingegneria che hanno ridisegnato architetture fallite, in diverse aziende, in diversi contesti:

“È stato più facile per me iterare su questo con i miei agenti, piuttosto che con quell’ingegnere.”

La prima volta che l’ho sentito, ho pensato che fosse un’esagerazione. La terza volta, ho capito che era un indicatore principale.

Come la vedo io, ci sono ingegneri che prospereranno in questo nuovo mondo e saranno “moltiplicatori” delle capacità dell’AI. Per farlo, devono essere forti in due aree, entrambe delle quali possono essere sviluppate con sufficiente motivazione intrinseca e curiosità intellettuale:

• Operano “nella stessa onda” dei loro stakeholder (PM, manager di ingegneria, ecc.). Capiscono cosa significa “buono”, quindi non devi spiegare loro le cose. Perché se producono lo stesso numero di incomprensioni del tuo agente di codifica, l’agente vincerà sempre quella battaglia. È disponibile istantaneamente, 24 ore su 24, e senza sosta.
• Migliorano costantemente le loro configurazioni dell’AI, quindi quando gli affidi qualcosa, sai che sarà fatto non solo bene (vedi il punto sopra), ma anche abbastanza velocemente per stare al passo con il nuovo ritmo del mercato.

Perché Questo è un Problema di Leadership, non Individuale

È tentante inquadrarlo come responsabilità dell’ingegnere individuale. “Mantieniti al passo o rimani indietro.” Ma se guidi un’organizzazione di ingegneria, quel tipo di inquadramento ti fa uscire dal giro.

I tuoi ingegneri sulla pianura non si sono fermati nel vuoto. Si sono fermati perché nulla nel loro ambiente li ha spinti oltre il primo adattamento. Hanno raggiunto un aumento della produttività che sembrava ragionevole e nessuno li ha sfidati a fare di più, e l’inerzia ha fatto il resto.

Gli ingegneri che hanno continuato a spingere? La maggior parte di loro è auto-motivata. Avrebbero spinto comunque. Ma non puoi assumere un’intera organizzazione di ingegneria con solo cercatori di frontiera auto-motivati. La domanda per i leader è: come si sposta il centro?

Questo è un problema di gestione del cambiamento, e una delle mie cornici preferite per questo proviene dal libro Switch dei fratelli Heath. La versione breve: devi dare alle persone una direzione chiara, far loro sentire perché conta, e ridisegnare l’ambiente in modo che il nuovo comportamento sia il percorso più facile. Applicato alle squadre di ingegneria, sembra:

Trova i tuoi punti luminosi e rendili visibili. Identifica gli ingegneri che hanno spinto più lontano nei loro flussi di lavoro dell’AI e fallo dimostrare regolarmente alla squadra. Non sessioni di formazione. Dimostrazioni live di lavoro reale. Quando il centro della tua squadra vede la differenza tra il loro flusso di lavoro e quello del miglior adattatore, crea un disagio produttivo che nessun mandato può eguagliare.

• Riduci il cambiamento. “Adottare l’AI” è troppo astratto per agire. Questo sprint, fissa il test agente da fine a fine, nel prossimo sprint distribuiscilo in tutta l’organizzazione, e così via. Passi specifici e gestibili battono sempre programmi di trasformazione ambiziosi, e le piccole vittorie contano.
• Ridisegna i default. Codifica il processo di verifica nelle competenze dell’AI, e assicurati che vengano distribuite in tutta la tua squadra e in tutti i loro agenti. Definisci i tuoi flussi di lavoro e utilizza gli strumenti che supportano ciò. Rendi il nuovo modo di lavorare il percorso più facile, in modo che le persone si dirigano lì invece di dover lottare per arrivarci.

La Finestra si Sta Chiudendo

Ecco la parte che rende questo urgente piuttosto che semplicemente importante.

Al momento, il divario di adattamento è una differenza di prestazioni. I tuoi ingegneri sulla pianura sono più lenti dei tuoi adattati, ma sono ancora produttivi. Contribuiscono ancora. Puoi portarli.

Quella finestra si sta chiudendo. Man mano che le capacità dell’AI si accelerano e la pressione competitiva si accumula, il ritmo minimo di lavoro di ingegneria sta aumentando. L’ingegnere “abbastanza buono” di oggi non è garantito per essere abbastanza buono nel prossimo trimestre. Non perché sia peggiorato, ma perché il pavimento si è alzato.

Le organizzazioni che riescono a spostare l’intera squadra sulla curva di adattamento, non solo gli adottanti precoci, avranno un vantaggio strutturale composto. Quelle che non lo faranno si troveranno a essere state assunte per un ritmo di competizione che non esiste più.

Ogni leader di ingegneria con cui parlo capisce questo intellettualmente. Pochi hanno cambiato il modo in cui gestiscono le loro squadre in risposta. Il divario tra comprensione e azione è a sua volta una sorta di pianura.

Non C’è un Ritmo Comodo

Nell’articolo sulla fatica da AI, ho sostenuto che il dolore muscolare è la prova che l’allenamento sta funzionando. Questo è ancora vero. Ma la verità successiva è più dura: il peso continua a salire.

In una palestra normale, puoi scegliere un peso comodo e mantenerlo per sempre. Nessuno aggiunge piatti alla tua barra senza chiedere. Nel paesaggio software attuale, ogni nuova release di modello, ogni nuova capacità di agente, ogni nuovo flusso di lavoro che qualcuno scopre e condivide, la barra si sposta. Resta fermo e il peso alla fine ti schiaccerà.

Non c’è uno spazio comodo nell’industria del software al momento. Non per gli ingegneri individuali, non per le squadre in cui lavorano, non per le aziende che quelle squadre costruiscono. La sola posizione sicura è il movimento continuo. E la sola domanda che conta per i leader di ingegneria è se l’intera squadra si sta muovendo, o solo quelli che si sarebbero mossi comunque.