IBM Trained an AI on 10 Million Lines of RPG. It Still Can't Write It.

IBM has spent more than two years and a public, community-sourced training effort building an AI system specifically to read, explain, and eventually write RPG. That's an unusual bet — no other vendor has trained a foundation model on a fixed-format 1960s business language and its free-format descendant. The pitch is simple: RPG shops are short on people who can read forty-year-old cycle-based logic, so let a large language model do the reading, and eventually the writing, for them. Whether that pitch survives contact with actual RPG code is a different question. Based on IBM's own public disclosures over the past two years, the honest answer sits somewhere between the vendor slides and the reflexive 'AI can't touch my RPG' dismissals — closer to the latter than IBM would probably like.

The Pitch: An AI That Has Read More RPG Than Most Programmers

In May 2024, at the POWERUp conference, IBM i chief technology officer Steve Will announced that IBM was formally building a code assistant for RPG, filed under announcement letter AD24-2179, with a mandate to help developers 'understand existing RPG code, create new RPG function using natural language description, and automatically generate test cases.' IBM had already run an internal proof of concept by that point, and Will's assessment of it was notably blunt for a product announcement.

“They worked on it for a few months and they produced a passable result. I mean, it's not good enough for prime time, but it proved that you could do all of those things.”

Steve Will, IBM i CTO

Two things stand out about that admission. It came directly from the person running the platform, not from a critic. And it set the tone for everything that followed: every subsequent IBM announcement about RPG AI tooling has shipped later, and with a narrower scope, than the original pitch implied.

Where the Model Actually Learned RPG

The RPG-specific capability sits on top of IBM's Granite family — Granite 8B, a decoder-only large language model IBM built and open-sourced as part of watsonx. Granite's general-purpose training drew on roughly 6 petabytes of raw multilingual internet content, filtered down to about 2.4 terabytes of usable text and tokenized into more than a trillion tokens. That produces a competent general coding model. It does not, on its own, produce a model that understands the RPG cycle, because there is nowhere near that volume of public RPG source on the open internet the way there is for Python or Java.

So in July 2024, IBM launched a public call for RPG code donations, explicitly asking for 'embarrassingly ugly code' — old fixed-format RPG II, RPG III, and OPM source in particular, plus question-and-answer pairs explaining what specific constructs do. Recognizable names in the IBM i community, including Susan Gantner, Scott Klement, Paul Tuohy, and Jim Buck, contributed samples through a GitHub-hosted portal, choosing whether their code stayed IBM-internal or went public. By the time IBM's public preview shipped roughly a year later, the company said it had fed more than 10 million lines of community and internal RPG code into the Granite models behind the assistant.

The RPG Cycle Doesn't Read Like Other Legacy Code

There's a structural reason RPG is a harder training target than COBOL, and IBM's own partners and executives have said so on the record. Speaking to IT Jungle in mid-2025, Fresche Solutions CTO John Clark described the difficulty directly.

“We really struggled with RPG. The challenge is always in the aspects of RPG which may be implicit.”

John Clark, CTO, Fresche Solutions

The problem Clark is describing isn't vocabulary, it's implicit structure. COBOL's procedural code reads roughly the way a model trained on generic imperative languages expects code to read: statements execute in the order they're written. RPG's traditional cycle — the implicit read-calculate-output loop baked into fixed-format RPG, plus constructs like data areas that carry state outside the visible source — has no real equivalent in the training corpora that make up most foundation models' coding knowledge. Steve Will made the same point about IBM's own engineering effort.

“RPG is different enough that there were things we had to do differently and train differently.”

Steve Will, IBM i CTO

That's a tacit admission that the RPG assistant couldn't simply reuse the pipeline IBM had already built for its mainframe COBOL tool, watsonx Code Assistant for Z, which had entered tech preview a full two years earlier, in September 2023, and shipped COBOL-to-Java conversion as its first use case.

It's worth being precise about what 'implicit' means here, because it's the crux of the whole problem. A COBOL PERFORM statement, or a Java method call, tells a model exactly what happens next: control transfers to a named paragraph or method, runs, and returns. Fixed-format RPG's program cycle does the opposite. The read, the record-identifying indicators, the detail and total calculations, and the automatic output all happen without a single visible instruction telling the reader that a loop exists at all — the loop is a property of the compiler, not a line of source a model can point to and reason about. A data area referenced through IN/OUT operations carries state across program calls with no parameter list showing that dependency either. Training a model to explain that kind of code means training it to reconstruct behavior that was never written down explicitly in the first place, which is a fundamentally different task than summarizing code where the control flow is already on the page.

What Actually Shipped, and What It Actually Does

The private preview of watsonx Code Assistant for i was announced at IBM Think in early May 2025; a public preview followed that July, running as a Visual Studio Code plug-in with no Rational Developer for i support planned. That last detail matters more than it looks. RDi, not VS Code, is where most working RPG developers actually spend their day, because it's the tool built around IBM i's compile, debug, and source-member workflow. Shipping the assistant first as a VS Code extension means the people it's aimed at have to change editors, or at least keep a second one open, before they can use it at all — a real adoption friction that a feature-complete comparison table doesn't capture.

