By George VanEaton
IBM i Engineering Leader | IBM Redbooks Contributing Author
AI-assisted development discussions often begin with code generation.
For IBM i teams maintaining mature applications, I think the more interesting question is different:
Can AI help us understand and safely evolve systems that already contain decades of business and operational knowledge?
That is the question I have been exploring through my work with IBM Bob.
I have spent more than 30 years working with IBM i, RPG, Db2 for i, SQL, production systems, and the applications built around them. My most useful experiences with Bob have not centered on asking it to generate RPG. They have centered on giving it enough context to help with application understanding, standards-based review, knowledge transfer, and modernization work.
RPG Is Rarely Just RPG
One of the challenges with applying AI to IBM i development is that the source member in front of you is rarely the whole system.
A business process may involve:
-
RPG programs and service programs
-
Db2 for i tables and views
-
SQL procedures
-
CL
-
Job descriptions
-
Batch processing
-
Data queues
-
External integrations
-
Operational procedures
-
Training material
-
Troubleshooting documentation
-
Years of coding and naming conventions
-
Business rules that were never formally documented
The most important layer may be business knowledge itself.
Some of that knowledge is visible in the source. Some is buried in database relationships or operational documentation. Some is understood by support teams because they have seen the same problem repeatedly. Some still lives with experienced developers who remember why a particular piece of logic exists.
An AI assistant cannot reason correctly about context it does not have.
A technically reasonable answer can still be the wrong answer for the application.
That principle has shaped how I use Bob.
Giving Bob More Than One Program
One of the first things I did was move beyond isolated code questions.
I gave Bob broader access to the application codebase so it could reason across programs and related components instead of examining one procedure in isolation.
That changes the kinds of questions you can ask.
Instead of only asking what a procedure does, you can begin asking:
-
Where else is this behavior used?
-
What other programs appear to depend on this structure?
-
Where is this field referenced?
-
Which programs participate in this workflow?
-
Where might a change have consequences elsewhere?
The resulting answers still need review, and Bob can still make assumptions or miss context that is not present.
But broader application context gives it a much better opportunity to reason about the application as a system rather than as a collection of unrelated source members.
For mature IBM i applications, that distinction matters.
Context Matters More Than Clever Prompting
A great deal of AI discussion focuses on writing better prompts.
Prompting matters, but in my experience context often matters more.
If I ask Bob to review one procedure while an important validation happens somewhere else in the application, the resulting answer may look reasonable and still be incomplete.
If a field has a business meaning that is not obvious from its name, Bob may infer something logical that is still incorrect.
If an older programming pattern exists because of an operational requirement that is invisible in the code being reviewed, an AI assistant may recommend removing behavior the business depends on.
Using AI effectively therefore requires developers to think not only about the question being asked, but also about the information the assistant needs in order to answer responsibly.
That becomes especially important in long-lived applications, where unusual-looking logic may be obsolete—or may represent years of accumulated business behavior.
Using Development Standards to Improve Review
Another step was giving Bob our development standards and using those standards to build reusable Bob skills around the way we expect software to be engineered.
This moves the interaction beyond generic programming advice.
A recommendation can be technically valid while still violating standards a team has deliberately chosen for architecture, naming, database design, service boundaries, testing, or code review.
Giving Bob those standards gave it a better frame for evaluating work against the engineering practices we actually use.
The team still owns the standards. Bob simply becomes another mechanism for applying them consistently.
That became particularly useful during database table reviews.
When Bob Found Something Human Review Missed
During database table reviews, I used Bob as an additional reviewer against table definitions and our development standards.
It surfaced issues that had survived previous human reviews, including:
-
Foreign keys referencing tables that did not exist
-
Duplicate short column names
-
Other inconsistencies against expected database standards
These were concrete findings that warranted investigation.
The easy but wrong conclusion would be that Bob somehow became better than the DBAs.
That is not what happened.
The value was that Bob provided another systematic pass across the definitions and standards without carrying exactly the same assumptions human reviewers naturally develop.
Experienced engineers and DBAs still had to validate the findings, understand the consequences, and decide whether anything should change.
Bob did not replace the reviewer.
It strengthened the review process.
The more useful question is whether AI can help an expert reviewer find something they otherwise might have missed.
In this case, it did.
Turning Scattered Knowledge Into Developer Knowledge
Another use of Bob has been particularly useful for knowledge transfer.
For one application workflow, I gave Bob context that included:
-
The relevant codebase
-
Existing training material for the workflow
-
Job logs associated with that workflow
-
Existing troubleshooting documentation
Each source told part of the story.
The code showed how the application was implemented. Training material described how the workflow was expected to operate. Job logs provided evidence of what happened during execution. Troubleshooting documentation captured accumulated operational experience.
I used Bob to bring those sources together and help create new documentation for developers learning the workflow.
This expands the idea of AI-assisted development beyond coding.
Bob was helping connect:
implementation → expected behavior → operational evidence → troubleshooting experience
Many mature applications do not have a complete absence of knowledge.
They have a knowledge distribution problem.
The information exists, but it is spread across source code, training documents, runbooks, logs, troubleshooting notes, and experienced people.
If AI can help bring those pieces together, it can materially improve onboarding and knowledge transfer.
For IBM i teams dealing with retirements, developer turnover, modernization, or simply decades of accumulated system history, I think this may become one of the more valuable uses of AI.
There is still an important guardrail.
Generated documentation cannot automatically become authoritative because it was assembled from authoritative inputs. Someone who understands the workflow must still review it, verify relationships, challenge assumptions, and look for missing context.
AI can help assemble the map. Engineering still has to determine whether the map matches the territory.
AI Can Suggest. Engineering Still Decides.
One of the easiest AI-assisted development workflows is also one of the most dangerous:
Prompt → generate → accept
That is convenient, but it is not an engineering process.
The workflow I prefer is:
Understand → constrain → ask → inspect → test → validate
Understand the problem first.
Establish the constraints.
Provide the assistant with appropriate context.
Ask it to explain, analyze, review, or propose an approach.
Inspect what it produces.
Test it.
Then validate the result against the behavior the system actually requires.
That keeps AI inside the engineering process instead of allowing AI to become the engineering process.
AI can accelerate analysis, documentation, review, and implementation.
But accelerating the wrong assumption only gets you to the wrong answer faster.
Why This Matters for IBM i Modernization
IBM i modernization is often described as a technology problem:
Those things matter.
But modernization fails when teams change implementation without understanding behavior.
A cleaner program that implements the wrong business rule is not modernization. It is simply a cleaner defect.
This is where AI-assisted development becomes especially interesting.
The bigger opportunity is to use AI to help developers:
-
Understand existing behavior
-
Trace dependencies
-
Review code and database definitions
-
Apply engineering standards consistently
-
Identify candidates for modernization
-
Improve documentation
-
Transfer application knowledge
-
Examine proposed changes
-
Support developer onboarding and training
That changes the modernization conversation.
Instead of beginning with, “What should we rewrite?” we can spend more time answering better questions:
What do we actually have?
Why does it behave this way?
Where are the boundaries?
What knowledge is embedded here?
What can safely change?
Where IBM i Teams Should Be Careful
I am increasingly optimistic about what AI-assisted development can do on IBM i, but that optimism needs discipline.
Do not confuse confidence with correctness
AI-generated explanations can sound authoritative even when important context is missing.
Read the explanation, then prove it.
Understand before you modernize
AI can accelerate a bad assumption just as easily as a good one.
Understanding should come before transformation.
Keep architectural decisions with the engineering team
An assistant can suggest alternatives.
Engineers still have to account for operational constraints, security, performance, maintainability, deployment realities, team capability, and organizational standards.
Treat generated documentation as a starting point
AI can produce useful explanations and documentation, but the result still needs technical review before it becomes trusted engineering material.
Keep teaching developers IBM i
AI does not reduce the value of platform knowledge.
It increases it.
The developer who understands RPG, Db2 for i, libraries, jobs, service programs, data flow, application architecture, and production behavior is much better equipped to recognize when an AI-generated answer does not fit the real system.
What I Would Tell an RPG Team Starting With Bob
If another IBM i team asked me how to begin, I would not start with the most ambitious use case.
Start with something the team already understands.
Choose a piece of code your experienced developers know well. Give Bob enough context to reason about it. Ask questions and compare Bob's answers with what the team knows to be true.
Pay attention to where it performs well, but pay even more attention to what it misses.
Then improve the context and repeat the exercise.
Once you understand how Bob behaves with your code, introduce your development standards.
Use it as an additional reviewer.
Try it on documentation and knowledge-transfer problems.
Use it to help trace a workflow across multiple components.
Only then move toward increasingly complex development and modernization work.
The initial goal should not be maximum productivity.
The goal should be calibration: understand where the tool deserves trust, where it needs supervision, what context improves the result, and where experienced developers need to take control.
That calibration is what eventually creates productivity.
Experienced Developers Still Matter
There is a recurring idea in parts of the AI conversation that as AI becomes more capable, experience becomes less valuable.
On IBM i, I think the opposite may be true.
Experienced developers know which questions to ask.
They recognize suspicious answers.
They understand production consequences.
They know that two pieces of code that appear functionally equivalent may not be operationally equivalent.
They know which strange-looking routines are technical debt and which ones represent business rules that nobody documented twenty years ago.
AI may also provide a better way to transfer some of that experience.
If we can combine code, standards, training material, troubleshooting information, logs, and experienced review into better explanations and documentation, we may be able to shorten the time it takes for the next developer to understand the application.
Someone still has to recognize when the answer does not fit.
That is engineering judgment.
Final Thoughts
Working with IBM Bob has made me more interested in AI-assisted development on IBM i, but not because I believe the future is simply about generating RPG faster.
The opportunity is broader.
Bob can help reason across more than one program, work against engineering standards, provide an additional review layer, expose issues that survive normal review, connect source code with operational and training knowledge, and help turn scattered institutional knowledge into something another developer can use.
For mature IBM i environments, those capabilities may ultimately matter more than code generation.
The disciplined engineering workflow still applies. Bob can help us move through it more effectively, but it should never give us permission to skip validation or hand off responsibility for the result.
The real opportunity with AI-assisted development is not to remove judgment from IBM i engineering.
It is to give engineers another way to understand, review, document, and improve the systems they are responsible for while keeping judgment where it belongs—with the engineer.
I would be interested in hearing how other IBM i teams are using IBM Bob.
Has Bob found something your normal review process missed, improved your understanding of an existing application, or helped you consolidate knowledge that was previously scattered across several places?
Share your experience in the comments.
#community-stories2