Project4i: what if sources had a project?

On IBM i there is no such thing as a project.

There are libraries, and libraries are a physical fact. Your invoicing is made of forty sources, but the system does not know that: it knows SRCLIB holds two hundred members, of which forty are invoicing, thirty are ordering, and the rest is archaeology. That grouping lives in the head of whoever works on it, and nowhere else.

Anybody arriving from another world notices on day one. Anybody who grew up here stopped noticing — which is worse, because you pay the cost all the same, you just cannot see it any more.

You pay it when two people open the same source and one of them, that evening, has lost the afternoon's work. You pay it when you have to work out who uses that service program before touching it, and the answer is "ask Franco". Above all you pay it at promotion time: recompiling by hand in the right order, remembering the library list, hoping nobody touched anything meanwhile.

The commercial ALMs for IBM i solve all of this. They are serious products, some of them excellent, and they cost — often a licence per environment, which means the bill multiplies exactly when you decide to do things properly. For the average shop, the one with two developers and a twenty-year-old ERP, they are out of the question.

Project4i comes at it from another direction: an extension for Visual Studio Code, free, MIT licensed.

How it is built, and why the "how" matters

First thing to say, because the name can mislead: the listing calls it IBM Project4i, but it is not an IBM product. It is an independent project by Giuseppe Di Bari, an IBM i engineer with twenty years in banking and fintech, with a small team around him.

The second is the architectural choice that convinced me most: Project4i does not talk to your system.

It rests entirely on Code for IBM i — the extension nearly everybody uses by now — and uses that connection, that authentication, those permissions. It opens no channel of its own. In the extension manifest the dependency is declared as mandatory, not as a suggestion.

It sounds like a technical detail. It is in fact the difference between "I am installing an extension" and "I need approval for a new route into the system", and anybody who has tried to push the second through a company with a security office knows how much that weighs.

What you do with it

The central piece is project groups: a logical set of sources drawn from any library, with QSYS members and IFS files able to sit together. The library boundary stops being the application boundary too. Put like that it sounds small; in daily use it changes how you look at your own code.

On top sits the rest, and these are the things you build by hand when you have no ALM.

The pipeline, with environments ready made — DEV, INT, QA, UAT, STG, PROD, DR — and separate libraries for source, objects, data, configuration, backup and journal. Promotion commands are preconfigured per environment, and the JOBD library list is applied during the move. That part, if you have ever written it by hand in CL, you know what it is worth.

Member locking, the function you notice on your first day working as a pair.

Approval before promotion, maker-checker style: whoever promotes is not whoever approves. With the per-project activity log, it is the ready answer for anybody asking who touched what and when — and sooner or later somebody asks.

The dependency graph, with what they call Impact Analysis 360: who uses this object, and what it depends on. On a codebase layered over decades that is the most expensive question in the trade, the one you answer today by opening ten sources and hoping.

Then there is a detail that says a lot about who wrote it. On promotion, for physical files it uses CRTPF followed by CHGPF instead of recreating: the data stays. And rollback of physical and logical files is deliberately left out — they preferred not to ship a button that, pressed at the wrong moment, deletes data.

Anybody who has worked in production sees the value of that second choice immediately. It is one fewer feature on the leaflet, and it is exactly the missing feature you want.

The AI, without the smoke

There are functions built on language models: technical and functional documentation generated, change-impact analysis, agents that carry out promotions, and a chat you talk to in plain language.

Two things, and they are the right ones.

You bring the model: OpenAI, Azure, watsonx, Copilot, or Ollama locally. If your code must not leave the building — and in a bank it does not — you run the model in house and the discussion ends there.

And if you do not want them, you switch them off. What remains is a pipeline and member locking that work. This is not an AI product dressed as an ALM: it is an ALM that also has AI.

On the build agent declared "zero-hallucination" I am more cautious than they are: what it does is run real CL commands rather than write text describing them, and that narrows the room for invention considerably. The architecture is right. But "zero" is a leaflet word, and as with any automation touching production, you watch the first run.

What it takes

Little: VS Code (or IBM BOB) from version 1.93, Code for IBM i installed and an active connection. You get it from the Marketplace or Open VSX, and a five-step wizard prepares the IFS root, the environments and the pipeline. The AI functions need a model provider, but only if you use them.

Where I am being straight with you

The version is 0.3.8, dated 18 August 2026. A young-project number, and it means what it looks like: live development — the latest two additions are a job inventory and one of procedure signatures — and an interface that may shift between versions.

So no, I would not put a bank's critical production under it next week without having run it for a while. But that is not the right question.

The right question is: what does it cost you to try? And that is the best part of this story. No licence, no negotiation, no demo with a salesman, no new door opened onto the system. You install an extension on a workstation, connect it to development, and run a real application through it for two weeks. If it does not convince you, uninstall it and you have lost nothing. And the code is MIT, so if it does convince you and one day the project stops, you are not held hostage.

The risk, in short, lies entirely in the youth of the project. Not in the design, which was thought out by somebody who knows where things hurt.

Who I would recommend it to

If two or more of you work on the same code and coordinate by talking, member locking alone is worth the install.

If you have several environments and promote by hand, the pipeline gives you time back from the first week.

If somebody asked you for traceability and you gave up because an ALM cost too much, this is the answer that does not cost.

Try it

Search for IBM Project4i in the VS Code Marketplace, or start from project4i.cloud, where the documentation is.

One piece of advice only: do not start with the most delicate project you have. Take a small but real application, run it through the pipeline once, and watch what happens. That run is where you find out whether this way of working is yours — and in my case it took about ten minutes to see that the gap I described at the start has finally been filled by somebody.

Sources

• IBM Community — the author's post, 2 July 2026
• project4i.cloud — official site and documentation
• IBM Project4i on the Visual Studio Marketplace — version, requirements, MIT licence
• Code for IBM i — the mandatory dependency