IBM Bob and RPG code: what it actually does and where it stops

In twelve months the same product changed name twice. Anyone who read a piece about watsonx Code Assistant for i in 2025 and another about Project Bob in the autumn of the same year read about two phases of one thing, and anyone searching today under the old name finds superseded material.

It is worth starting there, because in IBM i software a change of name is often a change of substance, and here it was: what is now called IBM Bob is a different thing from what was announced as an RPG assistant, available in a different way and at a price that did not exist in 2025.

This article sets out what Bob does to RPG code, what it costs, where the productivity figure everyone quotes comes from, and where it stops. The data is verified as of 31 August 2026 and the sources are at the end.

TL;DR

• Bob 1.0 has been generally available since 24 March 2026, with the global availability announcement on 28 April 2026. It is no longer a preview.
• Bob is an IDE derived from Visual Studio Code with agents, not a plugin. IBM describes it as a multi-model orchestration platform routing tasks across frontier models, open models and the Granite family.
• The IBM i functionality sits in a separate pack, the Premium Pack, available since 24 June 2026 at 40 dollars a month on top of the base subscription. Without that pack Bob does not read source held in QSYS.
• The pack brings a developer mode for RPG, COBOL, DDS, SQL and CL, around 40 skills (fixed-format to free-format conversion, replacing record-level database access with SQL, generating unit tests, extracting business rules) and around 30 tools acting on the system, including 5250 sessions and CL commands.
• The 45% productivity figure quoted everywhere refers to IBM internal developers, not customer IBM i installations: 6,000 IBM developers with access, roughly 3,000 using it daily, four months of use, vendor-stated.
• On an Italian RPG estate the value today sits in understanding and documenting existing code. Generation needs review by somebody who knows the platform, and there are documented cases of nonexistent command parameters being proposed as valid.

In RPG assessments handled by Obsidian Technologies the time concentrates on working out which programs are still called and by what, rather than on reading any individual source, and that is precisely the part a model-based assistant does not cover today, because it needs the execution history rather than the code.

From watsonx Code Assistant to Bob: the timeline

2025. IBM announces watsonx Code Assistant for i, built on a Granite model tuned for RPG and IBM i, shown at Think and at COMMON POWERUp. It stays in private preview.

October 2025, TechXchange. IBM converges the RPG assistant for IBM i and the COBOL assistant for System z into a single product, Project Bob. IT Jungle reports the reason plainly: watsonx Code Assistant for i was not progressing fast enough to keep pace with the wider AI market.

24 March 2026. Bob 1.0 reaches general availability.

28 April 2026. IBM announces global availability by press release.

24 June 2026. The Bob Premium Pack for IBM i arrives, which is the part that matters to anyone with an AS/400.

The timeline matters for a practical reason: most of the coverage still in circulation describes the preview phase, when the product had a different name, no public price and no access to QSYS. Anyone evaluating today on the basis of that material is evaluating a product that no longer exists.

What it actually does to RPG code

The distinction that matters is between base Bob and Bob with the IBM i pack.

Base Bob is a general-purpose agentic development environment. It reads repositories, explains code, writes code, runs commands, integrates over MCP. On RPG it works if the source sits on a PC or in Git, and for a typical IBM i estate that condition does not hold: the source sits in QSYS.

The Premium Pack removes exactly that limitation. The stated capabilities:

• Native support for source held in QSYS, without exporting it first
• IBM i developer mode, orienting the model towards platform specifics across RPG, COBOL, DDS, SQL and CL
• Around 40 skills, including converting RPG from fixed-format to free-format, replacing native database access with SQL, writing unit tests, extracting business rules from a program, compiling, generating display files
• Around 30 tools acting on the system: reading and writing QSYS and IFS, running CL commands and SQL statements, opening 5250 sessions, managing library lists
• RAG augmentation from platform-specific sources, including RPG Café and compiler knowledge

The list is concrete and should be read for what it is: these are the operations an RPG programmer performs during a working day, brought inside an environment where they are asked for in words. The step change from the preview phase is that Bob acts on the system, rather than explaining a source somebody pasted into it.

What it costs

Prices are in dollars, per user, per month, and as of the verification date they are public on the product site.

Two things need understanding before doing the arithmetic.

Bobcoins are consumption, not a flat rate. Each plan includes a monthly allocation and anyone exhausting it buys more. Intensive agentic use, which is how the product pays for itself, consumes more than occasional use, so the real cost depends on intensity and cannot be known before trying it.

The IBM i pack adds to the base plan. The minimum sensible configuration for an RPG programmer is therefore a base plan plus the 40 dollars, and the choice of plan depends on how many Bobcoins get consumed, which is the unknown.

For a team of three RPG programmers the annual cost lands on an order of magnitude of a few thousand dollars, which set against the hourly cost of somebody who can read RPG is a small figure. The thing to watch is that this spend adds to the five lines an IBM i system already carries, which we listed in what it costs to keep an AS/400 ERP running.

The 45% productivity figure: where it comes from

It appears in nearly every article about the product, and it is worth looking at closely because it gets used badly.

When IBM presented Project Bob at TechXchange in October 2025, the stated numbers were these: 6,000 IBM developers with access to the tool, roughly 3,000 using it daily and 1,500 every other day, four months of use, and a 45% productivity increase across the group.

Three clarifications change the weight of that figure.

They are IBM internal developers, not customers with an RPG estate in production. They work on IBM code, with IBM practices, inside the organisation that builds the tool.

