Skip to Main Content

After the TechXchange Buzz: Where Project Bob Fits in Your IBM i Modernization Strategy

The energy at IBM TechXchange in Orlando a couple of weeks ago was incredible. With around 10,000 people, it was the largest TechXchange I’ve ever attended. The Champions Day alone brought together about 700 of us, a sea of blue jackets and a fantastic opportunity to network. But from the moment the opening keynote started, one topic dominated the conversation: Project Bob.

The buzz was immediate and intense. As I moved from sessions to the massive Sandbox Expo area, everyone was talking about it. When I finally got to the hands-on lab, I saw my audience from my own modernization session drifting away to get their first look. The excitement was palpable.

Now that the dust has settled, I want to share my perspective on what Project Bob is, where it excels, its current limitations, and how it fits into a practical IBM i modernization strategy.

What is Project Bob? And What Isn’t It?

Project Bob is IBM’s new AI-powered code assistant, built as a fork of Visual Studio Code (VS Code). It’s designed to help IBM i and mainframe developers write, understand, and refactor RPG code more efficiently by bringing modern productivity tools directly into the developer’s workflow.

As highlighted in Alex Woodie’s IT Jungle coverage, Bob represents IBM’s most significant move yet toward embedding AI in day-to-day development environments, offering a familiar and approachable interface for both RPG and System z COBOL programmers.

For anyone familiar with modern Integrated Development Environments (IDEs), some of Bob’s features will feel familiar: predictive text, syntax correction, and case sensitivity. However, Bob aims to go further by using generative AI to explain code, suggest improvements, and even generate new RPG code from simple prompts. During a lab at TechXchange, I saw firsthand how you can input a block of RPG code and ask Bob to explain what it does in plain English. Your code appears on the left, and a chat pane on the right shows Bob’s explanation, which is a great feature for getting up to speed on unfamiliar or legacy code.

That said, it’s important to be clear about what Project Bob does not do. It is not an IBM i application modernization or system analysis tool. It works at the code snippet level, helping individual developers with specific tasks. It won’t map your application’s procedural flow, generate entity-relationship diagrams, or reveal system dependencies. Instead, think of Bob as a powerful assistant at the developer level—great for productivity and learning, but not a replacement for broader modernization or analysis tools.

Where Project Bob Shines for Developers

Based on my hands-on experience at IBM TechXchange, Bob shows real promise in three key areas of developer productivity:

  1. Code Explanation and Understanding
    Bob has a solid grasp of RPG (including old fixed-format and System/36 code), CL, and DDS. You can highlight a section of code and ask it to explain the logic. This is incredibly useful for developers new to a particular program or for those tackling decades-old, complex code without the original author around to ask. It helps bridge the knowledge gap. A big tick for IBM and Project Bob.
  2. Code Generation from Plain English
    In the lab, we gave Bob a simple instruction: “Write me an RPG program that validates US telephone numbers.” Bob understood the request, knew the structure of a US phone number, and generated a functional code snippet, complete with error handling. This ability to translate natural language into code can be a significant time-saver for routine tasks.
  3. Code Refactoring (with Limits)
    Bob can take older, fixed-format RPG and convert it to modern free-format RPG. This is a big step for improving code readability and maintainability. The large language models it uses, primarily from Anthropic, have been trained extensively on IBM i languages. However, its translation capabilities are currently limited to RPG-to-RPG conversions.

Bob also has built-in guardrails. It operates in different modes, allowing you to approve its suggestions before any changes are made to your source code. If you ask it about a non-existent RPG op-code, it won’t “hallucinate” an answer; it will simply state that it doesn’t understand. This controlled, predictable behavior is crucial for enterprise development.

The Practical Gaps: Availability, Scale, and Cost

