Every IBM i organization knows the headcount is shrinking. The average RPG developer is in their mid-to-late fifties. Retirements are accelerating. Hiring to backfill is difficult in the best of circumstances, and the pipeline of developers entering the field with IBM i expertise slow growing.
Most technology leaders are aware of this. What many haven’t fully reckoned with is what leaves when a veteran IBM i developer walks out the door, and how little time remains to do something about it.
This is not a future problem. It is an active one. And it requires a different response than most organizations are currently making.
What Actually Walks Out the Door
The headline risk of IBM i developer retirement is headcount. You lose someone, you have fewer hands to do the work. That’s real, but it understates the problem significantly.
What actually leaves with a veteran RPG developer is knowledge that was never written down. The pricing module that one person built in 1997 and has maintained ever since, who understands why it works the way it does and which three things you absolutely cannot touch. The batch job that runs every night without incident because the developer who wrote it also documented every edge case in their head rather than in code. The undocumented dependencies between programs that every new developer eventually discovers the hard way.
The financial consequences of letting this happen are substantial. Organizations lose at least $31.5 billion annually through failure to share knowledge effectively, and employees already waste an average of 10% of their workweek searching for information they need to do their jobs. When the person who holds that information retires, the search becomes fruitless. The knowledge is simply gone.
A typical IBM i application portfolio contains millions of lines of code. Most of that code was written by people who are now approaching or past retirement age. Most of it is not documented. Most of the institutional knowledge required to maintain it safely exists in the heads of a shrinking group of veterans, and when they leave, they take it with them.
This is not a failure of planning. It’s the natural result of how IBM i systems were built: stable, reliable, and maintained by the same small team for decades. The stability was a feature. The knowledge concentration is now a vulnerability.
The Pipeline Isn't Coming
There is a common assumption that the talent shortage is a temporary problem, that eventually the market will produce enough developers with IBM i expertise to fill the gap. That assumption is wrong, and it’s worth being direct about why.
The broader developer workforce is already shrinking. The U.S. Bureau of Labor Statistics projects overall employment of computer programmers to decline 6% through 2032. Within that declining pool, the IBM i talent situation is more acute, the average age of IBM i developers continues to rise, and most organizations are looking at the reality that their most knowledgeable team members will retire within the next five to ten years. Meanwhile, 4.1 million Americans are turning 65 annually through 2027, with 11,400 baby boomers reaching retirement age every single day.
RPG is not taught in many universities. The developer communities around IBM i systems, while deeply experienced, are aging along with the platforms they support. New developers entering the field gravitate toward modern stacks with larger communities, more abundant learning resources, and wider career optionality. The number of developers acquiring serious IBM i expertise each year is not keeping pace with the number retiring from it. The gap is structural, not cyclical. Waiting for the pipeline to replenish is not a strategy.
What Most Organizations Are Actually Doing
Most IBM i organizations respond to the staffing pressure in one of a few ways. Some try to hire and find the pool thin and expensive. Some try to retain their existing experts past intended retirement, which works until it doesn’t. Some begin initiatives to move applications off IBM i entirely, which is expensive, risky, and often takes longer than planned. And some do nothing, managing the risk quietly until a departure forces the issue.
None of these approaches changes the underlying math. The knowledge concentration problem doesn’t resolve on its own, and the window to address it while experienced developers are still available is closing.
What Agentic Coding Changes About This Problem
Agentic coding doesn’t replace the developers who are retiring. Nothing does. But it changes the math of what a smaller, less experienced team can accomplish, and it creates the possibility of capturing institutional knowledge before it walks out the door.
The most urgent application is documentation. CoderFlow agents can analyze RPG and COBOL programs, identify business rules embedded in code, map dependencies across programs and databases, and generate documentation for both technical and non-technical audiences. This is work that veteran developers rarely have time to do themselves, and that new developers desperately need to operate effectively. Agents can systematically work through an application portfolio, surfacing and documenting the logic that currently lives only in the code and in people’s heads, while those people are still available to review and validate what’s been captured.
Beyond documentation, agentic coding changes the productivity equation for smaller teams. When agents run the build-test-fix loop autonomously, a team of three developers can move through a backlog that previously required ten. Parallel execution means multiple programs can be worked simultaneously. The constraint shifts from developer hours to review capacity, and experienced developers can be focused on the judgment calls that actually require their expertise rather than the execution work that doesn’t.
For organizations beginning futurization initiatives, agentic coding accelerates the work that is most time-sensitive: converting fixed-format RPG to modern procedures, refactoring data access from record-level to SQL, and futurizing green-screen interfaces to browser-based applications. These are programs that need to be addressed before the developers who understand them retire. Agentic coding makes it realistic to move through that work at a pace that matches the urgency.
The Window Is Narrowing
The staffing cliff is not evenly distributed across IBM i organizations, but it is coming for nearly all of them. The question isn’t whether experienced developers will retire. They will. The question is whether the knowledge and capacity they represent can be preserved and extended before they do.
That requires acting while veterans are still available to validate automated documentation, review agent output, and transfer context that can’t be recovered once it’s gone. Waiting until a key developer announces their retirement to begin this work is not a plan. It’s a gamble on timing, and the odds get worse every year.
The organizations that will navigate this well are the ones that treat the staffing cliff as the operational risk it actually is, assess where their knowledge concentration is highest, and put systems in place now to capture and extend it.
Agentic coding is the most practical tool available for doing that. Not because it replaces the people who are leaving, but because it changes what the people who remain can accomplish and gives the organization a way to work through the knowledge preservation problem at a pace and scale that manual effort alone cannot match.
If your organization is facing this pressure, the conversation is worth having now. Reach out to our team or learn more about CoderFlow at profoundlogic.com/coderflow.