What happens when the last RPG developer leaves

Here is the uncomfortable part about losing your last RPG developer: nothing breaks. The order entry program runs Monday morning exactly like it ran Friday afternoon. Month-end closes. The EDI feeds go out. IBM i is one of the most stable platforms ever built, and well-written RPG can run untouched for decades. That stability is precisely what makes the situation dangerous, because it hides the loss until the moment you most need the person who is already gone.

This is not the same problem as the platform aging out. IBM publishes a roadmap for IBM i that currently runs to 2035. The hardware is fine. The operating system is fine. The risk is human. Skills shortage is now the number one concern for IBM i shops at 69 percent in Fortra’s 2026 IBM i Marketplace Survey, up from 60 percent a year earlier, and it finally pushed cybersecurity out of the top spot after nine straight years. That ranking shift does not mean the security risk shrank, it means staffing got worse faster. Our breakdown of what AI has changed about IBM i security covers why the old assumptions do not hold anymore either. Fortra’s survey data consistently puts the average IBM i developer in their mid-to-late fifties. So the question is not whether your programs will keep running. They will. The question is what you can still do to them once the person who understood them walks out.

The programs keep running, which is the trap

A compiled RPG program does not care that its author retired. It executes the same logic forever. For maintenance work that never needs to change, this is genuinely great. The problem is that businesses change constantly even when their software does not. A tax authority adjusts a rate. A trading partner updates an EDI specification. Finance wants a new field on an invoice. Now someone has to open a 4,000-line fixed-format program written in 1998 and change it without breaking the seven other programs that call it.

If that someone exists and understands the code, this is a Tuesday. If they do not, you have a crisis that arrived quietly, weeks or months after the developer left, with no warning and usually under a deadline.

Where the first crack actually shows

The failures are predictable. They cluster around the events that force a code change:

A regulatory or rate change. State tax tables, withholding rules, interchange fees. The number is hardcoded somewhere, and finding it means understanding the program flow.

A trading partner change. A customer migrates EDI standards or a bank changes a file format, and the inbound job starts rejecting records for reasons that are not in any error log.

A month-end or year-end abend. A job that has run clean for fifteen years aborts because a field finally overflowed or a date rolled past a boundary nobody coded for.

An infrastructure move. You upgrade hardware, change a library list, or move to the cloud, and a dependency that was always implicitly satisfied is suddenly not.

None of these are exotic. Every one of them is routine work for a developer who knows the system, and a multi-week archaeology project for anyone who does not.

Why “just read the code” does not work

Yes, this problem exists when any developer leaves any codebase. What makes IBM i different is the combination of factors that hit at once. Fixed-format RPG is substantially harder to read cold than Java or Python. Column position carries meaning, and dense 1990s code written for a specific shop reads like a dialect even to experienced RPG developers. The replacement hiring pool is a fraction of the size of mainstream languages. The codebases are typically 20 to 30 years old with no Git history, no pull requests, and change management systems that historically enforced process but not documentation. The problem is the same. The recovery options are narrower.

The standard reassurance is that the code is right there, so a competent developer can read it and figure it out. Sometimes. But IBM i estates fight back in specific ways.

Much of the code is fixed-format RPG, where column position carries meaning and the logic is dense and terse. It was readable to the person who wrote it and is opaque to almost everyone else. On top of that you have thirty years of layered patches, each one a small change made under pressure, none of them documented, all of them now load-bearing.

Then there are the magic numbers. A field gets multiplied by 1.0825 and nothing tells you that this is a sales tax rate, that it is specific to one state, and that it is supposed to change when the legislature changes it. The code is correct. The meaning is invisible.

Worst of all are the undocumented call chains. RPG applications grow into dense webs of programs calling programs, and the map of those relationships usually lives only in one person’s memory. Large IBM i estates routinely turn up dozens of hidden program dependencies during modernization projects, connections that were causing real failures in production that nobody could trace because the call chain existed only in one developer’s head.

What you actually lose: code versus intent

This is the distinction that matters, and most “legacy crisis” articles skate past it. You do not lose the code. The code is sitting in QGPL or your source library, fully intact. What you lose is intent: the reason behind each decision.

Code tells you the system charges a 2 percent fee on a certain transaction type. Intent tells you that fee exists because of a contract signed in 2009 with one specific customer, that it is supposed to expire when that contract renews, and that the renewal already happened so the fee is now a bug nobody noticed. The code is honest about what it does. It says nothing about whether that is still what you want.

