Accelerare la produzione di codice senza modificare il resto del processo non velocizza la consegna, bensì accelera l'insorgere di problemi in produzione. La velocità di un team di sviluppo non si misura dalla rapidità con cui scrive codice, ma dalla rapidità con cui può apportare modifiche in sicurezza, e questi due aspetti si sono progressivamente disaccoppiati negli ultimi due anni.
Si tratta di un fenomeno misurato, non di un sospetto.
Il rapporto DORA 2024 di Google Cloud, che ha coinvolto circa 39.000 professionisti, ha rilevato che un aumento del 251% nell'adozione dell'IA è correlato a un calo in 1,5% in termini di volume di consegne e da 7.2% in stabilità. La spiegazione fornita dagli autori stessi non è che il codice sia peggiore, ma che la dimensione dei lotti di modifiche stia aumentando: ne viene inviato di più contemporaneamente, viene esaminato in modo meno approfondito e viene distribuito con maggiori rischi.
Lo studio METR del luglio 2025 ha aggiunto un ulteriore elemento. In una sperimentazione controllata con 16 sviluppatori esperti su 246 attività reali, i partecipanti hanno impiegato 191 TP3T in più utilizzando l'assistenza dell'IA, nonostante si aspettassero di essere 241 TP3T più veloci e, dopo il test, credevano ancora di essere stati 201 TP3T più veloci. Vale la pena notare che lo stesso METR ha riesaminato tale studio nel 2026 per individuare potenziali distorsioni di selezione, e una coorte più ampia ha mostrato una differenza molto minore: il risultato esatto è oggetto di dibattito.
Ciò che non è in discussione è il risultato secondario, ed è quello importante per qualsiasi interpretazione: La percezione della velocità e la velocità effettiva sono due cose distinte.. Un team può avere la sensazione di procedere molto più velocemente, anche se il sistema impiega più tempo per raggiungere la fase di produzione.
La dimensione della modifica è la variabile nascosta alla base della maggior parte dei problemi di consegna. Una piccola modifica viene esaminata a fondo, testata completamente, implementata rapidamente e, in caso di errore, la causa può essere identificata in pochi minuti. Una modifica di grandi dimensioni non consente nulla di tutto ciò.
Variabile | piccolo cambiamento | Grande cambiamento |
|---|---|---|
Qualità della recensione | È pienamente compreso | «"Sembra ragionevole"» |
Copertura dei test | Verificabile | Parziale nella pratica |
Tempo di diagnosi in caso di guasto | Minuti | Ore o giorni |
Costo dell'inversione | Basso | Fermati: sta trascinando altre cose. |
Rischio di implementazione | Limitato | Accumulato |
Fino a poco tempo fa, lo sforzo necessario per scrivere il codice rappresentava un limite naturale alla dimensione dei batch. Ora che questo limite è venuto meno, la dimensione dei batch aumenta a meno che qualcuno non decida esplicitamente di limitarla. Questa decisione, ovvero limitare la dimensione delle modifiche, è probabilmente l'intervento più conveniente a disposizione di un team di sviluppo al giorno d'oggi.
Misurare le righe di codice, le attività completate o la "produttività per sviluppatore" peggiora attivamente la situazione perché premia proprio il comportamento che causa il problema. Le quattro metriche DORA rimangono lo standard ragionevole:
Frequenza di impiego. Con quale frequenza un prodotto viene messo in produzione? Un'alta frequenza implica piccoli lotti.
Tempi di consegna per la modifica. Dal momento in cui viene scritto fino alla sua messa in produzione. Misura l'intero processo, non solo la fase di scrittura in sé.
Modificare il tasso di guasto. Quale percentuale di implementazioni si traduce in un incidente? Questo è il contrappeso alla velocità.
Tempo di ripristino del servizio. Quanto tempo ci vuole per riprendersi? Misura l'effettiva capacità di funzionare.
I primi due parametri misurano la velocità, gli ultimi due la stabilità, e devono essere considerati congiuntamente. Un team che migliora i primi due ma peggiora gli ultimi due non è migliorato: ha semplicemente rimandato il lavoro al futuro e al team di supporto.
Limitare l'entità delle modifiche. La misura più semplice ed efficace. Costringe a scomporre il lavoro in unità comprensibili e restituisce qualità alla revisione.
Investite nei test prima di concentrarvi sulla velocità. Man mano che viene generato più codice, la rete di sicurezza diventa più importante, non meno. Senza test affidabili, la riduzione della potenza di calcolo è un azzardo ripetuto.
Automatizza la distribuzione e il ripristino. Se l'implementazione è costosa, il team accumulerà le modifiche finché non ne varrà la pena, e il blocco più grande verrà restituito.
Misura la stabilità con la stessa visibilità della velocità. Se la dashboard del comitato mostra solo le consegne, il team ottimizzerà le consegne.
Non premiare la velocità isolata. Gli incentivi influenzano il comportamento. Se ciò che viene inviato viene celebrato anziché sopportato, si invia di più e si sopporta di meno.
In molti comitati ci si aspetta che l'assistenza dell'IA si traduca in un raddoppio dei risultati nello stesso arco di tempo. È proprio questa aspettativa a generare la pressione che mina la stabilità.
La conversazione onesta si articola in due parti. Primo: la generazione di codice ha effettivamente subito un'accelerazione reale e misurabile. Secondo: la consegna è un processo più ampio – comprensione, revisione, test, integrazione, implementazione e gestione – e accelera solo quando viene affrontato l'intero pacchetto.
Tradotto in una frase che funziona in un consiglio: Abbiamo ridotto il costo di una parte del processo, non dell'intero processo.. Sfruttare appieno tale miglioramento richiede di investire nel resto, non di pretendere il doppio della stessa cosa.
Questa è la stessa conclusione raggiunta dal punto di vista architettonico, ed è per questo che il dibattito è tornato al design piuttosto che all'esecuzione, come abbiamo discusso in Il collo di bottiglia è ancora una volta l'architettura.
Accelera la generazione del codice, ma non necessariamente la sua distribuzione. Il rapporto DORA del 2024 ha rilevato che un aumento di 25% nell'adozione dell'IA è correlato a un calo di 1,5% nella produttività e a un calo di 7,2% nella stabilità, attribuibili alla crescita delle dimensioni dei batch di modifiche.
Perché determina la qualità della revisione, la copertura effettiva dei test, il tempo necessario per diagnosticare eventuali errori e il costo del ripristino. Lo sforzo di scrittura del codice rappresentava un limite naturale alle dimensioni; ora che tale limite è venuto meno, è necessario vincolarlo esplicitamente.
Le quattro metriche DORA sono: frequenza di implementazione, tempo di consegna delle modifiche, tasso di errore delle modifiche e tempo di ripristino del servizio. Le prime due misurano la velocità, mentre le ultime due misurano la stabilità; dovrebbero essere lette congiuntamente.
Uno studio METR del 2025 ha misurato un ritardo di 19% in sviluppatori esperti che si aspettavano di accelerare di 24%. Lo stesso METR ha successivamente esaminato il progetto per individuare potenziali distorsioni, e una coorte più ampia ha mostrato una differenza minore. Il risultato costante è che la velocità percepita e la velocità effettiva divergono.
Test automatizzati affidabili, implementazione e rollback automatizzati e un limite esplicito alla dimensione delle modifiche. Con l'aumentare del volume delle modifiche, la rete di sicurezza e la possibilità di annullare le modifiche diventano più importanti, non meno.
Perché premiano il comportamento che causa il problema: produrre più volume senza garantire che raggiunga la produzione in modo affidabile. L'incentivo determina il comportamento e misurare la produzione anziché i risultati sposta il costo sull'assistenza e sulle esigenze future.
Il tuo team consegna più velocemente o semplicemente produce di più? Analizziamo l'intero processo di erogazione (revisione, test, implementazione e gestione operativa) e vi indichiamo dove si trova il vero collo di bottiglia. Parliamone →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
