The job posting has been up for months. The few candidates with real RPG experience are either already employed, or asking for a salary the budget cannot support. Meanwhile, the team that is still there keeps absorbing the work.
For a growing number of IBM i organizations, this is not a temporary hiring delay. It is the new shape of the market. And the organizations making real progress have stopped asking how to find RPG developers and started asking a different question: how do we build them?
The Hiring Market Is Not Going to Solve This
The IBM i community has been talking about the skills gap for years. In 2026, it became the top concern.
In a 2026 IBM i Marketplace Survey (opens in a new tab), IBM i skills ranked as the number one concern among IBM i professionals, the first time since 2017 that it displaced the previous top issue. According to IT Jungle's coverage of the results (opens in a new tab), 69% of respondents named it a top concern, up from 60% the year before.
The report points in a specific direction, with skills at the top of the list, organizations need to get the most from their IBM i talent through mentoring and education.
Hiring is still part of the answer, but it cannot be the whole strategy when the pool of experienced candidates keeps shrinking. If your plan depends on finding someone who already knows RPG and already knows your business, you are competing with every other IBM i shop for the same small group of people.
What Is Actually Scarce
It helps to separate two kinds of knowledge that often get lumped together as "RPG skills."
The first is the language and the platform: RPG syntax, CL, Db2 for i, how compiles work, how jobs run. This is learnable. Former IBM i Chief Architect Steve Will made the point directly when discussing the survey results, noting that teaching IBM i to an experienced computer professional is relatively easy.
The second is knowledge of your applications: which programs run the business, what the undocumented rules mean, why a strange-looking condition exists, which changes are safe. This is the knowledge that is genuinely scarce, because it exists only in your code and in the heads of the people who have maintained it.
The distinction matters because it changes where the investment should go. You do not need to find people who already have both kinds of knowledge. You need people who can learn the first, and an environment that makes the second accessible.
Three Places to Build From
Your organization may have more potential capacity than its org chart suggests. When the search focuses only on experienced RPG developers, it overlooks people who are already on the payroll and already know the business, along with newer developers who could grow into IBM i work with the right support. Each of the groups below needs a different kind of investment, and each one adds capacity in a different way. Look in three places.
1. Your Existing IBM i Team
The developers you already have hold the scarcest knowledge of all. The goal is not to replace them but to multiply what they can do, and that increasingly means working effectively with AI.
Developers who can direct AI agents, write precise requirements, provide the right context, and review AI-generated changes critically can deliver far more than they could alone. Those are learnable skills, and they are different from the skills that made someone a strong RPG developer.
AI Foundations (opens in a new tab) is our hands-on training built for exactly this group. Across three live 90-minute sessions over two weeks, IBM i developers work through AI terminology, prompt engineering, and context engineering using real RPGLE, SQL, and Node.js examples. No prior AI experience is assumed, and the goal is judgment: knowing what AI does well, where it fails, and how to tell the difference.
2. Developers You Already Employ in Other Languages
If your organization also employs developers who work in Java, C#, JavaScript, or Python on other systems, those developers already understand programming, data, and business logic. What they lack is familiarity with IBM i.
That gap is smaller than it used to be. Free-format RPG reads much more like the languages these developers already know than fixed-format code does. And with Profound.js (opens in a new tab), part of Profound AppDev (opens in a new tab), developers who know JavaScript and Node.js can build new capability that works directly with IBM i data and existing RPG business logic, contributing to IBM i applications in a language they already use.
The practical step is simple: identify developers elsewhere in the organization who are curious about IBM i, and give them a contained first project alongside someone who knows the application.
3. Early-Career Developers
With few universities teaching IBM i, recent graduates rarely arrive knowing RPG, and expecting them to is unrealistic. What they may bring instead is experience working alongside AI tools, which is increasingly how development work gets done on every platform.
Hiring for aptitude and curiosity rather than RPG experience widens the candidate pool considerably. The tradeoff is that early-career hires need structured mentoring, which is where the next section becomes essential.
Make the Codebase Learnable
Every one of these strategies runs into the same obstacle: a codebase that is hard to learn. Fixed-format RPG, logic that was never documented, and data access patterns that only make sense to someone who has worked with them for years all lengthen the ramp for anyone new.
That obstacle is not fixed. It can be reduced deliberately.
Convert to free-format. Free-format RPG is far more approachable for developers who learned on modern languages, and converting it does not change what the programs do.
Refactor data access toward SQL. SQL is a skill nearly every developer already has. Moving record-level access to SQL makes data logic readable to a much wider group.
Document what the programs actually do. The knowledge that lives only in senior developers' heads is the hardest thing for a new developer to acquire. Writing it down, program by program, turns it into something anyone on the team can learn from.
These used to be multi-year efforts that competed with everything else for the same scarce developer time. With Agentic Futurization, powered by CoderFlow (opens in a new tab), AI agents handle the conversion, refactoring, and documentation work inside your environment, with every change validated before a developer approves it. CoderFlow's skills system also encodes how your environment works, so agents do not need the months of acclimation like a new hire does. The result is a codebase that new developers can learn from, rather than one they have to decode.
A First 90 Days for Building Capacity
There is no single right sequence, but a structure like this keeps the effort concrete.
Month one: build AI fluency and pick your people. Put your existing IBM i team through AI training so they can direct and review AI-assisted work. At the same time, identify the developers, internal or newly hired, who will be building IBM i skills.
Month two: make the most-touched programs learnable. Start with the programs that change most often, since that is where new developers will work first. Convert them to free-format, document their logic, and clean up their data access.
Month three: learn through real work. Pair each developer who is building IBM i skills with a senior developer on real changes. Reviewing AI-generated changes together is a particularly effective way to learn, because every review is a discussion of what the code does and why it matters to the business.
By the end of the quarter, the goal is not a fully independent RPG developer. It is a developer who can make real contributions with review, on a codebase that is getting easier to learn every month.
Where Outside Help Fits
Building capability takes time, and the backlog does not pause while it happens. That is where staff augmentation (opens in a new tab) fits, experienced IBM i developers who add capacity now, while your own team builds skills.
The best augmentation engagements support the build strategy rather than replacing it. They document what they touch, they work alongside your developers rather than in isolation, and they leave knowledge behind when the engagement ends.
For Senior Developers: You Are the Curriculum
If you are a senior RPG developer, this strategy depends on you more than anyone. The knowledge that makes you valuable is exactly the knowledge the next generation of developers needs.
That does not have to mean writing training materials in your spare time. It can mean reviewing a newer developer's work and explaining why a change is risky. It can mean confirming that AI-generated documentation of a program you know well is accurate. It can mean answering questions during a pairing session instead of in an emergency.
The difference between knowledge that walks out the door and knowledge that stays is whether anyone captured it while there was still time. Senior developers who help build the next generation are not making themselves replaceable. They are making the business resilient, and making their own work less dependent on being the only person who can do it.
Start With the Team You Have
The IBM i skills gap will not be solved by a better job description. It will be solved by organizations that decide to build capability on purpose: equipping the developers they have, widening who can contribute, and making their applications something new people can learn.
Futurization™ (opens in a new tab), our one-of-a-kind methodology for building new capability on top of proven IBM i applications instead of replacing them, is built on that same idea. The applications and the expertise you already have are the foundation, not the problem.
A good first step is giving your current team the skills to work with AI confidently. To schedule a kickoff call for AI Foundations or talk through a broader capability plan, reach out to Futurization@ProfoundLogic.com.