Accelerare il ciclo di vita della distribuzione del software con l'AI generativa: lezioni tratte da Enterprise Payment Services di IBM

Tre mesi fa, il backlog dei test di regressione e il tempo di esecuzione del mio team erano un ostacolo persistente per ogni sprint. Oggi, Bob ha ridotto il nostro sforzo di test di oltre il 70%. Questo risultato è stato raggiunto grazie all'implementazione di IBM Bob™, l'assistente di sviluppo AI di IBM, integrato nativamente nel workflow di test e membro a pieno titolo del nostro team di test. Dimostra che la distribuzione di software potenziata da AI non è più un concetto futuro.

I team di ingegneri del software si trovano ad affrontare una pressione crescente proveniente simultaneamente da più direzioni. Gli organismi di regolamentazione stanno rafforzando i requisiti normativi. Gli auditor della sicurezza richiedono maggiore visibilità sulla gestione delle vulnerabilità e sulle tempistiche di correzione. Nel frattempo, i clienti stanno accelerando le loro richieste funzionali, prevedendo un time-to-market più rapido senza alcun impatto sulla qualità o sulla stabilità.

Il team IBM Payment Center® Enterprise Payment Services (EPS) gestisce una piattaforma di pagamenti di alto valore e altamente regolamentata, e noi conviviamo quotidianamente con queste pressioni. Le piattaforme di pagamento si trovano all'incrocio di tutti questi elementi: regolamentazione finanziaria, obblighi di resilienza operativa, controlli di sicurezza rigorosi ed esigenze competitive dei clienti convergono in un unica codebase.

La domanda a cui ho deciso di rispondere quest'anno è semplice: come possiamo fare di più, più velocemente, con le stesse persone, senza sacrificare la qualità o la stabilità?

La risposta è l'AI generativa, in particolare IBM Bob, che abbiamo inserito all'inizio del 2026 come membro a pieno titolo del team di ingegneria EPS. Abbiamo ottenuto progressi significativi in pochi mesi. Questi risultati riflettono una trasformazione più ampia in corso in tutto il settore.

L'AI generativa non è più un esperimento pilota confinato ai suggerimenti di autocompletamento. Viene integrata in ogni disciplina principale del ciclo di vita dello sviluppo del software (SDLC), dalla raccolta dei requisiti alla gestione degli incidenti in produzione. I risultati sono talmente convincenti che le organizzazioni che non stanno ancora investendo subiranno un reale svantaggio competitivo.

La nostra esperienza si integra perfettamente nell'intero arco della distribuzione del software. Esaminiamo da vicino ogni fase.

Requisiti: trasformare il rumore in struttura
 

La fase di raccolta dei requisiti è sempre stata quella più ambigua e con il maggior potenziale di aumento dei costi a valle. Una definizione dei requisiti inadeguata è la causa principale di una quota sproporzionata di rilavorazioni di progetto, mancato raggiungimento degli obiettivi e introduzione di difetti. Un difetto riscontrato nei requisiti costa una frazione di uno rilevato in produzione.

L'AI generativa cambia radicalmente l'economia di questa fase. Nel contesto EPS, Bob gestisce:

• Generazione rapida di storie di utenti e documentazione:trasforma le note delle riunioni e le conversazioni con gli stakeholder direttamente in storie di utenti e criteri di accettazione strutturati e pronti per Jira.
• Identificazione dei requisiti mancanti: analisi delle storie esistenti rispetto al contesto aziendale e segnalazione delle lacune che gli analisti aziendali umani potrebbero non cogliere fino alla fine dello sprint.
• Traduzione di input non strutturati: conversione di trascrizioni, e-mail e note informali in artefatti di requisiti formali.

Abbiamo osservato miglioramenti della produttività del 30-40% nella fase dei requisiti utilizzando Bob per assistere gli analisti aziendali, principalmente attraverso l'eliminazione del lavoro di trascrizione manuale, riformattazione e riferimenti incrociati. Queste stime, misurate dal team, si basano sul lavoro svolto dagli analisti aziendali prima e dopo l'ingresso di Bob nel team.

