There are things IBM i developers do every single workday that consume hours and produce no visible output, like reading code no one documented, reviewing changes with no real context, writing boilerplate SQL that looks identical to every other query. IBM Bob doesn't solve IBM i modernization. It changes who carries the weight of it.
If you've read IBM's official materials on Bob, you've seen the architecture diagrams, the Bobcoin pricing tables, and the phrase "AI development partner" used approximately forty times. None of that tells you what every day's struggle looks like when you're an RPG developer staring at a fixed-format program someone wrote in 1997.
That's what we are trying to explain here, not what Bob can do in theory, what it changes in practice, inside an IBM i shop, for the teams who actually live in QSYS and ILE RPG and Db2 for i every day.
"The greatest cost in iSeries modernization isn't rewriting code. It's the hours senior developers spend reading code they didn't write, in a language the rest of the industry stopped teaching twenty years ago."
7 Places You Can Put IBM Bob to Work in Your IBM i Workflow Today
Below, we have grouped the everyday IBM i tasks where Bob makes a measurable difference:
#1: Understands What a Legacy Program Actually Does
Every IBM i shop has programs that are essentially institutional memory written in fixed-format RPG.
With little documentation, limited comments, variable names that made sense to someone twenty years ago, and the original developer long retired, every new change request starts with the same challenge: understanding the program before making any real development changes.
That usually means reading the code forward and backward, checking file definitions, tracing indicators, reviewing subroutines, and trying to reconstruct business intent from behavior. This is not development time. It is orientation time.
IBM Bob is useful here because it can explain legacy IBM i code in plain English.
A developer can paste a fixed-format RPG program into Bob and ask:
What does this program do? What files does it read and write? What are the business rules embedded in it?
Bob can return a walkthrough that explains:
- File inputs and outputs
- Key data transformations
- Conditional logic
- Indicator usage
- Embedded business rules
- Hardcoded values
- Areas that need closer review
This is where IBM Bob's AS/400 RPG fluency matters. A generic AI assistant may read syntax, but IBM Bob is designed with IBM i context, including RPG semantics, indicator logic, RPGLE patterns, Db2 for i usage, and common platform-specific development practices.
The benefit is not that Bob magically understands your business. The benefit is that it gives the developer a faster starting point. A task that once took 45 minutes of code reading may now take a few minutes of guided explanation, followed by developer validation.
Before touching any unfamiliar RPG, COBOL, or CL program, run it through Bob first. Use the explanation as a documentation baseline, review it, and commit the refined version to source control. The next developer who opens that program should not have to start from zero.
#2 Code Review That Checks What Reviewers Often Miss
In many IBM i shops, code review depends heavily on experienced developers. That creates a bottleneck. The people best qualified to review the code are also the busiest people on the team.
There is also another problem. Manual review often focuses on whether the code works and whether the business logic looks right. Security, authority handling, SQL patterns, and platform-specific risks may not get the same level of attention, especially when the review queue is long.
IBM Bob can improve the pre-review process.
Before a developer submits code for human review, they can run it through Bob to identify issues such as:
- Hardcoded credentials in CL programs Passwords, API keys, and sensitive values embedded in procedures can be flagged before they reach production.
- SQL injection risks in SQLRPGLE Dynamic SQL built from concatenated user input is common in older codebases and easy to miss in a visual review.
- Authority gaps in Db2 object access Bob can highlight programs that adopt authority unnecessarily or access objects without the right checks.
- Dead code in modernization candidates Unused subroutines, old indicators, and unreachable logic can be identified before a modernization sprint begins.
A senior developer reviewing someone else's code at the end of the day can miss things. Bob does not replace that reviewer, but it can catch issues before the code reaches them.
There is one important governance point. IBM Bob should not be treated as an autonomous production reviewer. Any action that writes files, compiles code, executes commands, or changes source should still require human approval. If your team uses Bob in review workflows, keep approval policies explicit and avoid broad "always allow" settings for sensitive actions.
Use Bob as the first filter before human review. Let Bob catch common security and refactoring issues, then let senior developers focus on business logic, design quality, and edge cases.
#3 Writes New IBM i Code Without Missing Platform Context
Writing new code on IBM i requires more than knowing general programming concepts.
A developer has to understand RPG IV conventions, embedded SQL, Db2 for i behavior, activation groups, commitment control, authority implications, journaling, and how the code will behave inside the IBM i runtime environment.
A developer who is strong in general programming but newer to IBM i may produce code that works, but is not fully aligned with platform expectations.
This is where IBM Bob can act as a platform-aware assistant.
For example, a developer can ask Bob to write a service program procedure that retrieves customer orders by date range using embedded SQL, handles not-found conditions, and returns a data structure array.
A stronger IBM i-aware first draft should consider:
- Proper SQLCOD or SQLSTATE handling
- Set-based processing where appropriate
- Cursor management
- Db2 for i performance considerations
- Commitment control awareness
- Service program structure
- Exported procedure conventions
- Error handling comments where human review is needed
The value is not that the generated code can be copied blindly into production. It cannot. The value is that the first draft starts closer to IBM i best practices than a generic output would.
For teams with mixed experience levels, this matters. Senior IBM i developers do not have to personally guide every line of new code. Bob can help less experienced developers get to a better starting point, while senior developers still review the final logic.
Use Bob for first drafts of service programs, SQLRPGLE modules, CL procedures, wrappers, and repeatable IBM i development patterns. Treat the output as a starting point, not a final deliverable.
#4: Fixed-Format to Free-Format RPG Conversion
If your organization is modernizing IBM i applications, fixed-format RPG conversion is probably somewhere in the backlog.
Converting fixed-format RPG III or RPG IV to free-format ILE RPG is often tedious. It is also more complex than simple syntax replacement. Indicators, result fields, subroutines, GOTO logic, and older operation codes require judgment.
IBM Bob can help by handling much of the mechanical first-pass conversion.
A developer can ask Bob to:
- Convert fixed-format RPG to free-format ILE RPG
- Replace cryptic indicators with meaningful variable names
- Convert older control flow into structured logic
- Replace record-level access with SQL where appropriate
- Flag conversion areas that need human review
This last point matters. A useful AI assistant should not silently produce risky code. It should identify where the conversion is uncertain and where a developer needs to validate business logic.
The goal of RPG modernization is not simply to reach free-format syntax. The real goal is to make the code easier for the next developer to read, maintain, and safely extend.
For managers, this changes how modernization work can be staffed.
If Bob can handle the mechanical 70% of a conversion, senior RPG developers can spend more time on the 30% that actually requires judgment:
- Business rule verification
- Edge case review
- Integration testing
- Performance validation
- Regression planning
That is a better use of experienced IBM i talent than asking them to manually rewrite every line.
In a modernization sprint, let Bob generate the first-pass free-format conversion, plus a short architecture note and a list of areas needing review. The senior developer then reviews, corrects, tests, and commits. The output still needs ownership, but the starting point is much stronger than a blank file.
#5: AS/400 Migration Planning Starts with Documentation
Many AS/400 migration to cloud and modernization projects run into the same issue. The obstacle is not always technical feasibility. It is understanding the current estate.
Before deciding whether to move workloads to Power Virtual Server, expose IBM i logic through APIs, containerize surrounding services, or rebuild parts of the application, teams need to know what the current system actually does. That is often the hard part.
Business logic is often buried inside RPG subroutines, while CL procedures quietly orchestrate important workflows, program dependencies remain undocumented, and data relationships exist in the database without being reflected in any current diagram.
IBM Bob can help turn that scattered understanding into usable documentation, making the current estate easier to read, assess, and plan against.
At the program level, Bob can help produce:
- Plain-English descriptions of program purpose
- Inputs and outputs
- Business rules
- File and table usage
- Program dependencies
- Data flow summaries
- Potential modernization risks
It can also support migration planning by helping teams understand how existing programs interact and where business logic is concentrated.
For large estates, Bob should be paired with portfolio-level analysis tools. Bob works best at the code and program level. It is not designed to automatically map thousands of programs across an entire object library or identify every business-critical dependency at system scale.
Tools such as ARCAD Observer or Fresche X-Analysis AI can support broader estate-level analysis. Bob is complementary to those tools. It helps developers and architects understand code-level detail once the modernization candidates are identified.
Use Bob to generate program-level documentation for high-priority modernization candidates before architecture planning begins. This makes migration discussions more grounded and less dependent on undocumented assumptions.
#6 COBOL Modernization with Enterprise Context
COBOL modernization is a crowded space. Many AI vendors claim they can analyze, convert, or refactor COBOL.
What makes IBM Bob relevant for IBM i teams is the enterprise context it brings into the modernization workflow.
For regulated industries running COBOL on IBM i, including healthcare, insurance, financial services, and government, modernization cannot ignore compliance, auditability, and human checkpoints.
A useful COBOL modernization workflow needs to do more than generate refactored code. It should help teams:
- Explain the business logic
- Identify security concerns
- Propose a cleaner structure
- Improve variable naming
- Generate unit tests
- Keep a record of what changed and why
- Ensure humans approve the right steps
Bob's approach is useful when it supports this controlled process. It can read a COBOL program, explain what it does, suggest refactoring options, flag risk areas, and generate test skeletons. If the workflow includes an audit trail of actions, teams have better documentation for what was changed, why it changed, and how it was reviewed.
For regulated organizations, that matters. A modernization tool that cannot satisfy security and compliance teams is unlikely to make it past architecture review.
Use Bob for COBOL explanation, refactoring preparation, security review, and test generation. Keep human checkpoints active, especially for regulated workloads.
#7 Documentation as a Continuous Byproduct
IBM i documentation is often weak because it is treated as a separate task from development, which means that when teams are under pressure, the code gets fixed, the change gets deployed, and documentation is pushed to "later," where it often stays.
IBM Bob can help change that pattern by making documentation part of the same workflow in which code is reviewed, modified, or modernized.
When code is generated, reviewed, converted, or modified in a Bob session, the same session can also produce:
- A plain-English program summary
- An architecture note
- A data flow explanation
- A list of files and tables used
- A summary of changes made
- Risks or assumptions that need review
- Test cases or test coverage notes
Documentation becomes part of the development workflow instead of a separate cleanup task.
For IBM i shops with aging codebases and high knowledge concentration risk, this is one of the most valuable uses of Bob. The "one person who understands that program" problem becomes less dangerous when each code change adds a little more documentation back into the estate.
Over time, this creates a more readable, reviewable, and maintainable IBM i environment.
Require documentation output for every Bob-assisted change session. Store it with the code, not in a disconnected folder where no one will find it later.
What IBM Bob Cannot Do Yet and Why It Matters
IBM Bob has practical value, but it also has limitations that managers should understand before introducing it into daily IBM i workflows.
- It needs source access through the developer workflow Base Bob 1.0 requires source to be available on the developer's workstation. It cannot directly read source from QSYS source physical files or the IFS. Until IBM i Developer Mode or the Premium Package for i adds deeper system connectivity, teams need to pull source locally or into Git before working with Bob.
- It works at the program level, not the estate level Bob can explain, review, and improve the RPG, COBOL, CL, or SQLRPGLE program you open. But it cannot scan thousands of programs across the IBM i estate and tell you which applications should be modernized first, which ones should be retired, or which ones carry the highest business risk.
- It cannot determine business criticality from code alone A payroll program, claims adjudication program, and monthly reporting program may look similar from a code-analysis perspective. But their failure impact is completely different. Business criticality depends on operations, compliance, users, timing, and downstream impact, not just source code.
- It does not replace dependency mapping IBM i systems are usually connected through call stacks, shared files, service programs, data queues, user spaces, batch jobs, and long-running operational routines. Bob can help explain one program, but it cannot fully map the system-wide dependency chain across the entire object library.
- It cannot own modernization sequencing Bob may help modernize a single program, but it cannot decide whether that program should be changed before or after related programs, which releases should be bundled, what rollback plan is needed, or what business teams must sign off.
- It requires active security governance Any AI tool with agent-like execution capabilities needs controls. Teams should avoid broad auto-approval for arbitrary commands. Any action that compiles, writes, deletes, executes, or modifies files should require human review.
- It is not a substitute for IBM i professionals Bob can reduce orientation time, help newer developers understand legacy code faster, and extend the reach of senior developers. But final judgment still belongs to people who understand IBM i, the business logic, the operational process, and the risk of getting it wrong.
Where to Start: A Small Experiment You Can Run This Week
The most common mistake organizations make with AI development tools is turning adoption into a large project before anyone has tested the tool on real work.
What starts as a simple evaluation quickly becomes a procurement discussion, a governance review, a training plan, and then a formal pilot, until the whole effort becomes heavier than it needs to be.
A better approach is to start smaller. Pick one senior RPG developer, give them access to the 30-day free trial with 40 Bobcoins and no credit card required, and ask them to spend one morning using Bob on three practical tasks from their actual workload:
- Explain a legacy program that only they understand
- Review a recent code change for IBM i-specific security issues
- Generate documentation for one RPG or COBOL module that currently has none
Then ask one question:
What would you have done differently in yesterday's code review if you had this?
That answer is your business case.
Not the vendor benchmark. Not the generic productivity claim. The real value is in the hours your best developers stop spending on work that should not require them.
Final Takeaway
Bob cuts a significant amount of the manual weight that IBM i teams carry every day. That is genuinely useful. But a tool that accelerates execution cannot substitute for knowing what to execute. The sequencing decisions, the risk calls, the dependency questions, the compliance considerations...you can't fathom them using any AI tool.
They live in experience, specifically, in the kind of experience that only comes from having worked across enough IBM i environments to know where things go wrong, why modernization programmes stall, and what it actually takes to move an AS400 estate forward without breaking what the business depends on.
With 15+ years of helping organizations run, maintain, and modernize IBM i systems, we have learned that no single tool, however capable, replaces a clear strategy, the right sequence of decisions, and people who have seen enough AS400 environments to know what works and what does not.
If you are thinking about where your IBM i estate needs to go next, let's talk. Book a 30-minute strategy call with our experts and walk away with a clearer picture of your options, your risks, and your next move.
