Putting IBM Bob to Work on Real IBM i Code

AI-assisted development has generated plenty of headlines, but IBM i developers tend to ask a more practical question: can it actually understand RPG, source members and decades of business logic?

John Long, Senior Software Development Manager at TJ Morris, has been using IBM Bob and Premium Package for i on real IBM i code. Here, he shares what works, what still needs attention and why a healthy amount of scepticism remains useful.

Setup

What does your development setup look like and how did you configure Bob and the IBM i package?

I run the Bob IDE on an Ubuntu laptop. As Bob is based on VS Code, the environment felt familiar. I started with the trial, moved to the standard edition and recently upgraded to Premium Package for i, or PPI.

Installation was straightforward. I downloaded the .deb package and installed it from the command line. Code for IBM i provides the connection to our development system.

We still use a green-screen change-management system. It checks source out into a dedicated development library, and I use Bob to work with that source. This means Bob complements our existing controls rather than replacing them.

Before PPI, I downloaded the source to a local workspace so /init could scan it. Changes then had to be copied back into the source member before I compiled through the green screen. It worked, but it was a little clumsy.

PPI removed most of that friction. Bob can now work directly with the IBM i source and compile it from the IDE. I configure the library list to match the development environment created by our change-management system, while promotion and deployment remain firmly under the existing process.

Source Management

How does Bob work with your source?

Our code is held in traditional source physical files and members rather than Git. The change-management system creates a development library and copies the relevant members into it.

PPI uses SSH to access those members directly. It can also examine copy members, file definitions and related objects, giving it much better context than the earlier local-workspace approach.

Changes are automatically saved to the IBM i source member. I initially extended the autosave delay, which meant the IBM i version could lag behind what I saw in the editor. Returning autosave to its default setting resolved that. The experience highlighted the importance of keeping the IDE and IBM i source closely synchronised.

I am also experimenting with storing plans in the IFS. Once development and testing are complete, I still use the green-screen system to promote and deploy the change.

First Move

What is the first thing you ask Bob to do with an unfamiliar program?

It depends on the program. If I already know it, I normally start with a business question or an outline of the change. If it is unfamiliar, I ask Bob to explain its function and highlight weak code, poor practices and possible performance issues.

A typical prompt is:

Review the code in @xxxxxx, explain its function, and highlight any potential issues, poor practices or performance concerns.

I then ask more focused questions about inputs, outputs, files and dependencies as needed. I often have several members open and use the outline view and Ctrl+click to move between definitions while checking Bob’s explanation against the source.

Before planning a change, I use the grill-me skill. It interviews me one question at a time, then uses each answer to decide what to ask next. This exposes vague requirements, assumptions, edge cases and gaps in error handling before any code is changed. This structured challenge is particularly useful because it strengthens the requirement before Bob creates a plan, reducing the chance of gaps being discovered during implementation.

Bob has already found a genuine bug where an uncommon path could leave a variable in an unpredictable state. It has also helped untangle and simplify some particularly awkward logic.

RPG & Beyond

How good is Bob with RPG, CL, DDS and embedded SQL?

Our code ranges from fixed-format RPG to fully free-format code. Some older programs exceed 10,000 lines and contain a great deal of monolithic business logic. Bob appears equally capable of explaining existing RPG and generating or modifying it.

Occasionally, generated code does not compile. With PPI, Bob can inspect the compiler output, correct the source and try again. I would still prefer not to spend additional Bobcoins while it works out why its own code failed, but the workflow itself is effective.

Bob has also converted fixed-format RPG to fully free format successfully. My custom rules define coding style and standards, and I refine them whenever Bob drifts from my preferred approach. It has adapted well enough that its code can be difficult to distinguish from mine. In some cases, the clearest difference is that Bob tends to include more detailed comments.

I have not used it enough with CL to offer a fair assessment. It has reviewed and created display files, understood existing physical and logical files, and worked well with SQL tables. Its embedded SQL has also been good, including cursor handling, immediate execution and error handling.

