Project Bob, VS Code, and the Future of IBM i Development: What Managers Should Prepare For

☕ Today’s Coffee: Starbucks Single-Origin Sumatra Dark Roast

Deep, earthy, and unshakably bold. The kind of roast that wakes you up and reminds you that something big is changing — whether you planned for it or not. That’s where the IBM i development world stands today.

For years, modernization meant “rewrite everything,” “move off RPG,” or “bolt a web UI onto the same old logic.” But now, we’re facing a genuine evolution — not of the platform, but of how we work on the platform.

Project Bob is not just another editor.
It’s not a plugin.
It’s not another modernization promise that requires a six-month training program.

Bob is the beginning of a new era.

And the teams that prepare now will lead the decade ahead.

Project Bob: The First Real Leap Forward in IBM i Development

Project Bob is IBM’s new AI-powered IDE built for RPG developers.
This matters. For decades, IBM i developers have lived in a split world:

Modern tooling on distributed systems
Aging tooling on the host
And a patchwork of enhancements trying to close the gap

Bob closes it for the first time.

The Three Things That Make Bob a Breakthrough

1. It’s a fork of VS Code

Not a plugin.
Not an overlay.
A full-blown fork — meaning:

All the performance
All the extensibility
All the modern workflows
All the UI polish
All the integrations

And then re-engineered for IBM i.

This puts RPG developers on equal footing with modern development ecosystems.

2. It understands your IBM i codebase like a team member

Bob can interpret:

RPGLE
SQLRPGLE
CL
DDS
SQL DDL
Service programs
Modules
Data flows
Dependencies
Errors
Git history
Taggable context

That’s more understanding than most developers have when they first join a project.

3. It doesn’t just describe problems — it solves them

This is the AI leap.

Bob can:

Break big tasks into steps
Produce modernization plans
Rewrite fixed-format RPG
Generate unit tests
Build documentation
Create ER diagrams
Suggest refactors
Ask for clarification
Validate assumptions
Enforce standards
Create proof-of-concepts
Review code
Predict impacts

This is not autocomplete.
This is a co-developer.

Modernization Without Fear: Why Bob Matters to Leadership

Most modernization fails not because of tools — but because of developer psychology.

Your senior developers have spent 20, 30, even 40 years building mastery in RPG, CL, and DDS. Their value comes from experience, intuition, and knowing the system’s history better than any documentation ever could.

Bob doesn’t replace that.
Bob amplifies it.

And that is the shift managers must learn to lead.

When people fear change, they resist it.
When people trust the change, they embrace it.

Bob is an opportunity to rebuild trust in modernization.

Workflows That Will Disappear (and Why That’s Good)

Let’s address reality: some workflows we’ve depended on for decades will fade fast.

1. SEU as a daily tool

It’s time.
SEU cannot do what modern tooling demands:

Code completion
AI assistance
Unit testing
Git integration
Refactoring
Modularity
SQL tooling
RPG enhancements

Staying in SEU will hold teams back.

2. Green-screen “hunt for the source”

With Bob:

Code is organized
Dependencies are mapped
Programs open instantly
Navigation is graphical

No more searching three libraries deep for a copybook.

3. Manual refactoring

Bob can detect patterns, anti-patterns, and opportunities for modernization:

Replace O-specs
Convert fixed-format
Expand data structures
Inline documentation
Convert RPG to service programs
Unpack monoliths into layers

This is modernization at speed.

4. Coding without standards

Bob Rules allow you to define:

Naming
File conventions
SQL usage rules
Error handling
Modular design
Free-form requirements
Test coverage expectations

Then Bob enforces them automatically.

5. Unscalable documentation

Bob generates:

Readme files
Module descriptions
High-level architecture
ER diagrams
State machines
API contracts
Cross-reference maps

Documentation is now a button — not a missing 3-month task.

The New Habits IBM i Developers Must Learn

Switching to Bob isn’t just a tool upgrade; it’s a change in how teams work.

1. Git as a foundational workflow

This is critical.

Git is not optional.
Remote build pipelines are not optional.
Pull requests are not optional.

Bob integrates Git deeply:

branch creation
PR automation
issue linking
code reviews
version snapshots
task decomposition

2. Testing culture

Bob generates RPGUnit test cases automatically.

This is a massive shift.
For decades, IBM i shops have relied on integration testing or manual QA.
Unit testing introduces:

higher confidence
safer refactoring
faster deployments
fewer regressions

Developers must learn to expect testing, not avoid it.

3. Collaborative modernization

This means:

code reviews
shared standards
consistent architecture
reusable modules
common libraries

Bob supports this out-of-the-box.

4. Asking better questions

Bob thrives on high-quality prompts and clear goals.

This trains developers to think:

precisely
architecturally
systematically

Bob improves developers as they improve Bob.

Training Strategies to Prepare Your Team

Modernization cannot be mandated.
It must be supported.

Here’s how.

1. Give developers protected learning time

Even 1–2 hours weekly accelerates learning dramatically.

2. Build a shared VS Code workspace

Pre-configured settings prevent setup paralysis.

3. Start a small “Bob Pilot Project”

Choose:

a small application
a known module
a utility program
a low-risk service program

Let developers learn hands-on.

4. Establish Bob Rules early

This acts as your internal style guide:

file templates
naming standards
SQL practices
error handling
module structure

5. Modernize incrementally

Avoid Big Bang rewrites.
Bob supports step-wise evolution:

DDS to DDL
Monolith to modules
Program calls to service programs
Pointers to prototypes
Fixed-format to free-form
Manual logic to testable logic

Small wins build confidence.

6. Identify early champions

These developers become:

trainers
mentors
reviewers
tool owners
culture carriers

Bob rewards prepared teams.

Preparing for the GA Release: Leadership To-Do List

Before Project Bob goes GA, leaders should:

1. Move your team to VS Code now

Jump early.
Lower the transition friction.

2. Standardize Git workflows

Teach:

cloning
branching
commits
merging
PR reviews

3. Begin modern SQL adoption

If your team is still relying heavily on DDS and native I/O, start introducing:

4. Introduce internal code reviews

These will eventually be automated by Bob.

5. Build a modernization roadmap

Include:

Code strategy
Database evolution
Testing adoption
Training plan
Tooling rollouts
Culture shifts

6. Join the Bob waitlist and stay informed

Educate your team early.

The Real Story: It’s Not About Tools — It’s About Identity

IBM i developers are legendary.
Not legacy.
Legendary.

They’ve carried systems that run banks, hospitals, manufacturers, governments, and critical infrastructure for decades.

Bob isn’t replacing them.
Bob is validating them.

It says:

Your work matters.
Your systems matter.
Your platform matters.
And now you’ll have the tools everyone else has had for years.

This is the modernization moment our community has been waiting for.

Final Sip

Sumatra Dark Roast finishes bold and steady — and so too does the message today:

Project Bob isn’t the future of IBM i.
It’s the future of how we build on IBM i.

And the teams that prepare now — the teams that invest, learn, and evolve — will define the next decade of RPG development.

Modernization is no longer a rewrite story.
It’s a mindset story.
A workflow story.
A team story.

Project Bob doesn’t threaten the RPG world.
It unlocks it.

☕ Follow The RPG Blend for more IBM i modernization, leadership insights, and developer growth strategies.
📖 Blog: https://therpgblend.blogspot.com/
📂 GitHub: https://github.com/Zero-Sub/the-rpg-blend
👥 LinkedIn: https://www.linkedin.com/in/george-vaneaton-a50101213/