Guru: A Modernization Experiment Using IBM Bob 2.0
October 5, 2026 Dan Darnell and Eric Whitcomb
The most common use case for business applications is the CRUD model. The Create, Read, Update, and Delete operations, performed against a business database, are found almost everywhere. Behind every fancy inquiry dashboard with all the graphical bling you can muster are a slew of tried and true so-called “maintenance programs” doing the heavy lifting over the data being presented. Whether it is back-office parameter tables, customer maintenance, or order entry applications, the CRUD model is fundamental. Most of us can whip out a simple green-screen maintenance program with our eyes closed in, oh, a couple hours or so, depending on what we have to draw on for getting started.
When Bob 2.0 came on the scene with IBM i features (i.e., “Premium Package for i”) we wondered how good Bob would be at generating a maintenance program and set about to do just that. Our requirements for Bob seemed reasonable to us:
- Start with database generation. Create a Customer table in a schema.
- Generated CRUD functions over the table in ILE RPG, suitable for use in the Integrated Web Services (IWS) 3.0 server.
- Make a front end out of JavaScript and Bootstrap utilizing the back end IWS services.
What this target gave us was something that felt like a real-world modernization effort. Far more than just an upgrade of existing code from an older RPG standard to a newer RPG standard. We wanted to put Bob to a real IBM i modernization test. The goal in modernization, we feel, is a modern UI on the front end with the latest standards on the back end, all running on the IBM i platform!
On Bob And Free-Format Conversions
We are of the opinion that Bob is not the best tool at this point for turning RPG III programs into RPG IV programs or RPG IV programs into free-format ILE RPG programs. It mostly comes down to cost. Bob charges for usage based on an abstraction they call Bobcoin. The monthly subscription for Bob, plus the IBM i tools in the Pro+ tier, will run you $100/month for 160 Bobcoin.
A full-fledged, day in, day out modernization effort to make free format ILE RPG out of RPG IV under the current model burns that Bobcoin incredibly quickly. We feel that the current model of 160 Bobcoin at the Pro+ tier is wildly insufficient for large-scale syntax upgrades. The “burn rate” is simply too fast.
There are cheaper alternatives out there for doing this kind of modernization work. Many great tools already exist that take older RPG code and turn it into free-format ILE RPG. You don’t need an AI to make a free-format ILE RPG program and with the concerns about cost – and even concerns about the consistency of AI – we suggest you consider a purpose-built tool for this kind of work.
We weighed several options including hosting services with Node.js or Python. These could run natively on the IBM i but are still out of the wheelhouse of many people on the platform. The latest IWS 3.0 server seemed to fit the bill as a service tier running natively and within the technical grasp of almost everyone. Similarly, free-format RPG as an implementation language for services felt right. However, the green-screen definitely had to go away in favor of a modern browser-based user interface.
To make the effort reasonable for others to follow we did not put a lot of agentic guardrails and other assets into place. We used Bob as more of an application generation tool without providing specific guidance for look and feel. Nor did we ask for a lot of context retention for follow-up efforts. For the purposes of this article we felt that simple was better.
We used a straightforward prompt to get Bob started:
Create a database table on IBM i for a Customer table with columns for UniqueID, CustomerName, and CustomerAddress. Create a CRUD application for the Customer table using ILE RPG to implement IWS services. Include PCML in generated RPG programs. Create a user interface using JavaScript and Bootstrap with full maintenance capabilities. Use library CUSTLIB to hold database table and source members.
Bob did not disappoint. Given this very scant direction, Bob created all of the resources needed for a modern maintenance application (see Figure 1 and Figure 2).
Figure 1. Maintenance Display
Figure 2. Delete Confirmation Action
Bob understood the reference to IWS services and created free-format RPG programs needed for configuration as endpoints. Program Call Markup Language (PCML) is used by the IWS wizard, hence our instruction to create PCML and embed it in the RPG programs. IWS exposes service endpoints when given individual RPG programs, one endpoint per program, or when given a service program, one endpoint per exported procedure. We chose to use individual programs and Bob used a nice design pattern with a service program encapsulating the embedded SQL and then small helper programs acting as the service endpoints.
Bob is very good at structuring and executing multi-step processes. Here was the initial “to-do” task list given to us by Bob as it started to the effort:
Along the way we were prompted to grant permissions for various tasks and informed as to the work being performed. As programs were generated they popped up in tabs. We haven’t seen this kind of a structured workflow in other AI coding tools. Some are decent at noting progress but none of them, in our experience, take the big-picture project view that Bob does in addition to tracking and reporting all the details.
We offered no guidance to speak of on UI design, not even a style sheet, yet we were pleased to find a very workable maintenance program, which we hosted in an HTTP server on the same IBM i running the IWS services. We’ve been working on modernization for a long time using many different tools. Seeing the browser-based UI working and with minimal input from us elicited a “wow” from both of us and we’re all about the “wow factor.”
While Bob got it right with minimal guidance we wondered what it would take to get a better service implementation out of the tool. Specifically, we wanted a service program to encapsulate the service endpoints for easier deployment in IWS. We gave Bob a URL with an article on REST-based IWS services: https://developer.ibm.com/tutorials/i-rest-web-services-server3/
Bob read the article and, with the context it provided, Bob churned out a variation of the project that was suitable for use in IWS with a single service program. Deployed IWS services, including the consolidated service program endpoint named “customers,” can be seen in Figure 3.
Figure 3. Integrated Web Services Deployed Services
Bob summarized the reasons that one service program with multiple procedure endpoints was better than individual RPG programs as endpoints. All of this was another “wow” moment for us and proved that Bob is a tool with seriously impressive capabilities.
So far we have talked about our success with Bob. What did not work out so well? First, to beat a dead horse, the cost. We “burned” 18 Bobcoin out of our allotment of 160 Bobcoin per month on this one maintenance program. One of the strangest things that happened was a misplaced “**FREE” statement in the generated source code. When the compile failed, Bob detected and corrected the error but it was an odd thing to get wrong. There was one unfortunate point where Bob couldn’t decide on the best way to access the IBM i and a sort of odd loop resulted. We were ultimately able to stop the whole process and start over but it did prompt us to ask: Why does Bob charge Bobcoin even for failed operations?
Bob seemed to struggle a bit to process the type of JSON data returned by IWS. Through debugging with browser tools we recognized that the JSON returned by IWS was not in the form of JSON objects and arrays but rather a wrapped version of JSON that needed further parsing for compatibility with the user interface logic. We could have asked Bob to fix this but the mis-match was so esoteric that we feared Bob would burn more coin than we had available while attempting a fix. We made the one-line JavaScript code change by hand.
Bob made some other interesting choices, such as hardcoding the schema on the database operations instead of letting the system find the files via the library list. This was easy to find and fix for us as RPG developers but indicative, to us, that Bob needs more direction up front or needs some additional savvy about the platform so that it can ask more questions along the way.
Right now, for us, Bob 2.0 with the Premium Package for i is approaching knock-your-socks-off impressive in scope and quality. The financial model has to be fixed so that a developer can work with Bob like any other development tool without fear of running out of Bobcoin. At our present rate of usage we have about 10 working days per month with Bob before the Bobcoin is gone. Consistency is still a little hit and miss, even when given the same prompts, but this should be remedied as Bob is given more built-in skills and those skills are refined. We would love to see the modernized maintenance program model given serious attention, perhaps with a purpose-built “skill” (a resource that Bob can use to consistently perform a task). When Bob can churn out a CRUD, without any required tweaks to the JavaScript we’ll be ready to crown Bob the “King of Modernization.” Meanwhile, keep pushing Bob for real modernization capabilities, beyond RPG syntax upgrades, and so will we!
Dan Darnell is a co-owner and vice president at Arkansas Data Services. Dan loves to write code, talk about code, design things, and, most of all, to work with other people to solve problems and create solutions. Dan has worked successfully as a consultant, managed companies large and small, and has written for international publications (including two books on Java for the IBM i). You can reach Dan at ddarnell@ark-data-services.com.
Eric Whitcomb is a freelance author, software developer, and thinker. Eric loves to dissect problems in realms across disciplines and dimensions. He excels at taking these thought experiments and turning them into real-world applications, wherein the application might be everything from software to a screenplay. Eric has extensive experience with all-things-AI. If you Grok, Claude, Gemini, ChatGPT, or slide into the Wild West of open source AI, Eric has been there too. You can reach Eric at eric@rootmedium.com.
RELATED STORIES
Guru: Deterministic Application Development With AI
