IBM Bob for Z: Why Vibes Don’t Run the Mainframe

Happy first birthday, IBM Bob. When I tell people I started my career as a COBOL software engineer at the age of 18, I usually get a similar look: somewhere between fascination and mild concern. I understand the reaction. But the COBOL applications out there aren’t museum exhibits. They are still pulling their weight in production, running core business processes every single day. That is why IBM Bob for Z has to do more than generate plausible code.

As the IBM and mainframe community gathers for IBM TechXchange 2026 in Atlanta, on 26–29 October, it has been roughly a year since IBM first announced Bob on that stage. In March, I wrote that watsonx Code Assistant for Z was a meaningful step in our evolution, even if it wasn’t the final destination.

Since June 2026, we’ve had our hands on the next step: IBM Bob Premium Package for Z. After months of seeing what works and what crashes into reality, it’s time for an honest, hype-free look at where agentic AI on the mainframe actually stands.

The 3 AM Mainframe Reality vs. the Marketing Fairy Tale

When I speak with mainframers and enterprise architects, nobody asks me about “synergistic AI paradigms.” They talk about the things that actually keep them awake at night:

• Their sole Endevor admin is retiring in twelve months.
• Nobody left in the building truly understands how the core applications hang together anymore.
• Fresh university graduates take one look at a 3270 green-and-black screen and quietly back out of the room.

And how has tech marketing responded to this very real anxiety? With fairy tales. You’ve probably heard the pitches by now:

• “Just run our AI over your codebase, and we’ll transform the whole thing into Java in four weeks!”
• “Skills shortage? Relax, AI knows it all!”
• “Our AI will write and fix your batch jobs while you sleep on the beach!”

If you’ve maintained a production mainframe system, you know how absurd that sounds. Gartner predicts that more than 70% of mainframe exit projects started in 2026 will miss their intended benefits because organizations overestimate what generative AI tooling can do. That is a forecast, not a measured failure rate for completed projects.

For large enterprises, data volumes, tightly coupled applications and decades of embedded business logic make a wholesale migration much harder than a code-conversion demo suggests. You cannot prompt-engineer your way out of forty years of tightly coupled business logic.

Why Out-of-the-Box Coding Agents Hit a Wall on z/OS

Don’t get me wrong: modern coding agents like Codex, Windsurf, Antigravity and base IBM Bob are impressive.

Bob brings its own IDE and Bob Shell for command-line work, alongside an agentic approach that can plan, execute, validate and govern multi-step development tasks. It combines developer intent with codebase context, team instructions and tools, using multiple models where appropriate. Security scanning and governance features are useful parts of that setup; they don’t automatically make every customer deployment compliant.

So why not just point an out-of-the-box agent at your mainframe code?

Because an agent working only from a local repository may be missing most of the context that matters. On the mainframe, we deal with what I call the environment problem:

• The business logic is scattered. It lives across PDS libraries, nested copybooks, JCL procedure libraries, Db2 schemas and CICS transaction definitions. A model can’t reason reliably about context it hasn’t been given.
• The build-and-test loop is different. Compiling and testing may require submitting jobs to z/OS and operating within RACF permissions, rather than running a quick local command.
• The developer experience is split. Part of the team still works in ISPF, while newer engineers use VS Code or Eclipse-based IBM Developer for z/OS (IDz).

These problems are solvable, as I explained in my earlier post on legacy SCMs and mainframe AI. But solving them takes time and effort. Until then, simply refusing to use AI isn’t much of a strategy either.

Enter IBM Bob Premium Package for Z

Available since June 2026, the Premium Package for Z addresses that environment gap by adding mainframe-specific context, modes, skills and tooling to Bob. It builds on the capabilities of watsonx Code Assistant for Z.

• Mainframe language and middleware awareness. The package supports work across COBOL, PL/I, assembler, JCL and related technologies, with context for systems such as CICS, IMS and Db2.
• Application understanding with Z Understand. Static analysis creates a queryable view of programs, copybooks, jobs and their relationships across an application estate. That gives the model structured facts to reason over, rather than asking it to reconstruct everything from isolated source files.
• Architecture and code workflows. Z Architect and Z Code modes help with impact analysis, explanation, documentation, code changes and refactoring. They can help make an undocumented program easier to investigate, while a developer checks the conclusions against the real system.
• Team standards that travel with the repository. Instructions in AGENTS.md and reusable Bob Skills help apply your team’s conventions consistently. These are explicit instructions and workflows, rather than a substitute for institutional knowledge.

And yes, code transformation is part of the conversation, including COBOL-to-Java work. It sounds great at first. But is changing the language really what we need?

The programming language has never been the whole problem. Rewriting clean, high-throughput COBOL into mediocre Java doesn’t solve an architecture problem; it gives you new syntax to debug. The value I’m interested in is making existing z/OS applications understandable, maintainable and testable.

The Integration Layer Is the Crux

Buying an AI licence is easy. Wiring it into a transactional core that has evolved over decades is the hard part.

Between the developer’s IDE and pipelines, the AI layer, and the z/OS foundation sits the integration work: tools and services such as Zowe, z/OSMF, Wazi tooling and z/OS Connect, backed by the appropriate RACF controls. Which components you need depends on your workflow. Installing an assistant doesn’t create those connections for you.

That integration layer is the crux. It determines what the assistant can see, what it can do, how changes are validated and who remains accountable.

Four Hard-Won Lessons and What Bob Cannot Do

Before rolling out IBM Bob for Z across your mainframe teams, set expectations clearly. No matter what a glossy brochure says, these tools cannot:

• Magically rewrite your entire mainframe estate overnight.
• Replace thirty years of knowledge inside your lead architect’s head.
• Guarantee 100% accuracy without human review.
• Skip change management or regulatory requirements.

From our hands-on work, here are the four rules that separate a useful rollout from expensive shelfware:

1. Start contained. Give Bob one read-only, high-value application slice. Use code understanding and architecture analysis to prove the value, then widen the scope.
2. Keep humans in charge. Every AI suggestion needs a named human reviewer who owns the decision.
3. Instrument the work. Use Bobalytics for visibility into usage and consumption. Measure elapsed time, rework and failure rates in your delivery workflow as well.
4. Govern before scale. Audit trails and tested rollback procedures are part of the rollout, not a task to leave until later.

Technology Is Only Half the Battle

A year after Bob’s announcement, and after several months working with the Premium Package for Z, I’m optimistic. We have an agentic environment that takes the reality of z/OS seriously.

But technology is only half the battle. The other half, even with AI and even with Bob, is mindset. If your organization isn’t ready to modernize its workflows, open its silos through tools such as Zowe and modern IDEs, and pair senior architects with developers who want to learn the platform, no AI agent will save you.