Does AI work for COBOL documentation too?

Yes. The same approach works for COBOL. General models handle COBOL better than RPG IV because there's more COBOL in training data. The prompt structure is similar: give explicit context about the language and platform, focus on explanation rather than generation.

Documenting RPG IV Code with AI: IBM i Developer Guide (2026)

IBM i shops have been fighting the documentation problem for decades. Programs written in RPG/400 in the 1990s with zero comments are still running payroll, managing inventory, and processing orders in 2026. The developer who wrote them retired. The documentation that existed was printed and lost. New developers stare at fixed-format RPG with cryptic 6-character field names and try to reverse-engineer what the business logic is doing.

AI changes this calculation significantly, not by writing new RPG, but by reading existing RPG and explaining it.

This guide covers exactly how to use AI for RPG IV documentation: which tools to use, which prompts work, what the limits are, and how to build a repeatable process.

Why Documentation First

Before any modernization project, refactoring effort, or onboarding initiative, you need documentation. It’s the prerequisite for everything else.

AI is most reliable when it’s reading and explaining code rather than generating it. For RPG IV specifically, where general models have thinner training data than for Python or JavaScript, explanation is where you get the most value with the least risk of hallucinated output.

The workflow: run AI documentation on your highest-priority or least-understood programs first. Generate internal comments, plain-English summaries, and data flow descriptions. Review them. This is lower-stakes than AI code generation, and the output is immediately useful to the development team.

Tools That Work for RPG IV Documentation

Claude (claude.ai or API)

Claude handles RPG IV better than GPT-4o in practice for documentation tasks. It’s more likely to recognize IBM i-specific constructs (CHAIN, READE, program calls via CALL/PARM) and produce accurate explanations rather than substituting analogies from other languages.

For large programs, the API with a long-context model handles programs that would overflow a chat window. The claude.ai interface (with Claude Sonnet 5 or Opus) handles programs up to several hundred lines cleanly in the standard context window.

ChatGPT / GPT-4o

Works for free-format RPG IV documentation with explicit context in the prompt. Less reliable on fixed-format RPG/400, it tends to confuse column positions and mix in free-format assumptions. If you’re working with older fixed-format code, Claude is a better choice.

IBM Project Bob

IBM’s VS Code-based tool built specifically for IBM i is the right environment if your team is adopting VS Code for IBM i development. Project Bob understands IBM i program call conventions, data structure conventions, and the RPG IV type system without needing explicit context in every prompt. The documentation generation is purpose-built rather than adapted from a general model.

Prompt Templates That Work

1. High-Level Program Summary

Use this before reading the code yourself. Get a map of what you’re about to deal with.

I'm working with IBM i (AS/400). The following is [free-format RPG IV / 
fixed-format RPG/400] source code.

Please provide:
1. A one-paragraph plain-English summary of what this program does
2. A list of external programs or service programs it calls (CALL, CALLP, prototyped procedures)
3. A list of files it reads or writes (F-specs or SQL statements)
4. The key input parameters and what they represent
5. The key output, what does it return, write, or update?
6. Any non-obvious business logic or IBM i-specific behavior

Do not explain basic RPG syntax. Focus on the business function.

[paste source code]

2. Procedure-Level Documentation

For a specific procedure or subroutine within a larger program:

I'm working with IBM i. This is a free-format RPG IV procedure.

Generate documentation in this format:
// ============================================================
// Procedure: [name]
// Purpose: [one-sentence description of what it does]
// Parameters:
//   [param name] (type), [description]
// Returns: [what it returns, or "none" for *VOID]
// Calls: [any external programs or procedures it calls]
// Files accessed: [any files read or written]
// Notes: [any IBM i-specific behavior, edge cases, or business rules]
// ============================================================

Only document facts you can confirm from the code. Do not guess at business 
context that isn't evident in the code itself.

[paste procedure]

3. Fixed-Format RPG/400 Explanation

Fixed-format is harder for general models. This prompt gives explicit context:

The following is fixed-format RPG/400 source code (NOT free-format RPG IV).
This runs on IBM i (AS/400). Column positions are significant.

Key things to know:
- Column 6: Form type (C = calculation, F = file, D = definition, etc.)
- Columns 7-8: Indicators
- Columns 26-35: Factor 1
- Columns 36-47: Operation
- Columns 48-53: Factor 2
- Columns 54-59: Result field

Explain what this code does in plain English. Focus on the business logic,
not the syntax. Note any operations that are IBM i-specific 
(CHAIN, READE, SETLL, EXFMT, etc.) and what they do in context.

[paste code]

4. Data Structure Documentation

RPG data structures are frequently undocumented and critical to understanding program flow:

I'm working with IBM i. These are RPG IV data structure definitions 
(D-specs or DCL-DS blocks).

For each data structure, explain:
- What this data structure represents in business terms
- What each subfield holds and its significance
- Whether it appears to be an externally described structure 
  (EXTNAME) or internally defined
- Any IBM i-specific types (like date format indicators, packed decimal, etc.)

