Firstly, ‘Sorry for writing so many blogs about IBM BOB‘ in recent months, but it really has been a complete game changer for me over the last year. It has turned the daily grind of staring at dusty fixed-format RPG into something almost enjoyable (honestly!). What used to take hours of head-scratching and strong tea now often takes minutes of asking a surprisingly competent AI sidekick. So here is the practical view of using it every day, warts and all.
Using AI Every Day to Wrestle Legacy RPG into Submission (Without Losing Your Mind or Your Job)
If you have spent any time staring at a 30 year old RPG III program that looks like it was written by someone who thought indicators were a personality trait, you already know the drill. This old code works! The business depends on it. And the only person who truly understands why subroutine $CALC does what it does, just handed in their notice or retired to a beach somewhere with better coffee than the office canteen. Now we’re in trouble!
Enter daily AI use. Specifically, tools like IBM BOB (the AI first development partner that lives inside a VS Code based IDE and now comes with a proper Premium Package for i). Used every day it can help you understand legacy RPG, troubleshoot faster, ship changes quicker, and capture the business knowledge that walks out the door with every experienced developer.
Here is the practical, no fluff view from the trenches.
The Upsides: Why Daily AI Use Makes Legacy RPG Feel Less Like Archaeology
Speed of understanding.
Point BOB at a fixed format RPG program and ask it to explain what the program does, which files it touches, and what the key business rules are. In minutes you get a readable summary instead of spending half a day reverse engineering indicators and GOTO statements. That alone is worth the price of admission when you inherit a program last touched in 1998.
Faster troubleshooting.
Dump a compiler listing, a job log, or a chunk of source into the Ask mode and ask why the subfile is blank or why the SQL is throwing SQLCODE 100. BOB has been trained on IBM i specifics. It spots the classic foot guns faster than most juniors (and some seniors who have been living in free format for too long).
Accelerated development and modernization.
Convert fixed format to free format, replace record level I/O with embedded SQL, generate unit test stubs, or produce the technical documentation that never got written. What used to take days of careful manual work can be reduced to a solid first draft that a human then reviews and hardens. The Premium Package for i adds native connection to the system, so BOB can read members directly from QSYS, suggest changes, and even help with compile cycles without constant copy and paste.
Knowledge preservation.
This is the quiet killer feature. Experienced developers leave. The tribal knowledge about why that particular date calculation exists, or why the order entry program has three different ways of calculating tax, leaves with them. AI that has seen the actual source can extract business rules, document them, and keep that knowledge inside the company instead of walking out the door.
The Downsides: Because Even Clever AI Still Needs a Responsible Adult in the Room
AI is still a very clever junior that occasionally hallucinates. It will confidently invent a file name that does not exist or suggest a modern construct that is not available on your release level. You still have to review everything. Blindly accepting the output is how you introduce subtle bugs that only surface at month end.
Context windows and token costs matter. Big monolithic programs still need careful chunking. And if your source is a mess of uncommented spaghetti, even the best model will struggle until you clean it up a bit.
Security and data residency are real concerns for some shops. You need to understand what leaves the building and what stays local. The enterprise version of BOB is designed with governance in mind, but you still own the risk.
Finally, it does not replace judgement. An AI can modernize the syntax. It cannot decide whether the business rule itself is still correct after twenty years of changes in the real world.
Will AI Replace IBM i Developers?
Nope – not for now anyway.
Not in any meaningful timeframe that matters to your career or your company’s risk register.
IBM i systems run the core of banks, manufacturers, distributors and hospitals. The code is full of RPG subroutines that only make sense because of decisions made in 1994. AI is outstanding at the mechanical work: explaining, converting, documenting, generating boilerplate. It is still weak at the strategic work: deciding what should be rewritten versus left alone, understanding the political and process constraints of the business, and owning the production outage when something goes wrong at 2 a.m.
What AI will do is raise the bar. Developers who refuse to use these tools will look slower and more expensive. Developers who treat BOB as a force multiplier will ship more, understand more, and become the people the business actually wants to keep. The ones who will struggle are the pure “I only write green screen RPG and refuse to learn anything new” crowd. That was already true before AI. AI just speeds the process up.
Closing the Skills Gap Before the Last Greybeard Walks Out the Door
The IBM i skills gap is real. New graduates do not queue up to learn fixed format RPG. The people who actually understand this legacy RPG codebase are retiring. This tribal knowledge is critical and it’s fading fast in todays business environments.
Tribal knowledge is the stuff that lives only inside the heads of the long-serving programmers who wrote the code back in the 1990s. It is the unspoken, unwritten understanding of why a particular RPG program does what it does, why certain indicators are set the way they are, why that weird date calculation exists, or why the order-entry program has three different tax routines depending on the customer type. None of it is in the comments. None of it is in any design document (those went missing years ago). It only exists because Dave, or Sue, or the bloke who retired last year, still remembers the business reasons from when the system was first built. When those people leave, the tribal knowledge leaves with them. The code still runs, but the next person looking at it is left guessing. That is exactly the problem AI tools like IBM BOB are starting to help with: extracting and documenting that hidden knowledge before the last of the original programmers walk out the door.
Me, trying to make sense of some Sys36 Accounting Code
AI changes the onboarding curve. A new developer can ask BOB to explain a complex order entry program in plain English, generate the documentation, and walk through the call stack. What used to take six months of pairing with a senior can be compressed dramatically. At the same time the seniors can use the same tool to extract the knowledge that lives only in their heads and turn it into living documentation and tests before they leave.
That is not theory. Shops already using the Premium Package for i are reporting faster onboarding and fewer “only Dave knows how this works” single points of failure.
What IBM BOB Actually Means for Your IBM i Software Department (Spoiler: Less Panic)
BOB is not another generic coding assistant that has vaguely heard of RPG. With the Premium Package for i it becomes an IBM i native partner. It understands OPM and ILE, DDS and SQL, CL and the quirks of the platform. It can work directly against your libraries. It has specialized modes and skills for the exact tasks we do every day: fixed to free conversion, business rule extraction, documentation generation, unit test scaffolding, and modernization planning.
For departments this means less time lost to archaeology and more time spent on actual improvement. It also means the institutional knowledge stops walking out the door quite so easily.
Real Use Cases: BOB versus the Old-Fashioned “Stare at the Code Until It Makes Sense” Method
Understanding legacy code.
Manually: open the source, start at the top, follow the indicators, draw a flowchart on paper. Hours.
BOB: “Explain this program, list the files, and extract the key business rules.” Minutes for a solid first pass, then you refine.
Troubleshooting.
Manually: dig through job logs, DSPJOB, put in temporary debug code.
BOB: feed it the relevant source and the error. It often spots the classic “I forgot the USROPN” or the indicator that never got turned off faster than you can say “why is *IN90 on?”
Documentation.
Manually: the documentation that never gets written.
BOB: generate structured comments, program level documentation, and even simple process descriptions directly from the source. You still edit it, but you are no longer starting from a blank page.
Modernization.
Manually: carefully convert fixed format to free, replace CHAIN/READ with SQL, introduce procedures, add error handling. Slow, error prone, and soul destroying when you have hundreds of programs.
BOB: convert a program (or a set of related programs) to modern free format RPGLE with proper control options, named constants, and structured error handling. You review, adjust the edge cases, compile, and move on. The difference in speed is not subtle.
In my side-by-side tests BOB has consistently produced cleaner, more IBM-i aware first drafts than generic AI tools I’ve used; Claude, Copilot, Kimi, Chatgpt. BOB shows its IBM-i coding skills even more once you move into SQLRPGLE, DDS interactions, and real PF-SQL modernization patterns.
Coming Soon: BOB in Action – Real Code, Real Messes, Real Fixes
I’m busy working on some old RPG36 code at the moment; it’s given me an idea to put together a new video series called BOB in Action. Real programs. Real problems. Real before and after. We will walk through understanding dusty RPG, fixing bugs, generating documentation, converting fixed format, and modernizing step by step while the camera is rolling. No polished marketing demos. Just the actual work of an IBM i developer using the tool every day.
If you are already using BOB, or if you are still deciding whether it belongs in your toolkit, the series should give you a clear picture of where it helps and where you still need to keep your brain engaged.
The bottom line is simple. AI will not replace IBM i developers. Developers who use AI well will replace the ones who do not. And the shops that capture their institutional knowledge before the last of the grey beards retire will be the ones still running clean, maintainable systems in ten years time.
Right. Time for another strong cup of tea and another session with BOB.
