Project4i: e se i sorgenti avessero un progetto?

Su IBM i il concetto di progetto non esiste.

Ci sono le librerie, e le librerie sono un fatto fisico. La tua fatturazione è fatta di quaranta sorgenti, ma il sistema non lo sa: sa che in SRCLIB ci sono duecento membri, di cui quaranta sono la fatturazione, trenta l'ordinato, e il resto è archeologia. Quel raggruppamento sta nella testa di chi ci lavora, e da nessun'altra parte.

Chiunque venga da un altro mondo se ne accorge il primo giorno. Chi è cresciuto qui non ci fa più caso — che è peggio, perché il costo lo paghi lo stesso, solo che non lo vedi più.

Lo paghi quando due persone aprono lo stesso sorgente e una delle due, la sera, ha perso il lavoro del pomeriggio. Lo paghi quando devi capire chi usa quel service program prima di toccarlo, e la risposta è "chiedi a Franco". Lo paghi soprattutto in promozione: ricompilare a mano nell'ordine giusto, ricordarsi la lista librerie, sperare che nessuno abbia toccato niente nel frattempo.

Gli ALM commerciali per IBM i risolvono tutto questo. Sono prodotti seri, alcuni ottimi, e costano — spesso con una licenza per ogni ambiente, il che significa che il conto si moltiplica proprio quando decidi di fare le cose per bene. Per l'installazione media italiana, quella da due sviluppatori e un gestionale da vent'anni, sono fuori discussione.

Project4i arriva da un'altra direzione: è un'estensione per Visual Studio Code, gratuita, con licenza MIT.

Come è fatto, e perché quel "come" conta

La prima cosa da dire, perché il nome può ingannare: sulla scheda si chiama IBM Project4i, ma non è un prodotto IBM. È un progetto indipendente di Giuseppe Di Bari, ingegnere IBM i con vent'anni fra banche e fintech, con un piccolo gruppo intorno.

La seconda è la scelta architetturale che mi ha convinto più di tutte: Project4i non parla con il tuo sistema.

Si appoggia interamente a Code for IBM i — l'estensione che ormai usano quasi tutti — e usa quella connessione, quell'autenticazione, quei permessi. Non apre un canale suo. Nel manifesto dell'estensione la dipendenza è dichiarata come obbligatoria, non come suggerimento.

Sembra un dettaglio tecnico. È invece la differenza fra "installo un'estensione" e "faccio approvare una nuova via d'accesso al sistema", e chiunque abbia provato a far passare la seconda in un'azienda con un ufficio sicurezza sa quanto pesa.

Che cosa ci fai

Il pezzo centrale sono i gruppi di progetto: un insieme logico di sorgenti presi da qualunque libreria, con membri di QSYS e file dell'IFS che possono stare insieme. Il confine della libreria smette di essere anche il confine dell'applicazione. Detto così sembra poco; nell'uso quotidiano cambia il modo in cui guardi il tuo stesso codice.

Sopra ci sta il resto, e sono le cose che uno si costruisce a mano quando non ha un ALM.

La pipeline, con gli ambienti già pronti — DEV, INT, QA, UAT, STG, PROD, DR — e librerie separate per sorgenti, oggetti, dati, configurazione, backup e journal. I comandi di promozione si preconfigurano per ambiente, e durante il passaggio viene applicata la lista librerie della JOBD. Quella parte lì, se l'hai mai scritta a mano in CL, sai quanto vale.

Il blocco dei membri, che è la funzione che si nota il primo giorno di lavoro in due.

L'approvazione prima della promozione, in stile maker-checker: chi promuove non è chi approva. Con il registro delle attività per progetto, è la risposta pronta a chiunque chieda chi ha toccato cosa e quando — e prima o poi qualcuno lo chiede.

Il grafo delle dipendenze, con quella che chiamano Impact Analysis 360: chi usa questo oggetto, e da cosa dipende. Su una base di codice stratificata per decenni è la domanda più cara del mestiere, quella che oggi risolvi aprendo dieci sorgenti e sperando.

Poi c'è un dettaglio che dice molto di chi l'ha scritto. In promozione, sui file fisici usa CRTPF seguito da CHGPF invece di ricreare: i dati restano. E il rollback dei file fisici e logici è deliberatamente escluso — hanno preferito non mettere un pulsante che, premuto nel momento sbagliato, cancella dati.

