IBM introduced IBM Project BOB at TechXchange 2025 as “an AI software development partner that understands your intent, repository, and security standards.” Positioned as an agentic AI tool, Bob aims to bring modernization expertise directly into developers’ daily workflows.
It’s a useful and desirable promise, but only if it holds up outside curated demos.
That is the lens Uwe Graf brought to his early evaluation of IBM Bob.
In enterprise mainframe environments, reality looks different than instant modernization. Mission-critical systems still rely on COBOL, PL/I, Assembler, REXX, and JCL. Any AI tool meant to support modernization must prove it can operate effectively inside decades-old codebases, established workflows, and real operational constraints.
Rather than testing idealized Java scenarios, I focused deliberately on legacy languages and real-world tasks: maintenance, refactoring, analysis, and learning scenarios that reflect day-to-day mainframe development. As someone who also trains new mainframe professionals, I evaluated Bob not only for its productivity gains but also for its educational value.
Getting Started: Installation and First Signals
Installation matters as much — or more — than functionality. In enterprise environments, tooling friction can determine whether a product is adopted or quietly sidelined.
I installed IBM Bob cleanly and without incident. In a landscape where developer tools often arrive with complex dependencies and configuration hurdles, this was a strong positive first impression. Integration into Visual Studio Code felt natural, allowing Bob to operate as part of the existing workflow rather than as a separate destination that required context switching.
One open question remained around model flexibility. It was not immediately clear to me how easily alternative language models could be configured or compared. For teams that intentionally evaluate model behavior and output differences, greater transparency here would be beneficial. Even so, the default experience aligned well with how many development teams operate in practice.
Legacy Languages Remain Central
Why this matters in real environments
While Java frequently dominates AI tooling demonstrations, the real value of IBM Bob lies in its support for legacy languages. COBOL, PL/I, Assembler, REXX, and JCL continue to power the core business logic of many enterprises. Tools that help developers read, understand, and modernize these languages address an ongoing and very real need.
Bob’s ability to perform structural and complexity analyses across large, historically grown codebases proved useful. Metrics such as McCabe or Halstead complexity provided helpful orientation when assessing legacy systems. Identical code occasionally produced slightly different complexity values depending on context. This was not a critical issue, but it is worth considering when using such metrics for planning or prioritization.
Productivity in Everyday Development
Refactoring without losing intent
IBM Bob shows clear strengths in day-to-day maintenance work. With well-formulated prompts, refactorings and structural improvements can be initiated efficiently. Code becomes more readable and better organized without requiring manual, line-by-line restructuring.
In environments where change requests are frequent and often time-sensitive, this assistance translates directly into productivity gains. Developers can focus more on intent and correctness rather than mechanical cleanup.
There are still areas for improvement, though. During COBOL refactorings, Bob occasionally defaults to older control-flow constructs, such as jumping to the end of a SECTION using a GO TO. While technically correct, this does not align with modern COBOL best practices. Support for explicitly targeting specific compiler versions or language standards would further improve output quality.
PL/I and Assembler: Solid Handling
PL/I support was consistently strong. Even complex programs shaped by decades of accumulated style variations were handled with care. Proposed changes remained structured, understandable, and respectful of the language’s characteristics. For teams maintaining PL/I applications, this capability represents a meaningful advantage.
Assembler support stood out in particular. Assembler code often includes historically motivated constructs that remain functional but difficult to read and maintain. IBM Bob frequently suggested cleaner, more modern alternatives. Replacing older patterns with clearer instruction sequences improved readability without altering behavior.
I also experimented with converting selected Assembler routines into COBOL. The results were surprisingly usable, provided the code avoided deeply system-specific instructions. The limitations here were expected and did not diminish the tool’s overall value.
REXX: Extensive Experience, Strong Results
I have extensive hands-on experience with REXX, both in production environments and in training scenarios. IBM Bob performed very well in these areas. Refactored REXX scripts were clearer, more consistent, and easier to maintain.
Scripts that had grown organically over many years benefited most from restructuring and clarification. Improved readability in REXX is not merely cosmetic. In many environments, these scripts play a critical role in automation and operational stability.
JCL and Its Importance for Learning
Explanation beats generation
I found one of the most compelling aspects of IBM Bob was its approach to JCL. In training environments, a familiar pattern emerges: beginners learn to write syntactically correct JCL, but they struggle to understand why jobs are structured the way they are.
IBM Bob addresses this gap by prioritizing explanation over generation. Job steps are described by purpose. DD statements and parameters are placed into a functional context. Dependencies between jobs, datasets, and programs become easier to follow.
“Users can ask [Bob] questions in natural language and receive explanations that support understanding. This makes a significant difference for newcomers.”
Existing jobs become easier to analyze, and new jobs can be built with greater confidence. The pressure to memorize every rule upfront decrease, while comprehension improves. Bob cannot replace foundational JCL training. Instead, it reinforces learning by accelerating understanding and lowering initial barriers.
A Necessary Reality Check
As expected, IBM Bob does not replace domain knowledge or professional responsibility. It cannot fully capture business context, historical design decisions, or organizational constraints. This distinction matters, especially in environments where systems have evolved over decades and support critical business functions.
These remain firmly in the hands of experienced developers.
“The tool supports analysis, explanation, and acceleration. It does not make architectural decisions or validate business correctness.”
Final Thoughts: Productivity and Education Combined
IBM Bob stands out to me for addressing two essential needs at once:
- It improves productivity in daily development and maintenance work.
- It supports learning by helping people understand code rather than just manipulating it.
For organizations maintaining large legacy portfolios, this combination carries strategic value. Making existing systems more approachable while enabling new talent to become productive faster strengthens long-term resilience.
“IBM Bob works because it amplifies what skilled mainframe professionals already do.”
This is not about replacing expertise with automation. It is not about surrendering judgment to AI. IBM Bob works because it amplifies what skilled mainframe professionals already do: analyze, interpret, and improve complex systems responsibly.
For me, IBM Bob represents a meaningful step forward in how agentic AI can support real modern mainframe development — without losing sight of human accountability.
0 Comments