Lo sviluppo software enterprise sta entrando in una fase diversa rispetto alla prima adozione dell’intelligenza artificiale generativa. La questione non è più soltanto scrivere codice più velocemente, ma governare l’intero ciclo che porta quel codice in produzione: analisi, revisione, validazione, modernizzazione, controllo dei costi, qualità, sicurezza e auditabilità.
È su questo terreno che IBM posiziona i nuovi aggiornamenti di IBM Bob, la piattaforma agentica per il software development pensata per portare capacità AI nei diversi punti del ciclo di sviluppo. L’obiettivo dichiarato è superare il modello del semplice assistente di coding, che opera dentro un singolo ambiente e supporta attività isolate, per proporre una base unificata in grado di coordinare agenti, strumenti, workflow e modelli.
Il punto è rilevante perché molte aziende stanno già usando l’AI per generare quantità crescenti di codice, ma stanno scoprendo che il collo di bottiglia si sposta altrove. Secondo il dato GitLab citato da IBM, l’85% dei professionisti DevSecOps intervistati ritiene che l’AI abbia spostato il problema dalla scrittura del codice alla sua revisione e validazione. È una fotografia coerente con ciò che sta accadendo nelle organizzazioni: produrre codice è diventato più facile, ma renderlo affidabile, sicuro e pronto per ambienti produttivi resta complesso.
IBM Bob nasce per affrontare questa seconda fase. Non si limita a generare codice, ma prova a inserirsi nei processi reali di ingegneria software, dove le attività sono distribuite tra team, repository, strumenti di sviluppo, ambienti legacy, pipeline DevSecOps e vincoli di governance. In questo contesto, l’AI non può essere solo un’interfaccia conversazionale. Deve diventare un sistema operativo per coordinare lavoro tecnico complesso.
Sviluppo software enterprise e nuovi colli di bottiglia dell’AI
L’adozione dell’AI nello sviluppo software ha creato un paradosso. Da un lato, i team possono produrre codice, test, bozze di documentazione e refactoring a una velocità molto superiore rispetto al passato. Dall’altro, questa accelerazione rischia di aumentare il carico sulle fasi successive: review, test, validazione architetturale, verifica della sicurezza, controllo della coerenza con gli standard interni e gestione del debito tecnico.
In ambienti enterprise, questo problema è ancora più evidente. Le aziende non sviluppano in un vuoto tecnologico. Operano su portafogli applicativi stratificati, spesso composti da sistemi core, codice legacy, applicazioni Java mature, workload mainframe, ambienti IBM i, integrazioni con sistemi finanziari o industriali, vincoli normativi e processi di change management rigorosi.
In questo scenario, un assistente AI che genera codice non basta. Può anzi produrre nuovo lavoro se gli output non sono coerenti, verificabili o facilmente integrabili. Serve una piattaforma capace di distribuire le attività tra agenti specializzati, mantenere il contesto, chiamare strumenti, gestire costi, misurare utilizzo e applicare workflow ripetibili.
IBM Bob viene aggiornato proprio in questa direzione. La piattaforma introduce capacità multi-agent e funzioni pensate per orchestrare il lavoro AI lungo più passaggi, invece di affidarlo a una singola interazione con un modello. È un’evoluzione sostanziale: nei progetti enterprise, il valore non sta solo nella risposta del modello, ma nella capacità del sistema di completare un processo complesso in modo coerente.
Capacità multi-agent per coordinare attività complesse
Le nuove capacità multi-agent di IBM Bob rispondono a una necessità precisa: suddividere il lavoro software in attività specializzate e coordinate. In un progetto reale, un singolo agente può non essere sufficiente per analizzare una codebase, leggere file, eseguire ricerche, interpretare tracce di funzioni, proporre modifiche, valutarne l’impatto e preparare un output utilizzabile.
Con il supporto ai subagent, Bob può gestire attività complesse in contesti isolati. Questo permette di evitare che ogni passaggio esplorativo saturi la finestra di contesto del modello principale, facendo crescere costi e latenza. Ogni file letto, ricerca eseguita o traccia analizzata può aumentare la quantità di contesto da gestire. Separare parte di queste attività in subagent consente di mantenere più controllato il processo.
Il vantaggio è tecnico ma anche economico. In un ambiente enterprise, l’uso dell’AI su larga scala non può prescindere dalla gestione del costo. Se ogni workflow richiede grandi quantità di token o chiamate ripetute a modelli costosi, il ritorno sull’investimento diventa più difficile da misurare. Bob prova a intervenire non solo sulla scelta del modello, ma sull’intero sistema di esecuzione.
IBM introduce anche il parallel, model-native tool calling. In pratica, Bob consente ai modelli di richiedere più strumenti nello stesso turno ed eseguirli insieme. Questo può ridurre tempi morti e rendere più efficiente l’esecuzione di attività che richiedono accesso a file, funzioni, repository, analisi o strumenti esterni.
Bobalytics e controllo dei costi dell’AI nello sviluppo
Uno degli aggiornamenti più significativi è Bobalytics, la nuova funzione di IBM Bob pensata per offrire visibilità su utilizzo, consumi, produttività, qualità, performance e costi. È un tassello importante perché molte aziende stanno sperimentando l’AI nello sviluppo software senza avere ancora strumenti adeguati per misurare l’impatto reale.
Il problema non è soltanto quanto costa un modello per token. Il costo effettivo dell’AI-driven development dipende da molti fattori: modello usato, numero di chiamate, lunghezza del contesto, complessità del task, strumenti invocati, passaggi intermedi, qualità dell’output, necessità di revisione e tempo risparmiato dal team.
Bob viene presentato da IBM come una piattaforma capace di ottimizzare oltre la semplice selezione del modello. Può abbinare modelli diversi ai task, coordinare agenti e fornire visibilità sull’esecuzione. Questo è un punto cruciale per l’enterprise: senza misurazione, l’adozione dell’AI resta difficile da governare.
Bobalytics risponde quindi a una domanda concreta dei CIO, dei responsabili engineering e dei team platform: dove viene usata l’AI, quanto consuma, quali attività accelera, quali risultati produce e quali costi genera. Senza questa visibilità, il rischio è passare da sperimentazioni promettenti a spese imprevedibili e difficili da giustificare.
La governance dei costi diventa ancora più importante quando l’AI viene applicata a workflow di modernizzazione o sviluppo su larga scala. In questi casi, il numero di passaggi può essere elevato e la variabilità degli output può generare ulteriori cicli di revisione. Un sistema di analytics nativo consente di controllare meglio l’adozione e di allinearla ai mandati interni dell’organizzazione.
Modernizzazione enterprise, il caso IBM Z
Tra le novità più rilevanti ci sono i Premium Packages di IBM Bob, workflow predefiniti e personalizzabili per ambienti enterprise specifici. Il primo riguarda IBM Z, cioè il mondo mainframe che ancora oggi sostiene processi critici in banche, assicurazioni, commercio, pubblica amministrazione e grandi organizzazioni globali.
La modernizzazione dei mainframe è uno dei casi più difficili per l’AI. Non basta generare codice nuovo. Bisogna comprendere sistemi stratificati, logiche applicative accumulate in decenni, dipendenze non sempre documentate, linguaggi come COBOL e PL/I, job JCL, processi batch, vincoli di performance e requisiti di continuità operativa.
IBM Bob introduce workflow AI-native per la modernizzazione di applicazioni IBM Z, compresa la modernizzazione COBOL e PL/I e l’analisi JCL. Il valore di un approccio strutturato sta nella ripetibilità. In progetti di questo tipo, l’output dell’AI non può variare in modo imprevedibile a seconda dell’utente o del prompt. Deve seguire passaggi controllati, documentabili e auditabili.
Per le aziende che operano su mainframe, questa è una differenza sostanziale. La modernizzazione non è un’attività sperimentale: coinvolge sistemi core, spesso con impatto diretto su transazioni, dati sensibili, processi regolati e servizi essenziali. Una piattaforma agentica deve quindi ridurre l’incertezza, non aumentarla.
IBM i e il nodo delle competenze legacy
Il secondo Premium Package riguarda IBM i, una piattaforma che continua a supportare processi mission-critical in molte aziende. Anche qui il problema non è solo tecnico, ma organizzativo. Le competenze su sistemi legacy sono sempre più difficili da reperire e molte imprese devono mantenere, evolvere e integrare applicazioni costruite nel tempo attorno a modelli operativi specifici.
IBM Bob porta capacità AI-native anche in questi ambienti, con integrazione del file system remoto, modalità e strumenti specifici per IBM i e workflow costruiti attorno ai pattern operativi tipici di queste installazioni. L’obiettivo è aiutare i team a comprendere meglio il patrimonio applicativo, accelerare attività di sviluppo e supportare la modernizzazione senza perdere il controllo del contesto.
Il caso citato da IBM di Jack Henry, provider tecnologico per il settore bancario e finanziario, va in questa direzione. L’azienda ha utilizzato IBM Bob per affrontare le sfide legate alla manutenzione e all’evoluzione di una vasta codebase RPG. Kevin Sligar, Chief Technical Architect di Jack Henry, spiega che grazie a IBM Bob gli sviluppatori possono accelerare i workflow RPG, migliorare la qualità del codice e ottenere una comprensione più profonda di decenni di conoscenza accumulata nei sistemi.
Questa frase coglie uno dei punti più importanti della modernizzazione legacy: non si tratta solo di convertire codice, ma di recuperare conoscenza. Molti sistemi critici incorporano regole di business non più documentate in modo completo. L’AI può aiutare a estrarre, spiegare e riorganizzare questa conoscenza, ma deve farlo dentro workflow controllati.
Java modernization e grandi portafogli applicativi
Il terzo Premium Package è dedicato alla modernizzazione Java. Le applicazioni Java enterprise rappresentano ancora una delle aree più ampie e complesse del software aziendale. Molte organizzazioni gestiscono portafogli con versioni diverse del linguaggio, framework obsoleti, dipendenze stratificate, librerie non aggiornate e architetture che devono essere rese più sicure, scalabili e manutenibili.
IBM Bob introduce workflow AI-guided per la modernizzazione Java, inclusa la migrazione a Java 25, il refactoring su larga scala e l’analisi delle dipendenze. Anche in questo caso il punto non è eseguire un singolo intervento, ma rendere il processo strutturato e ripetibile.
La modernizzazione Java è spesso sottovalutata perché il linguaggio è ancora ampiamente diffuso e supportato. Ma proprio questa diffusione rende il problema più esteso. Aggiornare versioni, eliminare dipendenze vulnerabili, razionalizzare architetture e mantenere compatibilità con sistemi esistenti può richiedere molto tempo e competenze specialistiche.
Un workflow agentico può contribuire a ridurre la complessità, soprattutto quando deve analizzare grandi basi di codice, individuare pattern ricorrenti, suggerire modifiche coerenti e mantenere traccia delle decisioni. Tuttavia, anche qui la revisione umana resta essenziale. Nei contesti enterprise, la modernizzazione automatizzata deve essere verificabile, testabile e integrata con pipeline di qualità.
Workflow predefiniti, personalizzabili e auditabili
Il concetto di workflow predefinito è centrale nella strategia di IBM Bob. IBM non propone solo agenti generici, ma pacchetti costruiti su decenni di esperienza nei sistemi enterprise. Questi workflow sono descritti come strutturati, ripetibili, auditabili e personalizzabili.
La distinzione è importante. In un ambiente sperimentale, un utente può provare prompt diversi fino a ottenere un risultato utile. In un ambiente enterprise, questo approccio non scala. Se team diversi modernizzano applicazioni critiche seguendo procedure diverse, l’organizzazione rischia output inconsistenti, difficile tracciabilità e problemi di governance.
Workflow strutturati permettono invece di definire passaggi ricorrenti, criteri di qualità, modalità di analisi e risultati attesi. Possono essere adattati agli ambienti aziendali, ma partono da un modello operativo già orientato al tipo di sistema da modernizzare. È un approccio più vicino alle esigenze dei grandi clienti rispetto al semplice “prompt engineering”.
Il caso Blue Pearl, citato da IBM, mostra la portata della promessa. L’azienda afferma di aver usato IBM Bob in un programma di modernizzazione legacy inizialmente stimato in nove mesi con 14 ingegneri, completandolo in tre giorni. Saireshan Govender, Group CEO di Blue Pearl, sottolinea che il risultato più importante non è stata solo la velocità, ma la combinazione tra efficienza operativa, ottimizzazione dei costi e risultati concreti su cui costruire.
Un dato di questo tipo va letto come caso specifico e non come garanzia replicabile in ogni contesto. Tuttavia, indica il tipo di valore che IBM vuole associare a Bob: accelerare progetti complessi mantenendo affidabilità e controllo.
Da assistente a partner agentico di sviluppo
La dichiarazione di Neel Sundaresan, GM Automation and AI di IBM, chiarisce il posizionamento del prodotto. “Bob is the platform enterprise customers have been asking for”, afferma il manager, aggiungendo che l’asticella dell’AI enterprise non è più un coding assistant migliore, ma un partner agentico end-to-end capace di lavorare dentro i sistemi già usati dai team di sviluppo, con governance, sicurezza e controllo dei costi.
Questa impostazione è coerente con la traiettoria del mercato. Gli strumenti AI per sviluppatori si stanno dividendo tra soluzioni generaliste, assistenti integrati negli IDE, agenti autonomi per attività specifiche e piattaforme enterprise orientate a governance e modernizzazione. IBM punta chiaramente su quest’ultimo segmento.
Il vantaggio competitivo potenziale non è solo la capacità del modello, ma la conoscenza dei domini enterprise. IBM Z, IBM i e Java sono ambienti in cui contano esperienza, strumenti, metodologie e comprensione del contesto operativo. Portare l’AI in questi spazi richiede più di un modello capace di scrivere codice: richiede workflow, policy, integrazioni e capacità di audit.
IBM Bob viene quindi presentato come una piattaforma per rendere l’AI applicabile dove il software è più critico, più stratificato e più difficile da modernizzare. È un posizionamento diverso da quello dei tool pensati per startup, applicazioni greenfield o produttività individuale degli sviluppatori.
Il nodo governance nello sviluppo software con AI
L’adozione dell’AI nello sviluppo software enterprise porta con sé un tema inevitabile: la governance. Più l’AI genera codice, modifica sistemi, analizza repository e propone trasformazioni, più diventa necessario definire regole su accesso, tracciabilità, approvazione, sicurezza e controllo dei costi.
IBM Bob affronta questo tema su più livelli. Le capacità multi-agent e i workflow strutturati puntano a rendere le attività più controllabili. Bobalytics offre visibilità su utilizzo e costi. I Premium Packages cercano di standardizzare attività complesse di modernizzazione. L’insieme di questi elementi risponde a una domanda precisa: come portare l’AI nello sviluppo software senza perdere controllo?
Per le imprese, questa domanda è centrale. Un output AI non può essere trattato come codice automaticamente affidabile. Deve passare da review, test, scansioni di sicurezza, controlli di conformità e validazione funzionale. La differenza è che una piattaforma agentica può aiutare a organizzare questi passaggi, invece di limitarsi a generare artefatti che poi il team deve verificare manualmente.
La governance riguarda anche la selezione dei modelli. In molte organizzazioni, gli sviluppatori scelgono manualmente modelli diversi cercando di bilanciare costo e prestazioni. Il risultato può essere incoerente: qualità variabile, spesa imprevedibile e difficoltà nel misurare l’effettivo impatto dell’AI. Bob punta a coordinare questa scelta in modo più sistemico, abbinando modelli e task all’interno di una piattaforma comune.
IBM Bob e la nuova fase dello sviluppo software enterprise
Gli aggiornamenti di IBM Bob segnalano una fase più matura dell’AI applicata allo sviluppo software enterprise. La prima ondata ha dimostrato che l’AI può scrivere codice, suggerire funzioni, completare frammenti e aiutare gli sviluppatori in attività puntuali. La fase successiva riguarda la capacità di gestire lavoro software complesso, multi-step e ad alto rischio.
Modernizzare un sistema mainframe, intervenire su una codebase RPG, migrare grandi portafogli Java o ridurre il debito tecnico di applicazioni mission-critical non sono attività che si risolvono con un singolo prompt. Richiedono analisi, pianificazione, strumenti, competenze di dominio, test, documentazione e capacità di dimostrare ciò che è stato fatto.
IBM Bob prova a inserirsi in questo spazio come piattaforma agentica end-to-end. Le nuove funzioni multi-agent, il parallel tool calling, i subagent, Bobalytics e i Premium Packages per IBM Z, IBM i e Java Modernization vanno tutti nella stessa direzione: rendere l’AI più utilizzabile, misurabile e governabile nei contesti enterprise.
Per IBM, il messaggio è chiaro. Il valore dell’AI nello sviluppo software non si misurerà solo sulla quantità di codice generato, ma sulla capacità di portare software affidabile in produzione più rapidamente, con costi sotto controllo e processi verificabili. È una prospettiva più realistica rispetto alla narrativa dell’automazione totale, perché riconosce dove si trovano davvero i problemi delle aziende.
In ultima analisi, IBM Bob non viene posizionato come l’ennesimo copilota per scrivere codice, ma come una piattaforma per affrontare la parte più difficile dello sviluppo software enterprise: trasformare sistemi complessi, mantenere qualità e sicurezza, gestire la conoscenza accumulata e rendere l’AI uno strumento operativo dentro processi industriali. È qui che si giocherà la competizione più importante nel software development assistito dall’intelligenza artificiale.
