I team all’avanguardia non utilizzano l’AI soltanto per scrivere codice più velocemente. Stanno ripensando il modo stesso in cui il software viene sviluppato. Questo approccio ha portato a incrementi di produttività significativi, fino a 4,5 volte e oltre.
Sei ingegneri. Settantasei giorni. Un progetto inizialmente stimato per 30 sviluppatori nell’arco di 12-18 mesi completato in meno di un trimestre. È quanto accaduto a un team Amazon Bedrock quando ha iniziato a considerare l’AI non semplicemente come uno strumento per accelerare la scrittura del codice, ma come parte integrante del proprio modo di lavorare. Nei cinque mesi successivi, il team ha rilasciato in produzione una quantità di codice superiore a quella realizzata nei dieci anni precedenti.
Il divario tra team come questo e gli altri si sta allargando rapidamente. Gli agenti AI per la programmazione hanno modificato profondamente la velocità con cui il software può essere scritto, ma non quella con cui arriva agli utenti. I commit aumentano e le pipeline CI/CD sono più impegnate che mai, ma il rilascio di nuove funzionalità in produzione non cresce allo stesso ritmo. Il collo di bottiglia non è la capacità dell’agente di generare output. È piuttosto il suo accesso alle conoscenze di cui ha bisogno per prendere buone decisioni e la disponibilità dei team a riorganizzare il proprio lavoro intorno a questa nuova realtà.
I team che hanno compreso questo passaggio possono essere definiti “frontier team”, team all’avanguardia. Non si trovano soltanto nei laboratori di ricerca più avanzati. Esistono in organizzazioni di dimensioni e settori diversi e condividono un approccio comune: considerano l’adozione dell’AI come un investimento sul modo di fare engineering, non semplicemente come l’introduzione di un nuovo strumento.
Tre percorsi verso lo sviluppo AI-native
Lo sviluppo software AI-native considera l’intelligenza artificiale come una componente fondante del processo, con agenti sempre più capaci guidati da professionisti esperti. Il modo in cui i team guidano tali agenti determina i risultati. In Amazon, i principali fattori che hanno guidato l’adozione dell’AI nello sviluppo sono stati la riduzione del tempo dedicato dagli sviluppatori ad attività non legate alla programmazione, quali la documentazione, il coordinamento e le operazioni operative, l’eliminazione del debito tecnico e la minimizzazione delle incongruenze nel codice tra migliaia di piccoli team di sviluppatori. Le sperimentazioni condotte su centinaia di team di engineering hanno evidenziato almeno tre possibili percorsi: un modello pionieristico con esperti che affrontano una sfida specifica, un ciclo intensivo di sviluppo da eseguire intorno a un piano ben definito e un esperimento in-situ che divide i team a metà tra approcci esistenti e flussi di lavoro adattati all’AI. I percorsi differiscono nella struttura, ma convergono sulla stessa conclusione.
L’iniziativa pionieristica è stata un esperimento controllato. A sei ingegneri senior è stato affidato un unico incarico: ricostruire il motore di inferenza Amazon Bedrock, un progetto inizialmente stimato per 30 sviluppatori con un tempo di realizzazione compreso tra i 12 e i 18 mesi. Anziché aumentare l’organico, il team ha dedicato le prime settimane a riprogettare i flussi di lavoro relativi all’AI, passando da attività discrete a risultati orientati agli obiettivi, eseguendo più agenti in parallelo e configurando sistemi che consentissero all’AI di operare in modo autonomo al di fuori dell’orario di lavoro. Il progetto è stato completato in 76 giorni. La produttività individuale degli sviluppatori è aumentata di circa 20 volte, misurata in base alla velocità di commit normalizzata (il numero di commit per sviluppatore a settimana, adeguato in base alla complessità del repository e alle dimensioni del team). I commit sono passati da 2 a settimana a 40.
Il team ha consegnato più codice di alta qualità in cinque mesi di quanto non avesse fatto nei progetti degli ultimi dieci anni, misurato in base alle righe di codice rilasciate in produzione.
Il ciclo intensivo di sviluppo ha adottato un approccio diverso. Il team Prime Video Financial Systems ha condotto un esperimento di 10 giorni ispirato al modello pionieristico. Sei ingegneri, un unico locale, nessun cambio di contesto, nessun turno di reperibilità, nessun altro progetto, riunioni limitate. Un ingegnere senior ha dedicato tre settimane alla preparazione, scomponendo la complessità in attività ben definite con requisiti dettagliati. Il team ha utilizzato lo sviluppo basato sulle specifiche per le funzionalità complesse e lo sviluppo diretto assistito da agenti per le attività in cui i requisiti erano già chiari. Nel corso dei dieci giorni sono stati prodotti 556 commit, rispetto a una baseline di 96. Una stima di progetto inizialmente pari a 90 settimane è stata ridotta a 24 settimane. Il team ha ricondotto il miglioramento a tre fattori combinati: l’accelerazione delle attività a bassa complessità decisionale (1.5x), una maggiore concentrazione sulle attività che richiedono decisioni più complesse, senza cambi di contesto (1.5x) e l’accesso immediato alle competenze specialistiche acquisite dagli agenti (1.5x). Se si elimina anche solo uno di questi fattori, i risultati precipitano. Il team sta ora cercando di ottimizzare questi tre fattori nelle operazioni di routine, avvalendosi di specifiche di prodotto dettagliate che racchiudono conoscenze specialistiche e di agenti autonomi che consentono di dedicare più tempo alle attività strategiche.
L’esperimento in-situ ha riguardato oltre 50 team. I 25 gruppi che hanno introdotto sia nuovi strumenti sia nuove pratiche di lavoro hanno ottenuto risultati migliori rispetto a quelli che si sono limitati ad aggiungere l’AI ai processi esistenti. Amazon Stores ha condotto progetti pilota strutturati con team di sviluppo standard che lavoravano sui propri backlog abituali, utilizzando Kiro e strumenti di intelligenza artificiale appositamente sviluppati, senza condizioni particolari né ingegneri specificamente selezionati. L’incremento mediano della produttività è stato di 4,5 volte, con alcuni team che hanno raggiunto un miglioramento superiore a 10 volte nella velocità di implementazione normalizzata (funzionalità implementate per ciclo intensivo di sviluppo, normalizzate rispetto ai valori di riferimento storici). In alcuni casi, attività che richiedevano settimane sono state completate nell’arco di una giornata; in altri, la preparazione di documenti di progettazione è passata da diversi giorni a poche ore.
Approcci differenti, quindi, stessa indicazione: conta il workflow, non soltanto lo strumento.
Cinque pratiche per diventare un team all’avanguardia
In tutti e tre i percorsi, i team più performanti condividono cinque pratiche accomunate da una logica comune: ridurre gli ostacoli alla comprensione del contesto da parte dell’agente e ampliare l’ambito di attività che questi può svolgere in modo autonomo.
È proprio qui che i team all’avanguardia si discostano dalle abitudini del passato. L’approccio tradizionale era ottimizzato per la velocità di generazione del codice individuale. I team all’avanguardia puntano invece a qualcosa di diverso: la velocità con cui il software corretto e pronto per la produzione arriva ai clienti. È proprio questa distinzione a guidare ogni pratica descritta di seguito.
1. Investire nel contesto degli agenti. I team all’avanguardia investono molto nel rendere progetti e conoscenze facilmente utilizzabili dagli agenti attraverso file di istruzioni e indicazioni sulle convenzioni adottate dal team, sugli standard di programmazione, sui test e sulle modalità di navigazione della codebase. Il team coinvolto su Amazon Bedrock, per esempio, ha collocato codice e documentazione all’interno di un unico repository e ha mantenuto i commenti generati dagli agenti AI, utilizzandoli come una forma di memoria persistente. Trascurare questa fase determina che gli agenti ripetano gli stessi errori.
2. Rallentare per accelerare. La pratica sopra menzionata richiede tempo e pazienza da parte dei team. Tutti i team altamente performanti hanno riferito che inizialmente il ritmo di lavoro ha subito un rallentamento mentre imparavano a utilizzare i modelli. Hanno codificato le competenze inter-funzionali in documenti guida riutilizzabili per gli agenti, hanno ristrutturato i repository in modo che i modelli di linguaggio di grandi dimensioni (LLM) potessero elaborarli, hanno aggiunto commenti e hanno riprogettato la suddivisione del codice per l’utilizzo da parte dell’AI. I team che hanno superato quella curva di apprendimento e definito i risultati attesi hanno sperimentato per primi un’accelerazione progressiva. I team che si aspettavano risultati immediati senza modificare i propri flussi di lavoro sono rimasti delusi. Ci si deve attendere che le prime due settimane sembrino più lente e quelle successive notevolmente più veloci. I team che hanno rinunciato nella seconda settimana non beneficeranno mai dell’accelerazione progressiva.
3. Alimentare gli agenti invece di supervisionarli continuamente. I team all’avanguardia mantengono un flusso costante di attività ben definite con risultati chiari, eseguendo più agenti in parallelo e revisionando i risultati in modo asincrono. Alcuni sviluppatori riferiscono di portare a termine funzionalità importanti in brevi intervalli di tempo, con il lavoro che procede anche quando non sono attivamente in attesa che l’agente completi un’attività. Un ingegnere senior ha rilasciato una modifica completa con solo “un paio d’ore di tempo consecutivo” perché l’agente ha lavorato mentre lui si dedicava a revisioni del codice, supporto operativo e riunioni.
4. Rendere esplicito l’intento prima di scrivere il codice. Che sia attraverso specifiche strutturate, documenti dettagliati sui requisiti o una suddivisione delle attività ben definita, i team all’avanguardia si assicurano che gli agenti abbiano un quadro chiaro di cosa significhi “completato” prima di iniziare a generare codice. Alcuni team che adottano questo approccio riferiscono di scrivere a mano solo l’1–2% del proprio codice, pur effettuando un numero significativamente maggiore di commit a persona a settimana rispetto a prima.
5. Anticipare i test. I team all’avanguardia sviluppano strumenti che consentono agli agenti di eseguire tutti i test di integrazione in locale e di correggersi autonomamente prima ancora che il codice raggiunga la pipeline. Il team di Prime Video, ad esempio, ha investito in misure di sicurezza automatizzate, test dei componenti, test delle prestazioni e formattatori in grado di individuare i problemi in fase precoce. Le revisioni del codice hanno spostato l’attenzione sulle definizioni delle interfacce e sulle decisioni architetturali, piuttosto che sullo stile del codice e sulle convenzioni di denominazione.
Cosa possono fare oggi i responsabili tecnologici
Non tutti i team ottengono questi risultati. I team che tralasciano la fase di creazione del contesto, considerano l’AI come una semplice sostituzione o si aspettano risultati immediati senza riorganizzare il proprio modo di lavorare ottengono risultati nettamente inferiori alle aspettative.
Diversi sviluppatori hanno adottato strumenti di programmazione basati sull’AI. Non tutti, però, stanno riscontrando miglioramenti in termini di produttività. Non stanno utilizzando gli strumenti sbagliati: stanno utilizzando gli strumenti giusti all’interno di flussi di lavoro sbagliati.
I punti chiave da ricordare sono:
1. Cambiare il modo di lavorare per far funzionare al meglio l’AI
2. Combinare tre fattori per garantire risultati: impiego dell’AI per attività che richiedono decisioni poco complesse x focus costante sulle attività che richiedono decisioni complesse x accesso immediato alle competenze specialistiche.
3. Iniziare con una fase pilota, poi scalare
Il punto di partenza concreto non è un’implementazione su larga scala, bensì un progetto pilota mirato. Si può iniziare con un piccolo team disposto a dedicare le prime settimane alla creazione del contesto degli agenti (file di configurazione, modelli di specifiche, repsoitory unico) prima di scrivere il codice di produzione. Al team può essere dato il compito di ristrutturare i flussi di lavoro, misurando la velocità dei commit, la frequenza dei deployment e i tempi di risoluzione dei problemi, insieme ai livelli di soddisfazione degli sviluppatori. Quanto appreso può quindi diventare una guida operativa per il resto dell’organizzazione.
I team che hanno registrato incrementi di produttività pari a 4,5 volte e, in alcuni casi, superiori a 10 volte non si sono limitati ad adottare una tecnologia migliore. Hanno capito come usarla per lavorare in modo diverso. Questa scelta è oggi alla portata di ogni organizzazione di ingegneria. Naturalmente, la velocità di commit del codice è solo una parte del quadro.
Altre aree del ciclo di vita dello sviluppo software nelle quali l’AI può contribuire comprendono la gestione delle release, le operazioni e le attività di sicurezza, gli aggiornamenti EOL e le innumerevoli attività non differenziate che caratterizzano l’ingegneria del software.