[paste D-specs or DCL-DS definitions]

5. Subroutine to Plain English

For programs with many subroutines and no comments:

I'm working with IBM i. The following is a subroutine from an RPG program.

Translate what this subroutine does into plain English pseudocode.
Use indented steps, not code. The reader is a business analyst who 
understands the business process but not RPG.

Label each major step. If there are conditional branches, show them 
with "If [condition]: / Else:" in the pseudocode.

[paste subroutine]

6. CL Program Documentation

CL programs are often glue code that orchestrates other programs, and frequently undocumented:

I'm working with IBM i. The following is a CL (Control Language) program.

Please explain:
1. What this CL program does at a high level
2. The sequence of programs it calls and what each one does 
   (based on what the call tells you)
3. What files or objects it reads, creates, or deletes
4. What job or subsystem management it performs (SBMJOB, CHGJOB, etc.)
5. Any error handling logic

[paste CL source]

Building a Repeatable Documentation Process

The goal is to document systematically, not ad hoc. Here’s a process that works:

Step 1: Inventory List the programs you need to document in priority order. Prioritize: programs that are changing soon, programs that new developers are asking about, and programs where the original author has left.

Step 2: Automated first pass For each program, run the High-Level Program Summary prompt. Save the output. This takes 2-3 minutes per program once you have the prompt ready.

Step 3: Human review An experienced IBM i developer reads the AI output against the actual code. The review catches misidentified business logic, IBM i-specific behavior the model didn’t recognize, and errors. This takes 10-20 minutes per program rather than the hour it would take to write documentation from scratch.

Step 4: Embed in source Add reviewed comments directly to the source code. Use // comments for free-format RPG IV. Add a header block to each program with the summary.

Step 5: Version control the docs If your shop isn’t already in Git for IBM i source, this is a good forcing function. Documented source in version control is significantly better than documented source in an LPAR library with no history.

What AI Gets Wrong on RPG IV

Being direct about the limits:

Fixed-format column positions. General models consistently make mistakes with fixed-format RPG/400 column arithmetic. They often misidentify which columns hold which factors. The prompt template above mitigates this but doesn’t eliminate it. Always verify fixed-format documentation with someone who knows the code.

Indicator logic. RPG indicators (LR, 01-99, overflow indicators) are opaque to general models. The model will note their presence but often can’t trace what sets them or what they control without reading the entire program. Indicator documentation usually needs human completion.

Business context. The model documents what the code does mechanically, not what the business intends. A subroutine named CALCDISC that applies a discount will be documented as “applies a discount calculation”, the specific discount table, the business rules governing it, and the exceptions aren’t in the code. That context has to come from people, which is why losing your last RPG developer costs you more than the code itself.

Multi-program call chains. A single program calling 10 other programs, each with their own logic, requires documenting each program separately. The model can’t follow the runtime call chain without seeing all the source.

For IBM i Shops Starting This Work

The highest-leverage starting point is the programs your team asks questions about most often. Those are the ones where documentation pays back immediately.

If you’re looking at a broader modernization initiative, documentation with AI is the right first step before any code conversion work. You can’t responsibly convert or refactor code that nobody understands.

For AI tools specific to IBM i development beyond documentation, see AI tools for IBM i developers.

Frequently Asked Questions

Can AI write RPG IV documentation automatically without human review?

Not reliably. The first pass is useful and saves significant time. But IBM i-specific behavior, indicator logic, and business context require human review before the documentation is trustworthy.

Does Claude understand RPG IV better than ChatGPT?

In practice, yes, particularly for fixed-format RPG/400 and programs that use IBM i-specific operations heavily. Both require explicit context in the prompt. Neither replaces IBM i expertise.

Should I use IBM Project Bob or a general AI for documentation?

IBM Project Bob is better for developers working in VS Code with IBM i integration. General AI (Claude, ChatGPT) is more accessible if your team isn’t already set up with Project Bob, and works well for documentation with the right prompts. Both are useful; they’re not mutually exclusive.

How long does it take to document a program with AI?

A 200-300 line RPG IV program takes about 5 minutes to generate a first-pass documentation with the prompts above, plus 15-30 minutes for an experienced developer to review and correct. That’s significantly faster than writing documentation from scratch.

What about COBOL documentation?

The same approach works for COBOL. General models handle COBOL better than RPG IV because there’s more COBOL in the training data. For COBOL-specific prompt templates and a step-by-step workflow, see our guide to documenting COBOL code with AI.

For a broader look at AI tools available to IBM i developers beyond documentation: AI Tools for IBM i Developers.

Want the Full Toolkit?

The IBM i AI Field Guide expands everything in this article into a complete operational guide: a repeatable 4-step documentation workflow, 35 IBM i-specific prompt templates covering RPG IV, CL, DDS, service programs and more, a knowledge transfer playbook for upcoming retirements, and modernization planning templates. Built for IBM i shops that need to move fast on documentation before institutional knowledge walks out the door.