IBM i Awareness

Does Bob understand IBM i objects, libraries and dependencies?

With PPI, Bob has a good understanding of IBM i objects. It can use commands such as DSPPGM and DSPSRVPGM, inspect objects in the library list and follow related files, copy members, programs and service programs.

Occasionally, it starts looking outside the most relevant area. I watch what it is doing and redirect it to the correct library or member. This keeps the investigation focused and avoids unnecessary use of time and Bobcoins.

It has handled our externally described files, SQL tables and layered dependencies well, despite the codebase having accumulated more than 25 years of changes. I have not yet tested it extensively where batch-job behaviour is central, so I would not claim that every aspect of runtime behaviour has been proven.

My rules tell Bob that I am an experienced RPG developer who prefers concise, practical answers without jargon or beginner tutorials. They also ask it to flag indicators, file I/O side effects, global state and hidden dependencies, and to seek clarification rather than make assumptions.

Prompting

Which prompting habits work best?

I prefer several small, focused prompts to one enormous instruction. Each answer can lead to another question, which helps me refine the requirement and gives Bob a clearer path to follow.

For most substantial changes, I use grill-me before asking for a plan. Grill-me challenges the proposed change through a structured conversation. Once the gaps and assumptions have been addressed, Bob can create a more focused implementation plan for me to review before it changes any source.

I normally start with the IBM i library-list option and use @ references to identify relevant members, although probably not as often as I should. I also watch where Bob searches. If it heads somewhere irrelevant, I interrupt and point it in the right direction.

I start a new conversation for each task where practical, but some work needs knowledge developed during previous interactions. This is a wider challenge with AI tools: retaining the context that still matters without allowing unrelated history to affect a new task.

My main prompting lesson is simple: be concise, but do not be vague. State the outcome clearly and ask Bob to verify anything that would otherwise require an assumption.

Quality & Testing

How reliable is the generated code, and how do you validate it?

Most generated code compiles successfully on the first attempt. One issue I have seen is the wrong field type being selected. In fairness, our older source can define the same conceptual value as packed decimal in one place, character in another and integer somewhere else. Even an experienced developer would need to examine the surrounding context carefully before selecting the correct definition.

I review everything Bob changes. That is not an indictment of the tool. I have always checked and double-checked my work. I scan the diff to confirm that the changes are sensible and limited to the expected areas.

Testing is currently manual. I create test cases, run the initial functional checks and then use debug to follow decision points and force the program through less common paths. I have not yet asked Bob to generate test cases or boundary conditions, but I plan to explore that during the formal testing phase of my current project.

The depth of review increases with business risk, although experience has taught me that even a small, apparently low-risk change can have significant consequences.

Legacy Code

How well does Bob modernise a large legacy program?

I am modernising a product-maintenance program that has evolved over more than 25 years and contains about 11,500 lines of code. It handles roughly five screens and includes a large mainline, numerous subroutines, extensive indicator use and globally scoped variables whose purpose is not always clear.

I am replacing it in stages, with a separate program for each screen and reusable business logic and validation held in RPG service programs. The design uses dedicated accessor, update and validation procedures based on the getter and setter idea.

A sanitised version of my prompt is:

Compare the original program at @ORIGINAL_PRODUCT_PROGRAM with the replacement at @NEW_SCREEN_PROGRAM. Create a plan to ensure that all existing business functionality is retained. Highlight logic errors and potential problems, remove redundant code and comments, and simplify complex logic where possible. Business logic and validation should be implemented as reusable procedures in the appropriate service programs, following the defined coding and style rules.

For later screens, I also supplied the relevant subroutines and line-number ranges. Bob examined the old program, related files, calls and my new service-program structure. It then produced a plan covering the screen program, new procedures, copy members and binder source.