Il fattore chiave è la consapevolezza contestuale di Bob. Abbiamo caricato su di esso l'intera documentazione della piattaforma, gli standard normativi, gli standard di codifica e i requisiti non funzionali. Questo fondamento garantisce che i requisiti generati riflettano le realtà architettoniche e normative di una piattaforma di pagamento, anziché limitarsi a essere semplicemente corretti dal punto di vista sintattico.

Progettazione e sviluppo: la più grande opportunità
 

Lo sviluppo è l'ambito in cui viene impiegata la maggior parte delle ore di progettazione e, di conseguenza, è lì che l'AI generativa offre il maggior potenziale trasformativo. Le proiezioni di IBM per Bob nella fase di progettazione indicano un miglioramento dell'efficienza del 30-50%, un intervallo che riflette l'ampiezza delle attività di progettazione e la profondità del contesto richiesta per ciascuna di esse.

Nella nostra implementazione, puntiamo ad accelerare i processi ingegneristici lungo tre direttrici. In ciascuna, Bob opera in modalità semi-autonoma, svolgendo il lavoro mentre un esperto della materia esamina e convalida l'output prima dell'accettazione. Questo abbinamento non è una limitazione; è il modello architettonico corretto per l'AI in questa fase di maturità.

1. Revisioni del codice assistite da Bob: Bob ha avuto accesso al repository di codice sorgente EPS ed esegue revisioni del codice affiancando revisori umani esperti in materia (SME). Questo approccio a doppia revisione garantisce la conformità ai requisiti normativi, agli standard di sicurezza e privacy e ai requisiti architetturali (sia funzionali che non funzionali), individuando i difetti durante lo sviluppo piuttosto che durante i test o la produzione. Una ricerca di GitHub su Copilot ha riscontrato che la revisione del codice assistita dall'AI ha individuato il 15-20% in più di problemi rilevanti per la sicurezza per ogni ciclo di pull request e ha ridotto i tempi di risoluzione grazie al fatto che l'IA proponeva modifiche correttive (diff) contestualmente alle criticità segnalate.
2. Gestione delle vulnerabilità e aggiornamenti: man mano che le versioni linguistiche e delle librerie si evolvono e i requisiti normativi cambiano, Bob valuta il raggio d'azione di un aggiornamento della libreria in tutta la codebase. Identifica i siti di chiamata incompatibili e raccomanda le modifiche necessarie in pochi minuti, un lavoro che in precedenza richiedeva ai tecnici senior di dedicare giorni al tracciamento manuale delle dipendenze.
3. Generazione e modifica del codice: Bob fornisce raccomandazioni per modificare il codice esistente in base a requisiti chiari (funzionali e non funzionali), contesto della codebase e vincoli normativi rilevanti. Un AI che genera codice per l'elaborazione dei pagamenti senza consapevolezza delle normative sulla residenza dei dati, degli standard di gestione degli errori o degli obblighi normativi è una responsabilità, non un asset. Caricare Bob con quel contesto in anticipo risolve direttamente questa sfida.

Test: eliminazione il collo di bottiglia
 

Storicamente, i test hanno rappresentato il principale fattore limitante nella velocità di consegna del software. I team di sviluppo producono codice più velocemente di quanto i team di QA possano convalidarlo. Questa asimmetria è il driver principale alla base del riporto di attività tra sprint, dei ritardi nel rilascio e dell'accumulo di backlog nei test di regressione.

I risultati del nostro team di QA sono i più maturi e i più sorprendenti. Tre mesi dopo aver implementato Bob come generatore di automazione dei test per la piattaforma di pagamento EPS Wires, abbiamo raggiunto i seguenti risultati:

• Riduzione del 70% nella creazione di automazioni dei test 
• Riduzione del 90% del backlog dei test di regressione
• Riduzione dell'80% nel tempo di esecuzione del ciclo di regressione

