Most IBM i shops believe they already have everything AI needs.
After all — the source members exist. The system runs. The business depends on it. So the assumption is: if the AI can read our RPG programs, it should be able to work with them.
That assumption is wrong. Having source members is not the same as having a system the AI can understand.
A note on timing: parts of this series were drafted before IBM's Premium Package for i went GA in July 2026. Bob doesn't weaken the argument that follows — it sharpens it — and this article now addresses it directly.
What AI Actually Needs to See
AI does not read code the way an IBM i developer does. A senior RPG developer fills in missing context from years with the system. AI depends entirely on what is visible in the environment: file relationships, structural organization, dependency chains, embedded context. Without these, it is not reasoning — it is guessing.
This matters more in 2026, not less. Agentic copilots like Cursor, Claude Code, and now IBM Bob work by navigating — opening files, tracing call chains, following references. Bob is the clearest proof of the point: IBM built it tools to read members straight out of QSYS, cross-reference source, and scan QSYS2.SYSDEP for dependencies — an entire machinery whose only job is reconstructing the structure the environment doesn't expose. When the vendor ships a navigation engine, it's because there was nothing to navigate.
Fragmented Source vs. Navigable Systems
Most IBM i environments are not structured as systems. They are structured as collections.
RPG programs exist in source members spread across source physical files, grouped by language type rather than by business function. A program in QRPGLESRC has no declared relationship to the service program it calls in a binding directory, or to the physical file it reads, or to the CL procedure that submits it as a batch job. Those relationships exist — but only in the minds of the people who built the system.
A navigable system is fundamentally different. It provides a clear structure of components, defined relationships between them, a way to traverse from one part of the system to another, and a representation of how the system behaves as a whole.
Without navigability, the AI is operating in a fragmented view. It sees individual source members. The system those members form has to be reconstructed by the tool — and whatever it reconstructs belongs to the tool, not to you. Nobody in your shop can read it, validate it, or take it to the next tool.
Why Fragmentation Breaks AI on IBM i
Make it concrete. ORDBCH100 is a nightly batch program: it calls three service programs, updates five physical files, enforces rules added across twenty releases, and is submitted by a CL program that owns the error routing. None of those relationships are visible to an AI reading ORDBCH100's source — the bindings live in a binding directory, the file dependencies are undeclared, the CL is a member it has never seen.
Ask a copilot to modify ORDBCH100 and it assumes isolation. The output looks correct in isolation — and breaks when it meets the actual system. This is the failure from Part 1, generalized. (There, a copilot asked to add a fuel surcharge edited one pricing program cleanly — and silently broke the two other programs that computed the same charge independently.) The AI did not fail because it was wrong about the code it could see. It failed because it could not see enough of the system.
The Missing Layer: System Structure
The real gap is not tooling. It is structure.
IBM i systems were not designed to expose dependency graphs or execution flow in a form that tools can consume. Object-based organization — programs, service programs, data queues, physical files all living as objects in libraries — made sense for the platform's operational model. It does not provide the structural visibility that AI depends on.
This is also why IBM i modernization efforts struggle in general, not just with AI. Large IBM i environments often lack central visibility into what calls what, which jobs depend on which files, and how changes ripple across the system. AI simply makes that structural gap more obvious and more costly.
What 'Navigable' Actually Means for IBM i
A navigable IBM i system is not just RPG source in files. It is a system where four properties hold.
1. Relationships are explicit. Which programs call which service programs. Which jobs depend on which files. Which modules bind together. These connections are declared in the repository structure, not inferred from object libraries at runtime.
2. Structure reflects the system. Source organization mirrors the business architecture, not the language type. RPG programs, CL procedures, and service programs that serve the same business function live together — not scattered across QRPGLESRC and QCLSRC with no visible relationship.
3. Flow can be traced. You can follow a business transaction from the CL job that submits it through the RPG programs that process it to the physical files it updates — without asking the developer who wrote it twenty years ago.
4. Context is accessible. Business rules are discoverable. The logic encoded in RPG indicators, nested conditions, and multi-program chains is documented in a form a tool can read — not just a person who already knows the answer.
These four properties are what allow AI to understand, reason, and generate meaningful RPG output. Remove any one of them and the AI's output degrades accordingly.
Why This Matters Before AI
This is not just an AI problem. Even without AI, fragmented IBM i systems create real operational costs: new developers take months to become productive, changes to core RPG programs carry significant risk, critical knowledge lives with a shrinking group of experienced staff, and debugging cross-program issues is slow and expensive.
AI does not introduce this problem. It exposes it.
Here is the uncomfortable part: with tools like IBM Bob, doing this in the wrong order no longer fails loudly. Point an agentic tool at an unprepared environment and it will deliver real value on day one — it was engineered to. The new failure mode is quieter: the shop never builds structure it owns. Every dependency graph, every extracted rule, every reconstructed flow accumulates inside one vendor's runtime — in a form your team cannot read, your business has never validated, and no other tool can use. And as agent memory matures, that gap doesn't shrink; it deepens, because the vendor's understanding of your system compounds while yours doesn't. It works just well enough that the structural work never happens.
The tools no longer force the right order. That makes the order a choice — and the line that matters is not who extracts your structure, but what format you are left holding. Structure you can read, diff, and point at any tool compounds across every vendor. Structure that lives only inside one runtime compounds for the vendor, not for you — no matter that it describes your system.
A Practical Starting Point
You do not need to transform the entire IBM i estate at once. Start with one business system or module: make its relationships visible, organize its RPG and CL source by business function, document its key flows. Even partial structure improves AI outcomes significantly.
The payoff compounds with the current tooling. A dependency map extracted from DSPPGMREF can be served through an MCP server to any copilot the shop adopts — and this is not a workaround, it is the designed extension point. IBM's own Premium Package for i documents MCP servers as the way to inject application architecture, internal standards, and domain knowledge into Bob for complex estates. The context layer you build is what you plug into Bob, Copilot, or whatever comes next. Build it once, and every tool benefits — including the ones that don't exist yet.
And you do not have to build it by hand. Tools like ARCAD's DISCOVER and Fresche's X-Analysis already map dependencies and extract rules automatically — buying that head start is a reasonable way to move faster. But it does not settle the question; it relocates it. Ask what you are left holding when the extraction is done. A graph you can export, read, and version is a structural asset you own, whoever generated it. The same graph reachable only through the vendor's own interface is one you rent, however accurately it describes your system. Owning your structure is a property of the format, not the labor — so make portability, not automation, the thing you evaluate the tool on.
Score Your Shop
AI does not need perfect IBM i systems. But it does need IBM i systems it can see. So here is a test you can run in the next sixty seconds: one point for each of the four properties that actually holds in your environment today.
Most environments I've seen score a 1 — usually some structure, nothing traceable. A 4 is rare. If you think your shop breaks that pattern, or you think one of these four properties matters less than I'm claiming, I want to hear it.
What's your score? Tell me in the comments on LinkedIn — disagreement welcome.
This is Part 2 of a five-part series on making IBM i environments AI-ready. Part 3 — Making Business Logic Machine-Readable, on surfacing the rules hiding in indicators, cryptic names, and multi-program chains — is next. Follow me on LinkedIn to catch it.