IBM Bob e il codice RPG: cosa fa davvero e dove si ferma

In dodici mesi lo stesso prodotto ha cambiato nome due volte. Chi ha letto un articolo su watsonx Code Assistant for i nel 2025 e uno su Project Bob nell’autunno dello stesso anno ha letto di due fasi della stessa cosa, e chi cerca oggi la documentazione con il nome vecchio trova materiale superato.

Vale la pena partire da qui, perché nel software per IBM i i cambi di nome sono spesso cambi di sostanza, e in questo caso lo sono stati: quello che oggi si chiama IBM Bob non è la stessa cosa che era stata annunciata come assistente per RPG, ed è disponibile in modo diverso e a un prezzo che nel 2025 non esisteva.

Questo articolo mette in fila cosa fa Bob sul codice RPG, quanto costa, da dove viene la cifra di produttività che tutti citano, e dove si ferma. I dati sono verificati al 31 agosto 2026 e le fonti sono in fondo.

TL;DR

• Bob 1.0 è disponibile in versione generale dal 24 marzo 2026, con l’annuncio di disponibilità globale del 28 aprile 2026. Non è più un preview.
• Bob è un IDE derivato da Visual Studio Code con agenti, non un plugin. IBM lo descrive come piattaforma di orchestrazione multi-modello che smista i compiti fra modelli di frontiera, modelli aperti e la famiglia Granite.
• Le funzioni IBM i stanno in un pacchetto a parte, il Premium Pack, disponibile dal 24 giugno 2026 a 40 dollari al mese oltre all’abbonamento base. Senza quel pacchetto Bob non legge i sorgenti in QSYS.
• Il pacchetto porta una developer mode per RPG, COBOL, DDS, SQL e CL, circa 40 skill (conversione da formato fisso a free-format, sostituzione degli accessi record-level con SQL, generazione di test unitari, estrazione di regole di business) e circa 30 strumenti che agiscono sul sistema, incluse sessioni 5250 e comandi CL.
• Il 45% di produttività che si legge ovunque riguarda gli sviluppatori interni di IBM, non installazioni IBM i di clienti: 6.000 sviluppatori IBM con accesso, circa 3.000 di uso quotidiano, quattro mesi di utilizzo, dato dichiarato dal fornitore.
• Su un parco RPG italiano il valore oggi è concentrato nella comprensione e documentazione del codice esistente. La generazione richiede revisione di qualcuno che conosce la piattaforma, e sono documentati casi di parametri di comando inesistenti proposti come validi.

Negli assessment su codice RPG seguiti da Obsidian Technologies il tempo si concentra sul capire quali programmi sono ancora chiamati e da cosa, più che sul leggere il singolo sorgente, ed è esattamente la parte che un assistente basato su modello oggi non copre, perché richiede lo storico di esecuzione e non il codice.

Da watsonx Code Assistant a Bob: la cronologia

2025. IBM annuncia watsonx Code Assistant for i, costruito su un modello Granite messo a punto per RPG e IBM i, presentato a Think e a COMMON POWERUp. Resta in preview privata.

Ottobre 2025, TechXchange. IBM converge l’assistente per RPG su IBM i e quello per COBOL su System z in un unico prodotto, Project Bob. IT Jungle riporta la ragione in modo asciutto: watsonx Code Assistant for i non stava avanzando abbastanza in fretta rispetto al resto del mercato AI.

24 marzo 2026. Bob 1.0 raggiunge la disponibilità generale.

28 aprile 2026. IBM annuncia la disponibilità globale con comunicato stampa.

24 giugno 2026. Arriva il Bob Premium Pack per IBM i, che è la parte che interessa a chi ha un AS/400.

La cronologia conta per una ragione pratica: la maggior parte dei contenuti in italiano su questo tema è ferma alla fase preview, quando il prodotto si chiamava diversamente, non aveva un prezzo pubblico e non toccava QSYS. Chi valuta oggi sulla base di quei materiali sta valutando un prodotto che non esiste più.

Cosa fa concretamente sul codice RPG

La distinzione che conta è fra Bob base e Bob con il pacchetto IBM i.

Bob base è un ambiente di sviluppo agentico generalista. Legge repository, spiega codice, scrive codice, esegue comandi, si integra via MCP. Su codice RPG funziona se il sorgente sta su PC o in Git, e per un parco IBM i tipico quella condizione non è soddisfatta: i sorgenti stanno in QSYS.

Il Premium Pack rimuove esattamente quel limite. Le capacità dichiarate:

• Supporto nativo ai sorgenti in QSYS, senza doverli prima esportare
• IBM i developer mode, che orienta il modello sulle particolarità della piattaforma per RPG, COBOL, DDS, SQL e CL
• Circa 40 skill, fra cui la conversione di RPG da formato fisso a free-format, la sostituzione degli accessi nativi al database con SQL, la scrittura di test unitari, l’estrazione delle regole di business da un programma, la compilazione, la generazione di file di visualizzazione
• Circa 30 strumenti che agiscono sul sistema: lettura e scrittura su QSYS e IFS, esecuzione di comandi CL e di istruzioni SQL, apertura di sessioni 5250, gestione delle library list
• Aumento con RAG da fonti specifiche di piattaforma, incluse RPG Café e la conoscenza dei compilatori

