When AI coding tools come up in an IBM i organization, the reaction is rarely simple.
Leadership sees productivity gains and wants to move fast. Developers wonder whether it is even viable on a platform this old. And underneath both is a quieter concern nobody states directly: if we point an AI at this codebase, what are we actually exposing?
The conversation in most IBM i shops starts with which AI tool should we use? GitHub Copilot, Cursor, Claude Code, an internal enterprise platform — the shortlist writes itself. It should start with something more fundamental: is this environment ready for AI assistance at all?
In most cases, the honest answer is not yet. And the reason has nothing to do with the AI tools.
Why AI Struggles With RPG Codebases
The first thing most IBM i shops discover when they point an AI tool at RPG is that the output looks convincing and fails to run.
Here is the pattern. A developer asks a copilot to add a fuel surcharge to order pricing. The AI edits ORDPRC001 — clean, plausible RPG that compiles on the first try. But the surcharge rate belongs in a data area the pricing routine reads at runtime, and PRCSRV, the service program behind it, validates an order total the change just broke. Three touchpoints. The AI saw one.
The natural conclusion is that the AI isn't good enough for IBM i yet — it needs more training, better prompts, a specialized model.
That conclusion is wrong.
A Context Problem, Not a Capability Problem
The real issue is not what the AI knows. It is what the AI can see.
AI tools assume codebases with navigable relationships, version history, explicit documentation, and a system-wide view. IBM i environments rarely provide any of it. RPG source lives in members organized by language type — QRPGLESRC, QCLSRC — not business function. Call relationships aren't declared in source. Service program dependencies hide in binding directories. Logic chains span programs with no map connecting them.
The surcharge failure wasn't bad luck. It was the guaranteed result of that structure.
This is not a training data problem. It is not a model capability problem. It is a structural mismatch between what AI tooling expects and what IBM i environments provide.
What AI Tools Actually Expect
A source physical file organizes members by language type. A Git repository organizes code by function, relationship, and history. These are different concepts, not different preferences — and every AI coding tool, regardless of vendor, is built for the second.
Understanding tasks — explaining a program, documenting an interface — work from partial context, so AI handles them well even in fragmented shops. Generative tasks require reasoning about the whole system. Without that structure, the AI is guessing: often well enough to look convincing, rarely well enough to run.
IBM i environments are not designed as navigable codebases. AI tools assume they are. That gap is the real barrier — and it is architectural, not technical.
The 2026 Stack Raises the Bar
The tooling has moved past autocomplete. Today's copilots are agentic — they open files, trace call chains, run builds, and edit across a project on their own. Cursor and Claude Code plan multi-file changes; enterprise copilots wire company knowledge in through retrieval-augmented generation; the Model Context Protocol (MCP) has become the standard way to hand an agent live access to systems of record.
Every one of those advances makes the environment matter more, not less. An agent that navigates dependencies is useless where dependencies are invisible. RAG can only retrieve context that exists somewhere retrievable. An MCP server can expose your call chains to any copilot — but only if you've extracted them first.
The smarter the tooling gets, the more expensive an unready environment becomes. Agentic AI doesn't lower the readiness bar. It raises it.
What AI Readiness Actually Requires
Four prerequisites, none of which were ever required before — which is why almost no shop has them.
Source control first. RPG and CL source must live in structured, versioned repositories — not source physical files. AI tools assume navigable, historical codebases. QRPGLESRC members are not an equivalent structure, and assuming they are is why most IBM i AI adoption stalls before it starts.
Explicit context. The business rules buried in RPG programs and batch jobs need to exist outside the code, in a form AI can consume — structured comments, meaningful names, short module docs. Shops with no machine-readable context get generic output. Shops that invest here get real assistance.
System visibility. Which programs call which service programs. Which jobs depend on which files. AI cannot reconstruct these relationships from source alone — they must be explicit, and once they are, an MCP server can serve them to any copilot the shop adopts.
A workspace model, not a member model. AI tools reason across projects. IBM i development has centered on a single member open in an editor. That model cannot support the cross-program reasoning that makes AI assistance powerful.
Governance Is Part of Readiness Now
That quiet concern from the opening — what are we actually exposing? — is no longer quiet. IBM i systems run payroll, billing, and inventory for regulated businesses, and an agentic copilot with system access is a new actor your auditors will ask about.
Three gates make AI use defensible. Data boundaries: define what source and data the AI may see, and keep production data out of prompts and indexes. Access control: start read-only, and grant write access per module, not per platform. Audit trail: every AI-assisted change should be attributable — who prompted, what the AI saw, what changed.
Shops that treat governance as a blocker will stall. Shops that treat it as part of the readiness work will be the ones allowed to scale.
What This Looks Like in Practice
Picture a distribution company: 2,800 RPG and CL programs, two developers who know where everything is, and a mandate to "do something with AI." Here is a first quarter that works.
Weeks 1–4: mirror source into Git, organized by business function, using tooling like the Code for IBM i extension. Weeks 5–8: extract call chains and file dependencies from DSPPGMREF and DSPDBR into a dependency map, exposed through an MCP server. Weeks 9–12: build a retrieval index over specs and runbooks, then pilot a copilot on read-only work — explaining programs, documenting interfaces, answering "what breaks if we change this file?"
Rerun the fuel-surcharge request at this point and the copilot's first move is to list all three touchpoints. That is the difference readiness makes. Generative work begins only then — one bounded module at a time, behind code review and an audit log.
How to Start
Readiness sounds like a program of work. Starting isn't. Pick one bounded module and run the checklist this month.
The goal isn't to transform the shop. It's to make one module AI-ready and let the result argue for the rest.
The Real Question
The IBM i community is asking whether AI copilots can work on RPG codebases. The answer is: yes, if the foundational work has been done. No, if it hasn't — and most shops haven't done it yet.
AI is not the foundation. It is the top layer. No amount of better prompting closes the gap between a source physical file and a navigable, context-rich repository.
The shops that get real value from AI will be the ones that treat source control, explicit context, system visibility, and governance as infrastructure investments — the work that happens before anything else. The copilots will keep changing. The readiness work transfers to whatever comes next.
The AI is ready for IBM i. The question is whether IBM i is ready for the AI.
Next in this series: From Fragmented Code to Navigable Systems — coming soon.