Crucially, the preview does exactly one thing: it explains existing RPG code. Point it at a program and it returns a detailed line-by-line explanation, a business-level summary, a plain-language description of what the program is used for, or documentation formatted for insertion into the source. That's the entire feature set. The two capabilities IBM's own 2024 announcement letter promised — generating new RPG from a natural-language description, and automatically writing test cases — were pushed to a later, unspecified phase, with general availability targeted for the second half of 2025.

IBM's own team has been candid about the preview's reliability. Demonstrating the tool, IBM's Edmund Reinhardt told IT Jungle plainly that the assistant is not something a developer should trust unconditionally, and that it will hallucinate the way every large language model does.

“It's not something you trust 100 percent.”

Edmund Reinhardt, IBM

Then IBM Rebuilt the Whole Program Around Someone Else's Model

The clearest signal about how far the from-scratch Granite-for-RPG approach actually got arrived in October 2025, when IBM announced Project Bob at its TechXchange conference — a unified code assistant merging the previously separate RPG and COBOL tools, demoed by Neel Sundaresan, IBM's general manager of automation and AI. Project Bob's primary model isn't Granite. According to IT Jungle's reporting, IBM built the tool around an external frontier model rather than Granite, described internally as the model IBM considers best for code analysis, with Granite relegated to a secondary role alongside Meta's Llama and Mistral models. Just as telling: IBM's own published page for Project Bob doesn't mention RPG or COBOL conversion at all, despite those being the foundational use cases of the two products it absorbed.

Read that number for what it measures: general-purpose internal engineering productivity across IBM's own software organization — largely Java migrations, framework upgrades, and Ansible or Terraform scripting — self-reported over a four-month internal test with no independent audit and no RPG-specific breakdown. A 45 percent productivity lift on Java 8-to-17 upgrades says very little about whether the underlying system can safely touch a forty-year-old order-entry program built on undocumented data areas. IBM has not published an equivalent figure for RPG.

So: Can It Actually Write RPG?

As of this writing, the honest answer is no — not in general availability, and not without close supervision even in preview. Here's what's actually been demonstrated versus what remains a roadmap promise, based on IBM's own statements to the trade press:

• Shipping and verified: RPG code explanation — line-level, business-level, and documentation generation — via a VS Code plug-in, built on a corpus of 10-million-plus lines of donated and internal RPG.
• Shipping but explicitly caveated by IBM's own staff: those explanations can hallucinate and are, in IBM's own words, 'not something you trust 100 percent.'
• Announced in 2024, not yet generally available: natural-language-to-RPG code generation.
• Announced in 2024, not yet generally available: automatic test case generation for existing RPG programs.
• Unclear after the Project Bob merger: whether future RPG generation will run primarily on Granite, or on the external model IBM adopted for Project Bob, with Granite in a supporting role.
• Not on the public roadmap: autonomous, agentic modification of production RPG systems — IBM has described this only as future exploration via the Model Context Protocol, not a shipping capability.

What This Actually Means for Shops Running RPG Today

None of this makes the effort a stunt. IBM shipped a working, if narrow, tool that does one genuinely useful thing: it can turn an undocumented forty-year-old RPG program into a plain-language explanation fast enough to matter for onboarding and impact analysis. That's exactly the kind of task IBM's own partners have flagged as the real bottleneck in RPG shops — not a shortage of people who can write new syntax, but a shortage of people who can read what the last three programmers left behind. That's a real, if modest, win, and it's the one part of the pitch that has actually shipped, works roughly as described with the caveats IBM itself gives, and doesn't require handing a production system over to a model that admittedly hallucinates.

The code-generation and test-generation promises are a different matter. They've been 'coming later this year' since 2024, IBM quietly swapped its own foundation model out for a third-party one in the flagship successor product, and the company has published no RPG-specific accuracy or reliability numbers to weigh against the general engineering-productivity claims it has published elsewhere. Treat the explanation tooling as a real, usable aid today. Treat any claim about AI generating or maintaining production RPG on its own as unproven until IBM — or an independent shop that has actually run it in production — publishes numbers to back it up.

There's also a quieter lesson in the Project Bob pivot that's worth sitting with regardless of which vendor's model ends up doing the work. IBM spent two years and a public code-donation drive building an RPG-literate model from the ground up, and when it needed the best available system for serious code analysis, it reached outside its own stack rather than betting the flagship product on what it had built. That's not a knock on the RPG training effort specifically — a domain-specific fine-tune on top of a strong general model, which is roughly what the Granite-plus-RPG-corpus approach amounts to, is still a reasonable way to get a system that recognizes cycle-based constructs a purely general-purpose model would misread. But it does mean the interesting long-term question for RPG shops isn't 'which vendor has the RPG model,' it's 'which general-purpose model is currently best at code reasoning, and does whatever wraps it actually understand this specific dialect of a specific language on this specific platform.' That's a moving target, and it will keep moving faster than any single vendor's roadmap.

For a shop actually deciding what to do with this today, the practical read is narrower than either the hype or the dismissal suggests. Point the current tooling at genuinely undocumented legacy programs where a plain-language explanation saves real onboarding time, and treat that explanation as a first draft a person who already knows the business logic still has to check, not a verified fact. Don't route anything the assistant generates straight into a compile-and-deploy pipeline without the same code review a junior developer's work would get, and don't take a vendor's internal productivity number from an unrelated codebase as evidence about RPG specifically. None of that requires waiting for a future release. It just requires treating the tool as what IBM's own engineers already call it: not something you trust 100 percent.