While the direction is promising, several realities temper the immediate excitement around Project Bob.

  • Availability: Bob is not generally available today. IBM has positioned this as an early look, with general availability not expected until well into next year. For teams with immediate modernization needs, it’s a risky waiting game. Whilst IBM seem committed, they just withdrew two other tools, MERLIN and Watson Code Assistant for i, with little advance warning.
  • Scope: As mentioned, Bob is a developer productivity tool, not a system-level solution. It won’t give you an entity-relationship diagram of your database or map the procedural flow of an entire application. Its visualizations are limited to text-based outputs. Admittedly, these can be visualized using tools like Mermaid diagrams, but these lack the interactivity of dedicated analysis tools.
  • Collaboration and Cost: Bob operates within a single developer’s workspace. This raises questions about team collaboration. If two developers ask Bob to explain the same piece of code, are you paying for the same analysis twice? The pricing model is still unclear. Since Bob orchestrates third-party services from Anthropic, usage will likely consume tokens, but how that cost is managed, governed, and passed on to customers remains an open question.

As previously mentioned, IBM’s announcement also came with the retirement of the Watson Code Assistant for i and MERLIN, making Bob their clear strategic direction. This is a positive consolidation, but it also highlights that the tool is still evolving.

AI in IBM i Modernization: The Right Tool for Each Job

At Fresche, we see AI-driven development as a multi-layered stack, and tools like Project Bob have a clear and valuable role to play. But they’re just one piece of a much larger puzzle.

In my experience, true application modernisation always starts with deep application understanding. Before you can refactor or rewrite anything, you need to know how your systems work. This is where a tool like Fresche’s X-Analysis AI comes in, providing system-wide analysis, procedural flow mapping, and database diagrams that a code-level assistant simply can’t.

With that foundation, you can move on to the heavy lifting of transformation. This is the job for our X-Modernize AI engine. It’s designed to modernize complete applications, not just isolated code fragments. And crucially, our approach goes beyond RPG-to-RPG conversion. We focus on transforming legacy code into maintainable, production-ready Java. Why Java? Because it opens the door to a far larger pool of developer talent and helps ensure your applications stay adaptable and relevant.

This is where a tool like Project Bob fits perfectly—as the “last mile” accelerator. Once our Application Modernization Factory automates the bulk of the modernization, developers still need to perform the final integration, testing, and refinement. An AI coding assistant can dramatically speed up this phase, giving developers the productivity boost they need to finish strong.

When each layer of the process is handles by specialized, purpose-built tools, teams reduce risk, gain speed, and set themselves up for sustainable modernization that lasts.

A Quick Checklist for Evaluating Your AI Modernization Strategy

As you consider tools like Project Bob, ask yourself these questions:

 

  1. What is my primary goal? Am I trying to make my current developers more productive (developer tool), or am I trying to modernize an entire application to a new language or architecture (system modernization)?
  2. Do I have a deep understanding of my application? Can I see all the dependencies, data models, and business logic flows before I start changing code?
  3. What is my talent strategy? Is my goal to write better RPG, or is it to open my systems to a much larger pool of Java or other modern-language developers?
  4. What is my timeline? Do I need a solution that is available and proven today, or can I wait for a new tool to become generally available?
  5. How will I manage cost and governance? Do I have a clear plan for controlling the costs associated with token-based AI tools across my development team?

 

Choose the Next Right Move

IBM’s investment in Project Bob is a fantastic signal for the IBM i community. It validates the importance of developer productivity and brings modern AI capabilities directly into the hands of RPG programmers. It will help developers write better code, faster.

However, boosting developer productivity is not the same as executing a comprehensive modernization strategy. True transformation requires starting with a deep, holistic understanding of your applications and having a plan to move them toward a more sustainable, future-proof architecture.

We see a future where tools like X-Analysis, X-Modernize AI, and Project Bob work together, each playing a critical role at different stages of the journey—from system-wide analysis to automated transformation to last-mile developer assistance. The buzz from Orlando was justified, but now the real work begins.

If you’d like a quick, practical conversation about your modernization roadmap, I’m always happy to help.

Let's Connect >>

 


Frequently Asked Questions (FAQ)