L’elenco è concreto e va letto per quello che è: sono le operazioni che un programmatore RPG fa in giornata, portate dentro un ambiente dove si chiedono a parole. Il salto rispetto alla fase preview è che Bob agisce sul sistema, invece di limitarsi a spiegare un sorgente che qualcuno gli ha incollato.

Quanto costa

I prezzi sono in dollari, per utente, al mese, e alla data di verifica sono pubblici sul sito del prodotto.

Due cose vanno capite prima di fare il conto.

I Bobcoin sono un consumo, non una tariffa piatta. Ogni piano include una quota mensile e chi la esaurisce ne compra altri. Un uso agentico intenso, che è poi il modo in cui il prodotto rende, consuma più di un uso occasionale, quindi il costo reale dipende dall’intensità e non si conosce prima di provarlo.

Il pacchetto IBM i si somma al piano base. La configurazione minima sensata per un programmatore RPG è quindi un piano base più i 40 dollari, e la scelta del piano dipende da quanti Bobcoin servono, che è la variabile ignota.

Per un team di tre programmatori RPG il costo annuo si colloca su un ordine di grandezza di poche migliaia di dollari, che confrontato con il costo orario di una persona che sa leggere RPG è una cifra piccola. Il punto di attenzione è che questa spesa si aggiunge alle cinque voci che un sistema IBM i ha già, e che abbiamo elencato in quanto costa mantenere un gestionale AS/400.

Il 45% di produttività: da dove viene quel numero

È la cifra che compare in quasi ogni articolo sul prodotto, e vale la pena guardarla da vicino perché viene usata male.

Quando IBM ha presentato Project Bob a TechXchange nell’ottobre 2025, i numeri dichiarati erano questi: 6.000 sviluppatori IBM con accesso allo strumento, circa 3.000 di uso quotidiano e 1.500 a giorni alterni, quattro mesi di utilizzo, e un aumento di produttività del 45% sull’insieme degli sviluppatori.

Tre precisazioni cambiano il peso del dato.

Sono sviluppatori interni di IBM, non clienti con un parco RPG in produzione. Lavorano su codice IBM, con pratiche IBM, dentro l’organizzazione che costruisce lo strumento.

È un dato dichiarato dal fornitore, senza metodologia pubblicata. Non c’è modo di sapere come sia stata misurata la produttività, su quali attività, né quale fosse la linea di base.

Il perimetro non è RPG. L’esempio portato in quella presentazione riguardava aggiornamenti Java e migrazioni di framework, cioè lavoro moderno su codice moderno, che è il caso in cui gli assistenti di codice rendono di più.

Nessuna delle tre precisazioni rende il numero falso. Le tre insieme rendono chiaro che non è un dato trasferibile a una software house italiana con 900 programmi RPG scritti fra il 1998 e il 2012, e che chiunque lo citi in quel contesto lo stia usando fuori dal suo dominio.

Dove si ferma

L’accuratezza sulla piattaforma non è risolta. Sono documentati casi in cui versioni iniziali proponevano parametri di comando che non esistono. Su un sistema dove un comando CL sbagliato può toccare dati di produzione, il vincolo operativo che ne deriva è che l’esecuzione va supervisionata, e questo riduce il guadagno proprio nelle attività dove sarebbe maggiore.

Non sa cosa è vivo. Un modello legge il sorgente che gli si dà. Sapere quali programmi sono ancora chiamati, da quale job, con che frequenza e per quale flusso richiede lo storico di esecuzione del sistema, non il codice. È il lavoro che determina la dimensione di qualunque progetto di modernizzazione, e resta un lavoro di assessment.

Non conosce il vostro dominio. Le regole che contano in un gestionale su misura stanno nelle eccezioni: il cliente che fattura in modo diverso, il magazzino che scala prima e registra dopo. Un modello le legge come codice, non come decisioni aziendali con una storia, e la conversione automatica le porta avanti senza sapere quali erano errori e quali erano scelte.

La conversione a free-format non è modernizzazione. Convertire RPG da formato fisso a free-format e sostituire gli accessi record-level con SQL sono miglioramenti reali di leggibilità e manutenibilità. Non cambiano l’architettura, non separano la logica dall’interfaccia 5250, non producono API. Confondere le due cose è il modo più rapido per spendere un budget di modernizzazione e ritrovarsi con lo stesso sistema scritto meglio.

Non è un sostituto delle competenze. Il valore dello strumento cresce con la competenza di chi lo usa, e su questa piattaforma vale più che altrove, perché serve qualcuno in grado di riconoscere una risposta sbagliata. Su un team senza competenze RPG, Bob non colma il vuoto: lo rende più veloce da attraversare nella direzione sbagliata.

Cosa cambia per un AS/400 italiano

Il caso d’uso con il rapporto valore-rischio migliore oggi non è la generazione di codice. È la documentazione di quello che c’è.

