Why Enterprise IBM i Development Needs a Better Foundation for AI

AI-assisted development is already part of daily work on IBM i. Developers ask an agent to explain a program, sketch a change, or estimate what else a field might touch. For a modest codebase that is a reasonable way to work. Enterprise estates are different. They hold millions of lines of RPG, COBOL, CL and SQL, and decades of business rules spread across programs, copybooks, service programs and database objects. No single person, and no single prompt, still holds that map.

The useful question is not whether AI can reason about this code. It can. The useful question is why hundreds of developers, and the agents beside them, should rediscover the same relationships every time someone asks. Application modernisation, impact analysis and ordinary maintenance all depend on those relationships. Rebuilding them from scratch, once per question, does not get more reliable as the estate grows.

The Problem: AI Can Reason, but Its Evidence May Be Incomplete

A general-purpose agent does not see an application all at once. It searches, retrieves a subset of source, and reasons over what came back. On a small project that subset is often enough. On a very large IBM i application, two weaknesses show up again and again.

The context is incomplete. Search returns the members that look relevant, which is not the same as the members that are relevant. A program may call a procedure in a service program that updates a field the search never opened. An agent can also stop early. Once an answer looks plausible, there is little pressure to keep looking. Dependencies outside the retrieved set are simply absent. The model cannot weigh evidence it was never given.

The meaning is ambiguous. A field named CUSTOMER-STATUS, a routine named VALCUST, or a block that resembles validation does not, by itself, establish what the business relies on. Similar names are reused for different purposes. The same rule is sometimes implemented more than once, years apart, in different styles. Names and patterns are clues. Experienced application knowledge, and evidence of how the code actually behaves, are what turn a clue into a conclusion you can stand behind.

Fluent answers hide this. A plausible conclusion reads like a finished one. It may still rest on a partial sample and an unverified reading of intent. The limit is the completeness and certainty of the evidence, not an inability to reason about code.

A Different Approach: Encode Application Expertise into the Analysis

MDiQ starts from a different place. Specialist algorithms, developed by experienced IBM i developers and application analysts, analyse the application natively on IBM i. They establish supported relationships among programs, modules, procedures, service programs, database objects, fields, calls, data usage and dependencies. Those relationships are stored in an Application Knowledge Graph and kept as the application changes, so the next question does not have to reconstruct them.

A developer or an agent can then ask for a defined slice of that knowledge, through the MDiQ interface or through MCP, REST and SQL. The structural work has already been done. The conversation can start from it.

The graph records structural facts the parsers were able to establish. It does not settle every question of business intent. A call, a field reference or a procedure boundary can be shown. What a status value means to the business, or which of two similar routines operations actually depend on, can still take an analyst. MDiQ separates what has been formally established from what still has to be inferred. It does not claim that every relationship in a decades-old estate has been found, or that a structural fact is the same thing as business meaning.

Why This Matters at Enterprise Scale

The cost of rediscovery is easy to underestimate one question at a time. Consider an illustrative scenario, not a measured customer result. An estate of 30 million lines of code. Five hundred developers. Each developer asks for analysis about twenty times a day. That is 10,000 analysis requests a day, before counting agents that run unattended.

If each request begins by searching source and inferring relationships again, the same calls, files and fields are retrieved and re-reasoned thousands of times. The work is redundant, and it varies. Two agents, given different subsets, can describe the same change differently. Latency, token usage and cost all grow with how much source is pulled into each conversation and how often the same inference is repeated. Those are consequences of where the work is done. They are not a benchmark, and this article does not claim a measured saving.

A shared graph changes the shape of the work. Discovering supported structure happens in the parsers, and the result is maintained incrementally as the application changes. Each request can start from that shared knowledge and spend its effort on the question in front of it: what the change means, which option to take, how to explain it. The structural starting point stays the same graph, rather than a fresh sample chosen independently for every developer.

Scoping: The Missing Ingredient in Large-Scale AI Analysis

Scale is a scope problem as well as a volume problem. An open question such as “tell me about the order application” invites an open-ended search. A useful question names the thing that is changing and asks what depends on it.

Take a concrete example: “What will be affected if we change the CUSTOMER-STATUS field?” Against the knowledge graph, that question is a traversal. Start at the field. Follow the programs, procedures and files recorded as using it. The result is an explicit dependency scope: a set of objects in view, and a much larger set left out. That scope can be given to an agent as a focused knowledge slice, through MCP, REST or SQL, instead of a retrieval across the whole estate. Asked again tomorrow, the same question can be run against the same graph and compared. The analysis is reproducible in a way a one-off search through source is not.

The boundary of the method should stay visible. Dynamic calls, overrides and other relationships the parsers do not support will not appear in that traversal. They may still matter, and they may still need a developer to investigate them. Scoping makes the known dependencies explicit. It leaves room for the investigation that sits outside them.

AI Governance Must Begin Before Code Is Changed

Most conversations about AI governance start at the moment of change: who may edit source, who must approve, and what may be deployed. Those controls matter. MDChange is the change-management layer for that work, so an AI-assisted change follows the same controlled path as any other change, from development through delivery.

They are not the start of the problem. Governance of an AI-assisted decision begins with the evidence behind it. If an agent recommends a change from a partial reading of the source, the later approval is approving a recommendation whose scope was never stated. MDiQ supports a traceable analysis scope: which objects were in view, which relationships were established, and which question the slice was built to answer. MDChange then governs what is allowed to change and how that change is delivered.

Together they are Knowledge-Driven Change™: application intelligence as the evidence, and established DevOps control as the path to production. MDiQ is the application intelligence foundation. MDChange is the complementary change-governance layer.

Expert Knowledge and AI Are Complementary

Specialist algorithms and general-purpose AI are good at different parts of the job. The parsers establish supported structural relationships and keep them in the graph. AI interprets that knowledge, explains it, compares options and helps a developer decide what to do. An agent with a defined slice of the graph can spend its reasoning on intent, impact and design. An agent without one spends the same effort trying to reconstruct the map.

MDiQ augments the AI tools a team already uses. It does not replace them, and it does not replace the people who know the business. The division of work is the point: expert-engineered analysis establishes what can be established; AI and developers reason about what to do with it.

A More Scalable Model for Enterprise AI Adoption

Put together, the model for a large IBM i estate is straightforward.

Accuracy means a conclusion that can be checked against established structure, with a clear line between a structural fact and an inference about meaning. It is a higher standard of evidence. It is not a guarantee that every analysis is complete.

Efficiency means the structural analysis is shared and maintained. Hundreds of developers, and the agents working with them, are not each repeating the same retrieval and the same inference. Any gain in latency, token usage or cost follows from that sharing. It should be measured in a real estate, not assumed from the architecture alone.

Evidence-based governance means the scope of an AI-assisted recommendation can be stated before anyone is asked to approve the change, and the change itself stays inside the DevOps controls the organisation already runs.

Conclusion: AI Should Not Have to Rediscover What We Already Know

Enterprise IBM i applications already contain the relationships that analysis keeps asking for. Re-deriving them from samples of source, once per question, per developer, per agent, becomes more expensive and less consistent as the estate grows. The expertise required to read this platform properly already exists. It can live in the analysis, where every subsequent question can use it.

Let expert-engineered software establish the application knowledge. Let AI use that knowledge to reason, explain and assist. And let established DevOps governance control the changes that follow.

That is Knowledge-Driven Change™.