Questi risultati non rappresentano miglioramenti marginali. Rappresentano una trasformazione strutturale nel modo in cui opera il team. Gli ingegneri QA sono passati dalla scrittura di automazione dei test alla revisione e raffinamento dei test generati dall'AI, un'attività che utilizza meglio le risorse. L'integrazione della pipeline CI/CD fa sì che gli errori di regressione emergano nel giro di poche ore dal commit, anziché giorni, riducendo drasticamente i costi associati a una modifica difettosa.

Questa esperienza è coerente con osservazioni più ampie del settore. La ricerca su organizzazioni che implementano l'AI generativa per la generazione di test ha riscontrato riduzioni medie del 60% nel ciclo di regressione, con implementazioni ad alte prestazioni, come la nostra, che ottengono guadagni ancora maggiori. Il fattore distintivo costante è il contesto: i generatori di test AI con accesso all'intera codebase, ai casi di test esistenti e ai requisiti aziendali producono test molto migliori rispetto ai sistemi che operano solo su frammenti di codice.

IBM Bob, completo del repository GitHub di EPS, degli standard normativi e della documentazione funzionale, è un esempio di questo approccio contestualizzato.

Design e architettura: miglioramento proattivo
 

L'AI generativa sta iniziando a svolgere un ruolo nell'intelligenza di progettazione proattiva. Si sta andando oltre il ciclo reattivo di creazione e test di ciò che è già stato specificato. La nostra roadmap include la possibilità di consentire a Bob di:

• Identificare colli di bottiglia nelle prestazioni non riconosciuti e inefficienze architettoniche accumulate nel tempo.
• Valutare e dare priorità all'eliminazione del debito tecnico correlando la struttura del codice con la cronologia degli incidenti e i dati sulle prestazioni.
• Generare raccomandazioni di progettazione per nuovi miglioramenti funzionali considerando l'architettura esistente, i vincoli normativi e i requisiti non funzionali.

Questo approccio è un caso d'uso più sofisticato rispetto alla modifica del codice o all'automazione dei test e richiede un livello più elevato di fiducia contestuale nelle raccomandazioni di Bob. Mantenere gli architetti umani aggiornati per convalidare le raccomandazioni prima di agire su di esse è la posizione giusta per questa fase di maturità dell'AI.

Il valore è significativo: un sistema che ha assorbito l'intera codebase, la sua architettura documentata e anni di decisioni progettuali può far emergere insight che altrimenti richiederebbero settimane di ricerca.

Supporto di livello 3: chiusura del ciclo
 

Il caso d'uso dell'AI con maggiore impatto operativo sulla nostra roadmap è l'accelerazione della risoluzione degli incidenti. Il supporto L3 per una piattaforma di pagamento di alto valore è un'attività ad alto rischio e sensibile al fattore tempo. Quando si verifica un incidente di produzione, il tempo necessario per identificare e risolvere la causa principale determina direttamente l'impatto sul cliente.

La roadmap di implementazione SDLC di Bob include l'analisi degli incidenti di supporto L3, la correlazione dei sintomi segnalati con i percorsi di codice nel repository, l'identificazione delle cause principali probabili e la proposta di azioni correttive. Lo stesso contesto che rende Bob efficace come revisore di codice, ovvero la conoscenza approfondita del codice sorgente, dei requisiti normativi e dei modelli di gestione degli errori, lo rende particolarmente adatto a questo compito.

Un ingegnere L3 umano, supportato da Bob, può scansionare l'intero codice sorgente in pochi secondi alla ricerca di pattern che corrispondano alla firma di un incidente, accelerando la risoluzione dell'incidente e minimizzando l'impatto sul cliente.

Nessuna di queste attività produttive è priva di rischi. I sistemi di AI generativa possono avere allucinazioni. Possono produrre output plausibili ma errati con apparente sicurezza. In una piattaforma di pagamento soggetta a controlli normativi, una modifica al codice generata dall'AI senza adeguata revisione o un caso di test specificato in modo errato possono avere gravi conseguenze a valle.