Il parco tipico che vediamo ha centinaia di programmi, documentazione ferma a quindici anni fa, e una o due persone che sanno come funziona. In quella situazione uno strumento che legge un programma e ne produce una spiegazione in italiano leggibile da chi non conosce RPG risolve un problema reale, e lo risolve con un rischio basso, perché l’output è un testo che qualcuno rilegge, non un comando che tocca dati.

Il secondo caso d’uso sensato è l’estrazione delle regole di business in vista di una migrazione. È lo stesso lavoro che l’assessment fa a mano, e uno strumento che lo accelera abbassa il costo della fase più cara delle cinque strategie di migrazione.

Il terzo, più prosaico, è la generazione di test su programmi che non ne hanno mai avuti. Su un sistema dove la paura di toccare il codice è il freno principale, avere test su cui appoggiarsi cambia quello che il team si sente di modificare.

Errori che vediamo fare in questa fase

1. Valutare sulla base dei materiali del 2025. Il prodotto ha cambiato nome, modello di distribuzione e prezzo. I confronti scritti in fase preview non descrivono quello che si compra oggi.

2. Comprare il piano base e scoprire che non legge QSYS. Il pacchetto IBM i è un acquisto separato, ed è quello che rende lo strumento utile su questa piattaforma.

3. Presentare la conversione a free-format come un progetto di modernizzazione. Sono due cose diverse con due budget diversi, e la prima non produce i risultati che si vendono con la seconda.

4. Citare il 45% in un preventivo. È un dato interno IBM su lavoro non-RPG. Metterlo in un documento commerciale espone chi lo scrive alla prima domanda di un cliente informato.

5. Partire dalla generazione invece che dalla comprensione. L’ordine giusto è capire cosa c’è, poi documentarlo, poi eventualmente cambiarlo. Invertirlo è il modo in cui i progetti assistiti dall’AI producono codice nuovo sopra a problemi vecchi non capiti.

FAQ

Bob sostituisce watsonx Code Assistant for i?

Sì. Le capacità dell’assistente per IBM i sono confluite in Bob nell’ottobre 2025, e il prodotto precedente non è la strada su cui IBM sta investendo.

Serve mandare il codice RPG in cloud?

Dipende dalla configurazione scelta. IBM ha dichiarato flessibilità di deployment fra cloud, on-premise e ibrido proprio per i vincoli di governance dei dati. È la prima domanda da fare al rivenditore, ed è la domanda che decide se il prodotto è utilizzabile in contesti soggetti a vincoli contrattuali sui dati.

Funziona in italiano?

Sulle spiegazioni di codice sì, e la qualità dipende dal modello sottostante più che dallo strumento. Sul codice generato la lingua non è la variabile rilevante.

Quanto costa davvero per un team di tre persone?

Tre piani base più tre pacchetti IBM i sono la base, a cui si somma il consumo di Bobcoin, che è la parte imprevedibile. Il modo sensato di scoprirlo è il periodo di prova gratuito con un lavoro reale, non una stima.

Conviene aspettare la prossima versione?

Su una piattaforma che ha visto due cambi di nome in dodici mesi, aspettare ha un costo basso e un beneficio incerto. La ragione per provarlo adesso è diversa: il periodo di prova è gratuito e produce un dato vostro sul vostro codice, che vale più di qualunque valutazione scritta da altri.

Fa la stessa cosa su COBOL?

Il perimetro COBOL è servito dal pacchetto per la modernizzazione IBM Z, che ha un modello di licenza diverso ed è riservato al livello Enterprise. Non è incluso nel pacchetto IBM i.

Il primo lavoro su cui conviene misurarlo

Bob è passato in diciotto mesi da annuncio a prodotto disponibile con un listino pubblico, ed è oggi lo strumento più concreto che esista per lavorare su codice RPG con assistenza di un modello. Questo non lo rende la risposta alla domanda su cosa fare del vostro AS/400, che resta una domanda di piano industriale.

Il modo utile di verificarlo non richiede una decisione. Richiede di prendere un programma solo, fra i più temuti e meno documentati, e chiedere allo strumento di spiegarlo durante il periodo di prova. Poi far leggere quella spiegazione alla persona che quel programma lo conosce. La distanza fra le due versioni è il dato che serve, ed è vostro, non di IBM.

Se avete un parco RPG e volete capire quale parte del lavoro di assessment può essere accelerata e quale no, parliamone.

Per approfondire: IBM i 7.4 fuori supporto dal 30 settembre 2026 per la scadenza che sta muovendo le decisioni in questo momento, e il pilastro modernizzazione dei sistemi legacy.

Fonti: IT Jungle sulla convergenza in Project Bob (ottobre 2025) per i numeri dichiarati da IBM, IT Jungle su Bob 1.0 per la data di disponibilità generale, IT Jungle sul Premium Pack per IBM i per le capacità e la data del pacchetto, e il listino ufficiale per i prezzi. Dati verificati al 31 agosto 2026: trattandosi di un prodotto che in dodici mesi ha cambiato nome due volte, vanno riverificati prima di qualunque decisione di acquisto.