Sviluppo AI-native: le 5 pratiche dei team che accelerano davvero

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 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 procede 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. Tra i principali fattori che hanno guidato l’adozione dell’AI nello sviluppo vi sono 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 team di sviluppo. Le sperimentazioni condotte su centinaia di team di engineering hanno evidenziato almeno tre percorsi: un modello pionieristico con esperti chiamati ad affrontare una sfida specifica, un ciclo intensivo di sviluppo costruito intorno a un piano ben definito e un esperimento in-situ che ha confrontato team impegnati con approcci esistenti e team che avevano adattato i propri flussi di lavoro all’AI. I percorsi differiscono nella struttura, ma convergono sulla stessa conclusione.

L’iniziativa pionieristica

L’iniziativa pionieristica è stata un esperimento controllato. A sei ingegneri senior è stato affidato un unico incarico: ricostruire un motore di inferenza, un progetto inizialmente stimato per 30 sviluppatori con un tempo di realizzazione compreso tra 12 e 18 mesi. Anziché aumentare l’organico, il team ha dedicato le prime settimane a riprogettare i flussi di lavoro intorno 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 anche 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

Il ciclo intensivo di sviluppo ha adottato un approccio diverso. Un team di sei ingegneri ha condotto un esperimento di dieci giorni ispirato al modello pionieristico. Sei ingegneri, un unico locale, nessun cambio di contesto, nessun turno di reperibilità, nessun altro progetto e 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 ha quindi iniziato a lavorare sull’ottimizzazione di questi tre elementi 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

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. I progetti pilota sono stati condotti con team di sviluppo standard impegnati sui propri backlog abituali, senza condizioni particolari né ingegneri specificamente selezionati. L’incremento mediano della produttività è stato pari a 4,5 volte, mentre alcuni team hanno raggiunto miglioramenti superiori 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 nell’iniziativa pioneristica, 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. Nel ciclo intensivo di sviluppo, ad esempio, il tema 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, repository 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.