Il nostro framework di gestione del rischio è costruito intorno al modello semi-autonomo: Bob viene implementato come membro del team profondamente integrato in ogni fase dell'SDLC, sempre affiancato da un revisore umano che convalida l'output prima che venga accettato. Gli analisti aziendali esaminano i requisiti generati da Bob. I proprietari del codice esaminano i bug identificati da Bob e le correzioni proposte. Gli ingegneri QA esaminano i casi di test generati da Bob. Gli ingegneri L3 esamineranno le analisi degli incidenti di Bob.

Questo approccio non costituisce una limitazione. È il modello architettonico corretto per l'AI in questa fase di maturità. Il modello scambia una frazione del limite di efficienza teorico con una sostanziale riduzione del rischio di errore e lo fa in modo da consentire la costruzione incrementale della fiducia.

Poiché gli output di Bob si dimostrano affidabili in ogni dominio, il livello di controllo umano può essere calibrato in modo appropriato. Mi aspetto che questa configurazione semi-autonoma rimanga la norma per diversi anni, con Bob che continua ad apprendere dall'esperienza e a produrre output di qualità progressivamente superiore nel tempo.

Tra requisiti, progettazione e test, IBM prevede un miglioramento dell'efficienza dal 25% al 70% da parte di Bob, a seconda della fase e dell'attività specifica. Anche se i risultati si stabilizzano all'estremità conservativa di ogni intervallo, l'effetto cumulativo all'interno del team equivale a un aumento del 25–40% della capacità effettiva del team.

Per illustrare concretamente il concetto, consideriamo un team di 10 persone che ottiene un aumento di efficienza complessivo del 30% in tutte le fasi del ciclo di vita dello sviluppo del software (SDLC). L'output effettivo equivale a quello di 13 ingegneri che lavorano al ritmo originario, senza aumentare l'organico né incrementare i costi in proporzione.

Per un'organizzazione che deve affrontare un'accelerazione della domanda con un budget fisso, questo non è un miglioramento incrementale. È un moltiplicatore di capacità che permette allo stesso team di offrire più funzionalità, mantenere una qualità superiore, rispondere più rapidamente agli incidenti e assorbire obblighi normativi crescenti senza un aumento proporzionale dei costi.

La nostra esperienza fa emergere tre domande su cui ogni responsabile di progettazione dovrebbe affrontare in questo momento:

1. Come contestualizzate l'AI per il vostro ambiente? L'approccio EPS, che prevede di fornire a Bob in anticipo il la codebase, gli standard, i requisiti normativi e la documentazione, costituisce il fondamento di tutto ciò che segue. Un assistente AI che opera senza questo contesto è meno prezioso, e potenzialmente più rischioso, di uno adeguatamente ancorato a tale contesto.
2. Da dove si comincia? I test sono il percorso più veloce verso un ROI misurabile, come dimostrano i nostri risultati. La combinazione di criteri di successo chiari, una soglia di rischio relativamente bassa e un elevato sforzo manuale nella situazione attuale lo rende il caposaldo ideale per qualsiasi team che inizia questo percorso.
3. Come si gestisce la fiducia in modo incrementale? Il modello semi-autonomo, ovvero AI con l'intervento umano, non rappresenta un compromesso. Si tratta di un modello di implementazione responsabile che consente alle organizzazioni di catturare valore costruendo al contempo la fiducia istituzionale necessaria per espandere nel tempo il ruolo dell'AI.

Il percorso del mio team, da una funzione di QA manuale e limitata da backlog, a un'organizzazione di qualità potenziata dall'AI e integrata con CI/CD in tre mesi dimostra che questa trasformazione è realizzabile rapidamente. La lezione più ampia è chiara: l'AI generativa incorporata nell'SDLC non è un programma pilota futuro. Sta già offrendo risultati misurabili per i team che hanno effettuato l'investimento. Il momento di costruire quelle fondamenta è adesso.