The modernisation is deliberately phased rather than a large rewrite. I run the old and new versions side by side, compare validation and updates, and examine file changes and journal activity from both versions.

The result so far is more readable and maintainable code, with some performance improvements. It has also improved my understanding of business logic that had become buried under years of change.

Trust & boundaries

What are your boundaries for AI-assisted changes?

Bob has been instructed to treat our production source and libraries used by other developers as read-only. It can inspect them when necessary, but it should not modify them.

I do not allow Bob to alter production objects or data, interfere with production, or deploy code. I also prefer not to publish details of our IBM i profiles and authorities. Those arrangements are deliberately kept internal.

For significant work, I review the plan before implementation. I then give Bob one defined task at a time, although that task may require coordinated changes across several members.

I monitor what Bob does and review the completed changes myself. AI-generated code goes through the same compilation, testing, review, promotion and deployment controls as developer-written code. Confidential data, credentials and production data are excluded from the context I provide.

My basic rule is that Bob can investigate, propose and implement, but the developer remains accountable.

Advice & Wishlist

What would you improve and what would you tell a sceptical RPG developer?

When Bob needs to identify a source member, I would like it to ask whether there is a specific member I want it to review, rather than relying on me to remember to use the @ reference or automatically searching for one.

As a minor gripe, I would also prefer clearer, more informative progress messages in place of some of the quirkier ones, so it’s easier to understand what Bob is actually doing.

Bobcoin consumption remains a concern. I sometimes restrict context or interrupt a wider investigation because I am watching the meter. A rough cost estimate before starting a task would help, as would advice on reducing context size and making prompts more efficient. My preference would be unlimited use under reasonable fair-use terms.

I would also like better storage and management of plans and analysis. A central repository linked to the relevant code would let other developers reuse previous work rather than repeat the investigation. Bob could also use the configured IBM i release to suggest suitable newer RPG or operating-system features.

One immediate benefit is the generation of standard, repeatable code. A subfile maintenance program is not especially difficult, but writing one involves plenty of routine work. Letting Bob build that foundation leaves more time for business logic, validation and the genuinely interesting problems.

My advice to a sceptical developer is to start small. Ask Bob to create a straightforward subfile program, then check its validation, errors and file updates. Refine the rules until it follows your standards. Next, ask it to explain a complex program you already understand and compare its analysis with your own knowledge.

Initially, be cautious and check everything. Confidence should come from evidence, testing and repeated use, not from assuming AI must be right.

Bob is most valuable when you question it, review its work and treat it as a development partner rather than an infallible authority. Teach it how you work, give it the right context and correct it when it is wrong. The best results come when Bob is treated as a capable development partner that still needs clear direction, appropriate context and careful review.

PowerWire Conclusion

AI assistance on IBM i is no longer an abstract promise — it’s becoming a practical tool that developers can put to work on real code, real members and real business logic. What John Long’s experience shows most clearly is that value doesn’t come from treating Bob as a magic box, but from treating it as a disciplined development partner: one that can analyse legacy logic, generate modern RPG, challenge assumptions and accelerate routine work, while still relying on the developer’s judgement, standards and review.

The message for the IBM i community is straightforward. AI won’t replace decades of knowledge, nor will it remove the need for careful testing, structured change control or sceptical thinking. But used well — with clear prompts, defined boundaries and a willingness to question its output — it can reduce friction, expose hidden issues and free developers to focus on the parts of the job that genuinely require human insight.

Bob is still evolving, and there is plenty of room for refinement, from cost transparency to richer plan management. Yet even today, its ability to understand RPG, navigate IBM i objects and support staged modernisation makes it a meaningful addition to the toolbox.

For developers wondering whether AI has anything real to offer on IBM i, John’s experience provides a grounded answer: start small, stay in control, and let evidence guide your confidence. The potential is there — and it’s already proving itself in day‑to‑day work.

PowerWire would like to thank John for his time and expertise in composing this article.

A future IBM Champion? Maybe!