Chapter 01 was about where Bob runs. This one is about what it does once it gets there. The short answer is "modernize your RPG." The useful answer is more specific: Bob does its best work where its output can be checked, and the shops getting the most from it set it up that way from day one.
The first release of Bob worked from source pulled down to a PC. For a community whose code lives in QSYS, a direct connection was the most requested change, and IT Jungle covered that feedback closely.1
What changed in JuneBob reaches the box now.
On June 24, IBM shipped the Bob Premium Package for i, an add-on to a paid Bob plan.2 It connects to your system through Code for IBM i and changes what Bob can see:
- It reads source where it lives. Members in QSYS and files in the IFS, directly, with no export step. That's the change the community asked for.
- It reads your database's structure. Tables, constraints, foreign keys and relationships, straight from the Db2 catalog. From that it can draw the entity-relationship picture most shops have only ever carried in someone's head.
- It brings platform knowledge it wasn't trained on. A curated documentation library reaching back to the System/36 era. IBM's Tim Rowe used the RPG cycle as the example: in his words,
something completely different that nobody understands.
3
On top of that sit two IBM i modes (a Developer mode for RPG, CL, DDS, COBOL and SQL, and a Database mode for Db2 for i), around thirty platform tools for things like CL commands, SQL and 5250 sessions, and a library of task skills.4 Coverage at launch put the skills near forty; IBM's documentation now lists more than sixty, twenty-one of them for RPG alone.5
What it's good atFour jobs, done as solid first drafts.
Explaining what a program does.
Summarize a program, the files it touches, and the business rules buried in it. This is the fastest win, and the one that matters most for the shrinking pool of people who still know the old code.
Modernizing syntax.
Fixed-format to free-format RPG, OPM to ILE, and record-level access to embedded SQL each have a dedicated skill. Practitioners describe the results as a good first draft in place of days of manual work.7
Writing the documentation nobody wrote.
Design documents and diagrams generated from the code and the catalog. Not glamorous, but it's knowledge you get to keep after the people who carried it retire.
Scaffolding tests.
RPGUnit test suites, set up and named properly. Bob can chain this with a conversion: convert the program, generate tests against it, document the result, in one session.2
Jack Henry, one of the named early customers, says its developers are moving faster on RPG work and getting more out of decades of accumulated system knowledge.4 That's a credible claim, and it lines up with the four jobs above.
Working with itWhere a person stays in the loop.
Like any AI assistant, Bob works best with someone who knows the system alongside it. IBM's own guidance is to use it safely and responsibly on IBM i,6 and experienced practitioners put it simply: treat its output as a strong first draft and review it before it ships.7 In practice that comes down to four habits.
Confirm facts about your system.
Language models can state something about your environment with confidence: a product option, an SQL service, an object name. Have Bob look it up on the system or in the documentation rather than recall it, and confirm anything you'll build on.
State the platform's rules up front.
Ten-character object and member names, your CCSID and EBCDIC handling, your release level, your naming standards. Saying them once at the start keeps every answer inside your shop's lines.
Scope tasks the way you'd scope them for a new hire.
Short, specific tasks with a clear finish line go best. Larger efforts, like modernizing a whole menu system, work better broken into steps you can check one at a time.
Business judgment stays with your people.
Bob can explain a twenty-year-old pricing rule clearly. Whether that rule should still exist is a business decision. And large monoliths are easier for anyone, person or agent, to work through in pieces.
The ruleTrust what the box can check. Verify what only the box knows.
Put the strengths and the failures side by side and one line separates them. Bob is strong where its output can be checked by the platform: a compile either succeeds or it doesn't, an RPGUnit test passes or fails, a catalog read is a fact. It needs a second look where it has to assert something about your system from memory instead of looking it up.
It's the same rule you'd give a talented developer in their first week: check the work you can check, and don't take their word for anything about the system they haven't seen yet. The difference is that IBM i gives you unusually good judges. The compiler, RPGUnit, the catalog and the journal are all objective, and all already on the box.
Let it run. Let the box judge.
What to do MondayFour moves for a first real trial.
Start where you can grade it.
Pick a program your best developer knows cold and ask Bob to explain it. You'll learn more about Bob in that hour than from any demo, because you'll know exactly where it's right.
Make the platform the judge.
No conversion merges without a clean compile and passing RPGUnit tests. That turns Bob's best skills into ones you can verify, not ones you have to trust.
Teach the mode your house rules.
Both IBM i modes can be customized. Put the ten-character limit, your release level, CCSID, naming standards and "look it up before you claim it" into the mode once, instead of reminding Bob every session.8
Keep tasks short and specific.
"Convert this program and test it" goes well. "Modernize this menu system" works better as a series of steps. Scope like you would for a new hire.
And everything from Chapter 01 still applies: Bob acts with exactly the authority of the profile you connect it with. A narrow profile keeps every task inside the lines you drew.
Before Bob touches your RPG: how ready is the estate it's walking into?
Take the IBM i readiness read