Labels

IBM BOB: An Engineer’s Tool, Not a Shortcut

 First Sip

Today’s coffee is a solid cup of Green Mountain Dark Magic. Dependable. No drama.

That’s the right frame of mind for talking about IBM BOB.

IBM BOB isn’t here to replace RPG developers, rescue broken systems, or magically modernize decades of code. It’s here to help engineers think more clearly about the systems they already own. When used well, it becomes a quiet force multiplier. When used poorly, it simply exposes existing discipline problems faster.

I’ve used IBM BOB deeply enough to trust it—and deeply enough to know where it should never be trusted blindly.

What IBM BOB Really Is

IBM BOB is an AI-assisted engineering system designed specifically for IBM i development. Not “AI for everything.” Not a generic chatbot pointed at RPG. A purpose-built tool that operates inside real IBM i constraints.

It works where IBM i teams actually live:

IBM BOB doesn’t pretend those systems are small, clean, or modern by default. It assumes complexity and helps engineers reason through it.

That assumption alone sets it apart.

The Correct Mental Model

This is the most important section of the article.

IBM BOB only works if you adopt the right mindset:

  • You are still responsible for the code
  • You still own correctness and behavior
  • You still have to understand the business rules
  • You still approve every meaningful change

IBM BOB accelerates understanding. It does not replace it.

I’ve used BOB to produce a full how-to manual for IBM i workflows—something that would have taken weeks of manual explanation and cross-checking otherwise. That worked because I already understood the system well enough to guide and validate the output.

Without that grounding, the result would have been fast and wrong.

Where IBM BOB Actually Shines

Code Understanding at Scale

IBM BOB is exceptional at helping you answer questions like:

  • What does this program really do?
  • Where is this business rule implemented?
  • Why does this field exist and who uses it?

For onboarding new developers, this is transformative. Instead of tribal knowledge or brittle documentation, you get structured explanations rooted in the actual code.

That doesn’t remove the need for mentoring. It makes mentoring more effective.

Structural and Dependency Awareness

Most IBM i risk lives in places no one can see:

IBM BOB helps surface those relationships. Not to shame past decisions, but to make future decisions safer.

This is where good engineers slow down—and where BOB earns its keep.

Refactoring Support Without Recklessness

IBM BOB can assist with:

  • Moving fixed-form RPG toward free-form
  • Breaking large programs into procedures
  • Improving readability and structure

What it does not do is push a big red “rewrite” button.

That restraint matters.

Refactoring is still an engineering decision, not a suggestion to accept blindly. BOB provides options. Engineers provide judgment.

Documentation as a Side Effect of Understanding

One of the most underrated strengths of IBM BOB is documentation generation—when it’s treated correctly.

The best documentation I’ve seen produced with BOB didn’t come from asking for “docs.” It came from asking for understanding first. Once the system was understood, the documentation followed naturally.

That’s how I used it to create a how-to manual: explain, verify, refine, then document.

Documentation should be a byproduct of clarity, not a separate chore.

What IBM BOB Will Never Fix for You

Let’s be honest.

IBM BOB cannot:

If your codebase is a mess, BOB will explain that mess very clearly.

That’s still useful—but only if you’re ready to act.

Guidance for Developers

If you’re a developer using IBM BOB:

  • Treat it like a fast reader, not a decision maker
  • Validate everything
  • Use it to explore, not to abdicate thinking
  • Learn from its explanations

IBM BOB is most powerful when paired with curiosity and discipline.

Guidance for Managers and Leaders

If you’re introducing IBM BOB to a team, your responsibility increases, not decreases.

You still need to:

  • Set expectations around ownership
  • Enforce code review and testing
  • Invest in fundamentals and training
  • Prevent tool-driven complacency

IBM BOB doesn’t lower the bar. It raises it.

Strong teams get stronger. Weak practices get exposed.

Why IBM BOB Fits the IBM i Culture

IBM i has always valued:

  • Stability without stagnation
  • Compatibility without fear
  • Progress without destruction

IBM BOB fits that philosophy.

It doesn’t tear systems apart. It helps engineers understand them well enough to change them responsibly. That’s not flashy. It’s professional.

Final Sips

IBM BOB is not here to save IBM i.

IBM i doesn’t need saving.

IBM BOB is here to help engineers who take responsibility for long-lived systems do their work with more clarity, confidence, and care.

Used with discipline, it becomes leverage.
Used casually, it becomes noise.

The difference has nothing to do with AI—and everything to do with craftsmanship.

Labels:

Comments

Post a Comment