Multiply that by every business rule encoded across a few hundred programs, and you start to see the real exposure. Rebuilding the code is an engineering problem. Recovering the intent is an interview, and your interviewee is leaving.

What AI can recover, and what it cannot

The honest answer in 2026 is that AI helps more than it used to, and less than the marketing claims. IBM Bob, IBM’s VS Code-based assistant for IBM i, reached general availability in March and handles RPG II, III, IV, and ILE plus COBOL, CL, DDS, and SQL. Its application mapping can trace dependencies, data flows, and call chains across a whole estate in hours rather than months. IBM’s Bob Premium Package for i, announced in May and shipping June 24, adds around 40 IBM i-specific skills. These tools are real and worth using. They will rebuild the call-chain map that used to live in one person’s memory, and that alone is enormous.

What AI cannot do is recover intent that was never written down anywhere. It can read the 1.0825 and tell you it is a multiplier applied to a subtotal. It cannot know that it is a state tax rate, that it is wrong for three months of the year because of a quirk in how the state handles a holiday, and that the previous developer had a manual workaround for it. That knowledge does not exist in the code. AI cannot extract what is not there. It can structure and accelerate the recovery, but the source of truth is still a human who has to say it out loud.

For a sense of where these tools currently land, our rundown of AI tools for IBM i developers covers Bob, watsonx, and the rest, and our guide to documenting RPG IV code with AI walks through the practical workflow.

If your RPG developer is still here, do this now

The single highest-value thing you can do is capture the undocumented business rules while their author can still explain them. Not the syntax, the rules. Sit down with them and work program by program through the questions only they can answer: which numbers are legal requirements versus internal policy, which customers have special handling, which jobs must run in a specific order, and which programs everyone is afraid to touch and why.

AI makes this faster than it used to be. You can record the sessions, have a model transcribe and structure them, then run the actual code through a documentation tool and reconcile the two. The veteran corrects what the tool gets wrong, and you end up with documentation that captures both what the code does and why. Our IBM i AI Field Guide packages the prompts and the workflow for exactly this kind of knowledge capture, built for RPG and CL rather than generic code.

This is the same first move we argue for in our IBM i retirement wave plan. Capture the knowledge before you modernize anything, because modernization built on guesses just relocates the problem.

If the RPG developer is already gone

You have lost the cheap option, not all of them. Triage in this order. First, run an AI mapping pass over the estate to rebuild the dependency and call-chain picture, so at least you know what touches what. Second, prioritize by business risk: the programs tied to revenue, compliance, and customer commitments get documented first. Third, find a contract IBM i developer to validate the AI output, because the tools will be confidently wrong in places and you need a human who knows the platform to catch it. Expect to pay for it. Experienced RPG developers are scarce, and scarce skills are expensive. That cost is the bill for the documentation that never got written.

If modernization is on the table, do the knowledge recovery first regardless. Our guide to IBM i modernization with AI gets into the options, but the sequence never changes: understand the system before you change it.

Frequently asked questions

What happens to IBM i programs when the RPG developer leaves?

Nothing, at first. The programs keep running exactly as before, because RPG and IBM i are stable. The damage shows up later, when a business rule needs to change and nobody understands the code well enough to change it safely. The risk is not a crash on day one. It is the slow loss of anyone who can modify the system.

Can AI document RPG code after the developer is gone?

Partly. Tools like IBM Bob can explain what RPG code does, map call chains, and trace data flows across an estate in hours. What they cannot recover is intent, the reason a rule exists. AI can tell you a field is set to 0.0825, but not that it is a state tax rate that changes by legislation.

How long do we have before the IBM i knowledge is gone?

Most organizations expect their most knowledgeable IBM i staff to retire within five to ten years, and the average RPG developer is already in their mid-to-late fifties. The practical window to capture what they know is now, while they are still employed and can explain the code in their own words.

What should we do first if the developer is still here?

Capture the undocumented business rules, not the syntax. Sit with them and record why the code does what it does: which rules are legal requirements, which are customer-specific hacks, and which call chains nobody dares touch. AI tools can transcribe and structure that, but the knowledge has to come out of their head first.

Bottom line

The last RPG developer leaving is not a fire. It is a slow leak you do not notice until you reach for something that is no longer there. The programs run fine, which is exactly why companies wait too long to act. If your veteran is still on staff, the move is obvious and urgent: capture the intent behind the code now, using AI to go faster, while the person who knows it can still tell you. If they are already gone, rebuild the map with tooling, prioritize by business risk, and pay for a human to check the work. Either way, the goal is the same. Get the knowledge out of one person’s head and into something the next person can read.