A vendor runs a demo for your team. The screen displays a lengthy RPG program and a prompt box. The presenter presses return. The language model generates two paragraphs of text to explain the business logic. The presenter smiles. The senior developer in the room leans forward and points at the screen. The second paragraph describes a pricing branch that does not exist in the source code. The vendor stops smiling. This is where most AI legacy code modernization attempts stop.
The system runs on IBM i. Programs written in the 1990s still compile and process production workloads today. A language model looking at those programs treats them like any other text file. It reads words and guesses the next likely word based on statistical probability. When a vendor feeds raw RPG into a language model, the results look impressive to executives. The results look terrifying to the developers who maintain the billing systems.
IBM i 7.4 reaches IBM end of support on 30 September 2026. Audit pressures increase. Budget reviews demand lower maintenance costs. The RPG developers who wrote the core systems approach their retirement dates. The pressure to map the legacy footprint is real. Relying on hallucinated descriptions creates unacceptable risk for your business.
What a language model does with raw fixed-format RPG
When you give a language model raw code, the model must guess the context. Fixed-format RPG carries minimal context in the words themselves. Variables have short names. Column positions dictate the meaning of a line. A character in column six dictates the specification type.
A human developer spends years learning to read these positions visually. The language model receives the text as a flat string. It assigns mathematical weights to tokens. The mathematical weights fail when the meaning depends entirely on horizontal spacing. The model attempts to find semantic meaning in blank spaces. It reads an indicator like *IN45 and processes it as a random string. The process destroys the positional context.
A model has a strict limit on how much text it can accept in one prompt. This limit is the context window. When a massive program exceeds that limit, the application feeding the model truncates the file. The model reads the first half of the logic. It never sees the file writes at the end. The generated description sounds confident and completely misses the database updates.
Another quiet failure happens with copy members. Copy members pull source from other libraries into a program at compile time. If the tool reading the source does not resolve the copy member, the model reads a gap in the logic. A model fills gaps. The model invents a copy member to fill the space. It writes a detailed explanation of a data structure that exists only in its own parameters.
The output is also non-repeatable. If you run the same raw program through the model twice, you get two different explanations. You cannot base a migration project on shifting text. AI code modernization requires a repeatable baseline. A strict architectural approach to the source code must happen before the text generation begins. When a project skips the structured read, the failures remain quiet and dangerous. The code looks analyzed, and the actual business rules remain hidden.
The failure shapes of AI legacy code modernization
When an unstructured tool processes IBM i source, the errors follow predictable patterns. You can identify these patterns during a trial phase. You must test for them before you commit to a platform.
| Failure shape | What causes it | The test that catches it |
|---|---|---|
| The model describes logic from the first half of a program and ignores the database updates at the end. | The application truncates the source file to fit the model context window. | You ask the model to list all file writes and compare the answer to the program source. |
| The model invents fields and data structures for an unresolved copy member. | The reading tool fails to locate the copy member and the model guesses the contents. | You search the output for variables that do not exist in the source or the real copy member. |
| The model explains the same program differently on two successive runs. | The system relies on statistical probability to guess answers from raw text. | You run the same prompt twice and compare the resulting descriptions for contradictory logic. |
| The model lists an external call that the application does not actually execute. | The model hallucinates a connection based on variable names. | You check the model output against the compiled DSPPGMREF output. |
These failures happen because a statistical model cannot parse strict syntax reliably. It produces a complete answer whether or not the facts exist. The model lacks facts. The model creates facts. You catch these inventions by comparing the generated text to the absolute reality of the compiled objects.
What a structured read of the source does first
Before a model sees any text, a parser must read the code. Golden Path Digital builds AS/Forward. AS/Forward is software that reads IBM i RPG source. It reads six RPG dialects through a proprietary ingestion layer. We tested the ingestion layer against roughly 5,000 programs drawn from PUB400 and public code repositories. We know how fixed-format RPG behaves.
The RPG language evolved over decades. Your systems might contain RPG II code written in the 1980s. The same library might hold RPG III logic from the 1990s. The developers might have added RPG IV syntax later. A single application incorporates multiple eras of syntax. AS/Forward handles this reality.
The ingestion layer applies strict rules to each line. It does not guess. It parses the syntax by rule. It builds an interconnection graph across every program, file, copy member and display file. It flags unresolved copy members and missing dependencies as warnings. This structured read produces a complete picture of the application. Our post on application dependency mapping for copy members covers how the relationships get found.
The parser records exactly which variables belong to which files. The parser maps where the copy members sit. If a copy member is missing, the tool generates a warning. An unresolved copy member is one the reading tool could not find. The warning list records exactly what the parser could not resolve.
The ingestion layer scopes a change in a migration view. You pick a field or object. The view lists what else moves. The interface displays a readiness status per program. A call target built at runtime does not appear in any static cross-reference, so it lands on the warning list as a dependency the pass could not follow. You must know they exist before you migrate anything.
Understanding the structure limits the scope of the project. You find programs that nothing calls. You map the actual footprint of the system. This mapping happens logically. The parser either finds the reference or it logs a warning. There is no guessing in the ingestion layer.
Feeding the graph and the code to the model
Once the parsing finishes, AS/Forward generates a plain-English description of each program from the ingested source. The model receives a structured package. The prompt includes the program text. The prompt includes the resolved copy members. The prompt holds the exact dependency graph. The model works one program at a time with the interconnection graph and a generated description attached.
A senior developer holds a mental map of the system. When a senior developer reads a program, they know which physical file holds the customer balance. They know which logical file provides the sorting index. AS/Forward builds this same map digitally. The interconnection graph records every relationship.
The prompt restricts the model from guessing. The model must rely on the structured data provided by the ingestion layer. Because the ingestion layer structures the data first, a smaller model does useful work on the output. A smaller model processes logic faster. It costs less to run. You get consistent results because the model responds to structured facts.
Verification becomes a simple process. A developer opens the member in the source physical file. The developer reads the generated sentence. The developer confirms the sentence matches the code. The text provides a reliable foundation for the next steps. AS/Forward converts to any target language the client picks. Python and free-format RPG are two examples.
Running an air-gapped AI legacy code modernization deployment
Security policies often prevent sending production code to external servers. CL programs that drive FTP transfers often hold a user ID and password as literal text. You cannot send those credentials to a public cloud API.
IBM i systems run core financial operations. These systems process payroll batches. They calculate healthcare claims. The data flowing through these programs carries strict regulatory protections. You cannot risk exposing the underlying logic to a public network.
The preferred deployment is air-gapped inside the client network. Running an AI legacy code modernization deployment in isolation protects your assets. AS/Forward runs against Claude, OpenAI, Gemini or local models on your own hardware. You install the ingestion layer behind your firewall. You host a local language model on your own servers. Our post on air gapped AI for source code covers the setup.
The source never leaves the network. You control the hardware. You control the model weights. The prompt history remains under your administrative access. The entire process stays internal. An air-gapped installation gives your security team the evidence it asks for. It protects your proprietary business logic. You get the benefits of automated code explanation within a secure boundary.
How to build a test set and score the answers
You need a way to measure the accuracy of the output. You build a test set from programs your developers know intimately. You select a billing calculation program. You select a complex order entry program. A daily reporting job provides a different logic test. A month-end close procedure tests the batch processing rules.
You process these specific programs through the ingestion layer and the model. You generate the plain-English descriptions. You hand the descriptions to the developers who maintain those programs. The developers score the answers.
They read the explanation of the tax calculation branch. They verify the file updates against the source code. The external calls undergo strict review. The team grades the output for accuracy and completeness. A structured system allows you to trace any error back to the parser or the prompt.
If the developers find errors, they flag them. We correct the read. You rerun the test set. This process creates trust in the automated descriptions. Your team learns to rely on the generated text because they proved its accuracy on familiar logic.
What AI legacy code modernization still cannot do
Automated tools have strict limits. A model cannot determine why a business rule exists. The source logic applies a discount if the customer state is Texas and the order total exceeds four hundred dollars. The source text omits the fact that a former sales director promised this discount to a specific client in 1998. The human context remains outside the digital files.
A model cannot recommend a target architecture. It cannot suggest moving the logic to a different server. It has no capacity to endorse keeping green screens and modernizing behind them. Understanding comes first and the target decision comes second. The second decision belongs to the client.
A model cannot reconstruct a lost database schema from runtime behavior alone. DSPPGMREF reports which files a program references at the file level. It captures references at compile time. The model reads what is recorded in the compiled objects. It cannot invent business intent that the original programmer omitted from the original files. The tool maps the reality of the system. The tool records exactly what the original programmer wrote. The reality of AI legacy code modernization involves strict boundaries.
Start your modernization assessment today
Golden Path Digital built AS/Forward to solve the parsing problem first. AS/Forward carries one US patent pending. We process the code structurally. The parser builds the graph. The system generates the plain-English descriptions. The interface displays the readiness status. We map the reality of your IBM i footprint. A successful AI legacy code modernization project requires knowing the exact system state first.
You can make one decision today. Ask us to read your production source libraries. We offer the IBM i modernization assessment. We ingest your production source libraries and hand back the program count, the dependency graph, the plain-English descriptions, the warning list and the list of programs nothing calls. Understanding the code prevents failed migrations.
Or we install AS/Forward air-gapped on your own hardware and it reads the source there. We handle custom software development to support your exact requirements. Call 501-232-7188 to discuss your environment. Reach out through our contact page and tell us how many RPG programs sit in your production libraries.