It is vendor-stated, with no published methodology. There is no way to know how productivity was measured, across which activities, or what the baseline was.

The scope is not RPG. The example given in that presentation concerned Java upgrades and framework migrations, meaning modern work on modern code, which is the case where code assistants deliver most.

None of the three clarifications makes the number false. Together they make clear that it does not transfer to an Italian software house with 900 RPG programs written between 1998 and 2012, and that anybody quoting it in that context is using it outside its domain.

Where it stops

Platform accuracy is not solved. There are documented cases of early versions proposing command parameters that do not exist. On a system where a wrong CL command can touch production data, the operational constraint that follows is that execution has to be supervised, which reduces the gain precisely in the activities where it would be largest.

It does not know what is alive. A model reads the source it is given. Knowing which programs are still called, from which job, how often and for which flow requires the system execution history, not the code. That is the work which sizes any modernization project, and it stays assessment work.

It does not know your domain. The rules that matter in bespoke business software live in the exceptions: the client invoiced differently, the warehouse that decrements before it records. A model reads those as code, not as business decisions with a history, and automated conversion carries them forward without knowing which were mistakes and which were choices.

Free-format conversion is not modernization. Converting RPG from fixed to free-format and replacing record-level access with SQL are real improvements in readability and maintainability. They do not change the architecture, do not separate logic from the 5250 interface, and do not produce APIs. Conflating the two is the fastest way to spend a modernization budget and end up with the same system written better.

It does not replace skills. The value of the tool rises with the competence of the person using it, and on this platform that holds more than elsewhere, because somebody has to be able to recognise a wrong answer. On a team with no RPG competence, Bob does not fill the gap: it makes the gap faster to cross in the wrong direction.

What changes for an Italian AS/400

The use case with the best value-to-risk ratio today is not code generation. It is documenting what is there.

The typical estate we see has hundreds of programs, documentation frozen fifteen years ago, and one or two people who know how it works. In that situation a tool that reads a program and produces an explanation readable by somebody who does not know RPG solves a real problem, and solves it at low risk, because the output is a text somebody rereads rather than a command touching data.

The second sensible use case is extracting business rules ahead of a migration. It is the same work an assessment does by hand, and a tool that accelerates it lowers the cost of the most expensive phase of the five migration strategies.

The third, more prosaic, is generating tests on programs that never had any. On a system where fear of touching the code is the main brake, having tests to lean on changes what the team feels able to modify.

Mistakes we see at this stage

1. Evaluating on 2025 material. The product changed name, distribution model and price. Comparisons written during the preview do not describe what is on sale today.

2. Buying the base plan and discovering it does not read QSYS. The IBM i pack is a separate purchase, and it is what makes the tool useful on this platform.

3. Presenting free-format conversion as a modernization project. Two different things with two different budgets, and the first does not produce the results sold with the second.

4. Quoting the 45% in a proposal. It is an internal IBM figure on non-RPG work. Putting it in a commercial document exposes the author to the first question from an informed client.

5. Starting with generation rather than comprehension. The right order is understand what is there, then document it, then possibly change it. Inverting that is how AI-assisted projects produce new code on top of old problems nobody understood.

FAQ

Does Bob replace watsonx Code Assistant for i?

Yes. The IBM i assistant capabilities were folded into Bob in October 2025, and the earlier product is not where IBM is investing.

Does RPG code have to go to the cloud?

It depends on the chosen configuration. IBM has stated deployment flexibility across cloud, on-premise and hybrid precisely because of data governance constraints. It is the first question to put to the reseller, and it is the question that decides whether the product is usable in contexts with contractual constraints on data.

Does it work in Italian?

For code explanations yes, and the quality depends on the underlying model rather than on the tool. For generated code the language is not the relevant variable.

What does it really cost for a team of three?

Three base plans plus three IBM i packs are the floor, with Bobcoin consumption on top, which is the unpredictable part. The sensible way to find out is the free trial period against real work, rather than an estimate.

Is it worth waiting for the next version?

On a product that has changed name twice in twelve months, waiting carries a low cost and an uncertain benefit. The reason to try it now is different: the trial is free and produces a figure of your own, on your own code, worth more than any assessment written by somebody else.

Does it do the same for COBOL?

The COBOL scope is served by the IBM Z modernization pack, which has a different licensing model and is restricted to the Enterprise tier. It is not included in the IBM i pack.

The first piece of work to measure it on

Bob went from announcement to available product with a public price list in eighteen months, and it is today the most concrete tool available for working on RPG code with model assistance. That does not make it the answer to what to do about your AS/400, which stays a question of business planning.

The useful way to check it does not require a decision. It requires taking one program, among the most feared and least documented, and asking the tool to explain it during the trial period. Then having that explanation read by the person who knows that program. The distance between the two versions is the figure that matters, and it is yours rather than IBM’s.

If you have an RPG estate and want to work out which part of the assessment work can be accelerated and which cannot, let’s talk.

Further reading: IBM i 7.4 out of support from 30 September 2026 for the deadline driving decisions right now, and the legacy systems modernization pillar.

Sources: IT Jungle on the convergence into Project Bob (October 2025) for the IBM-stated figures, IT Jungle on Bob 1.0 for the general availability date, IT Jungle on the IBM i Premium Pack for the pack capabilities and date, and the official price list for pricing. Data verified on 31 August 2026: for a product that has changed name twice in twelve months, reverify before any purchase decision.