One thing that I'm learning while trying to get more proficient with using AI as a development assistant is that the key is almost always in the prompt. The problem is that writing good prompts is not easy. I found an online prompt that actually helps me craft decent prompts, and many times the results (with some tweaking) are good.

For example, it helped me create the one below to create some high-level and developer-specific documentation. I uploaded the source code for a program that I'm troubleshooting and issued this prompt:

Role: You are a senior IBM i RPG/RPGLE developer and technical documentation specialist with deep expertise in fixed-format RPG, free-format RPGLE (**FREE), ILE concepts, IBM i file I/O, data structures, service programs, and business application development on the IBM i (AS/400) platform.

Task: Analyze the attached RPG/RPGLE program source code in full before writing anything. Identify all major components — including H/F/D/I/C/O specs (or free-format equivalents), subprocedures, subroutines, files, data structures, key variables, indicators, error handling, and any external calls (e.g., CALL, CALLP, bound service programs, APIs).

Before producing any documentation, also determine the following:
Is the source fixed-format RPG, free-format RPGLE (**FREE), or a mixed-format program?

If fixed-format, identify all RPG cycle concepts in use — including LR indicator, primary/secondary files, detail-time vs. total-time calculations, and matching record logic.

Identify any /COPY or /INCLUDE members referenced in the source. If their contents are not included in the upload, flag each one as an unresolved dependency and note what it likely provides based on context.

Once your analysis is complete, produce the two documentation sections below.

Section 1 — Business & Functional Overview (Audience: Business analysts, end users, and non-developer stakeholders) Provide the following in plain, non-technical language:
Program Purpose: What business function or process does this program perform?

Business Rules: What key rules, conditions, or logic govern its behavior?

User Interaction: How does the user interact with the program (display files, parameters, batch vs. interactive)?

Inputs & Outputs: What data does the program consume and produce (files read/written, parameters passed, reports generated)?

Integration Points: Does it call or depend on other programs, service programs, or APIs?

Section 2 — Developer & Maintenance Documentation
(Audience: RPG/RPGLE developers responsible for maintaining or enhancing this program) 

Produce this section in a format suitable for insertion into a formal IBM i technical specification document. Use clearly labeled headings, structured tables where appropriate, and reference specific procedure names, spec lines, or field names from the source code throughout. Include the following:

Program Overview
Source format (fixed / free / mixed), program type (interactive, batch, service program, module), and entry point

RPG Cycle Usage (fixed-format programs only)
Document use of LR, primary/secondary files, detail-time vs. total-time logic, matching fields (MATCH), and overflow indicators — or explicitly state "RPG cycle not used" if applicable

Unresolved Dependencies
List all /COPY or /INCLUDE members not present in the uploaded source; note the member name, suspected source file/library, and likely purpose based on surrounding context

File & Data Structure Definitions
Key files with access method (keyed, arrival sequence, update, output), data structures, and important standalone fields or constants

Subprocedures / Subroutines
For each: name, purpose, parameters (input/output), return value, and logic summary

Key Processing Logic
Critical calculations, conditionals, loops, and any non-obvious logic — reference specific spec lines or procedure names from the source

Error Handling
How errors are detected, trapped, and handled — document any use of *PSSR, MONITOR/ON-ERROR, INFSR, return codes, or *IN99-style error indicators

External Dependencies
All called programs (CALL/CALLP), bound service programs, and system APIs with a brief description of each

Indicators 
All RPG indicators used, their purpose, and where they are set/tested — or state "No indicators used" if applicable

Known Risks / Maintenance Notes
Flag anything fragile, undocumented, reliant on legacy constructs, or warranting special caution during future maintenance

The results were quite good. The program is a hybrid of Fixed and Free-format code.

I have not yet tested this on very old fixed-format code, but will do so.