Chi ha lavorato in produzione capisce subito il valore di quella seconda scelta. È una funzione in meno sul volantino, ed è esattamente la funzione in meno che vuoi.

L'intelligenza artificiale, senza il fumo

Ci sono funzioni basate su modelli linguistici: documentazione tecnica e funzionale generata, analisi dell'impatto di una modifica, agenti che eseguono promozioni, e una chat con cui parli in italiano.

Due cose, e sono quelle giuste.

Il modello lo porti tu: OpenAI, Azure, watsonx, Copilot, oppure Ollama in locale. Se il tuo codice non deve uscire dall'azienda fai girare il modello in casa e finisce lì la discussione.

E se non le vuoi, le spegni. Restano una pipeline e un blocco dei membri che funzionano. Non è un prodotto AI travestito da ALM: è un ALM che ha anche l'AI.

Sul build agent dichiarato «a zero allucinazioni» sono più prudente di loro: quello che fa è eseguire comandi CL veri invece di scrivere testo che li descrive, e questo restringe parecchio lo spazio per l'invenzione. L'architettura è giusta. Ma «zero» è una parola da volantino, e come per qualsiasi automazione che tocca la produzione, il primo giro lo guardi.

Che cosa serve

Poco: VS Code (o IBM BOB) dalla versione 1.93, Code for IBM i installato e una connessione attiva. Si prende dal Marketplace o dall'Open VSX, e una procedura guidata in cinque passi prepara la radice sull'IFS, gli ambienti e la pipeline. Per le funzioni AI serve un fornitore di modelli, ma solo se le usi.

Dove sono onesto

La versione è la 0.3.8, del 18 agosto 2026. È un numero da progetto giovane e significa quello che sembra: sviluppo vivo — le ultime due aggiunte sono un inventario dei job e uno delle firme di procedure — e un'interfaccia che fra una versione e l'altra può spostarsi.

Quindi no, non ci metterei sotto la produzione critica di una banca la settimana prossima senza averlo fatto girare per un po'. Ma la domanda giusta non è quella.

La domanda giusta è: quanto ti costa provarlo? Ed è la parte migliore di questa storia. Niente licenza, niente trattativa, niente demo con il commerciale, niente nuova porta aperta sul sistema. Installi un'estensione su una postazione, la colleghi allo sviluppo, ci porti dentro un'applicazione vera per due settimane. Se non ti convince, la disinstalli e non hai perso nulla. E il codice è MIT, quindi se ti convince e un domani il progetto si ferma, non sei in ostaggio.

Il rischio, insomma, sta tutto nella giovinezza del progetto. Non nell'impianto, che è pensato da qualcuno che sa dove fanno male le cose.

A chi lo consiglio

Se lavorate in due o più sullo stesso codice e vi coordinate a voce, il solo blocco dei membri vale l'installazione.

Se avete più ambienti e promuovete a mano, la pipeline vi restituisce tempo dalla prima settimana.

Se qualcuno vi ha chiesto tracciabilità e vi siete arresi perché un ALM costava troppo, questa è la risposta che non costa.

Se invece lavori da solo su un sistema solo, o hai già un ALM commerciale che gira bene, lascia perdere: risolverebbe problemi che non hai, o ne sposterebbe uno che sta già in piedi.

Provalo

Cerca IBM Project4i nel Marketplace di VS Code, o parti da project4i.cloud, dove c'è la documentazione.

Un consiglio solo: non partire dal progetto più delicato che hai. Prendi un'applicazione piccola ma vera, portala attraverso la pipeline una volta sola, e guarda cosa succede. È in quel giro che capisci se questo modo di lavorare è il tuo — e nel mio caso ci sono voluti circa dieci minuti per capire che il buco di cui parlavo all'inizio, finalmente, qualcuno l'ha riempito.

Fonti

• IBM Community — il post dell'autore, 2 luglio 2026
• project4i.cloud — sito ufficiale e documentazione
• IBM Project4i sul Visual Studio Marketplace — versione, requisiti, licenza MIT
• Code for IBM i — la dipendenza obbligatoria