IBM i, AI, And The Cost Of “We’ve Always Done It That Way”

October 19, 2026 Peg Tuttle

I’ve spent more than 30 years in the IBM i community, and I’ve heard one phrase more times than I can count: “We’ve always done it that way.” Sometimes it’s a perfectly reasonable explanation. Other times, I think it might be one of the most dangerous things we can say about a technology environment.

Think about it. IBM i has been running mission-critical business applications for decades. Manufacturing, distribution, financial services, healthcare, retail. These systems process orders, manage inventory, run financial applications, and support operations that cannot afford to stop.

And they do it remarkably well.

That reliability is one of IBM i’s greatest strengths. But I wonder whether it can also become a reason we stop questioning how we do things. When something has worked for 20 years or 30 years, what motivates us to change it? And perhaps more importantly, what happens when the reasons we haven’t changed are no longer valid?

The Cost Of Not Knowing

Let’s talk about application modernization. It’s a topic that comes up in almost every IBM i conversation these days, but modernization doesn’t necessarily mean replacing an application or rewriting thousands of lines of RPG.

Sometimes it starts with understanding what you already have.

Consider an application that has evolved over several decades. Multiple developers have contributed to it. Business requirements have changed. New interfaces have been added. Programs have been modified, expanded, and integrated with other systems. Underneath that application may be thousands of relationships among RPG programs, CL, physical and logical files, SQL tables, display files and batch processes. And somewhere along the way, the documentation may not have kept pace. The application still works, but understanding the impact of a change can become increasingly difficult.

Which programs call this one? What files does it update? What other applications depend on it? What happens downstream if we change a field or modify a process?

Those are legitimate questions, and the answers matter.

It’s easy to characterize an organization as resistant to modernization. But sometimes what looks like resistance is actually a reasonable concern about introducing risk into an environment that the business depends on every day.

I understand that.

What interests me is whether some of the assumptions behind those decisions are beginning to change.

Enter IBM Bob

I’ve been spending more time learning about AI and what it means for the IBM i community. One development that has really caught my attention is IBM Bob, IBM’s AI-powered development assistant.

Recently, Tim Rowe, IBM’s business architect for application development and systems management for IBM i, stopped by The Incredible i Show to bring us up to speed on Bob and demonstrate a new capability called Understand.

I’m not a developer, but I’ve spent enough years around IBM i applications and the people who support them to appreciate the challenges involved in maintaining decades of business logic. What caught my attention during Tim’s demonstration wasn’t simply that Bob could help developers write or modify code. It was the opportunity to better understand applications that have evolved over decades.

Understand creates a metadata repository from compiled IBM i application objects, allowing Bob to identify program calls, file relationships, dependencies, and other connections across an application. Developers can use that information to investigate how an application works and assess the potential impact of changes without having to manually trace every relationship from scratch.

Think about what that could mean for an organization with decades of business logic embedded in its applications.

Rowe also shared news about the continued expansion of the IBM Bob Premium Package for i, including newly released COBOL skills. These capabilities cover COBOL code generation, copybooks, subprograms, error handling, interactive applications, and report processing.

For organizations maintaining decades of RPG and COBOL applications, that’s a big deal. We’re not just talking about generating new code. We’re talking about giving development teams additional tools to work with applications that have evolved over many years.

That doesn’t eliminate the need for experienced developers, testing or human judgment. And it certainly doesn’t mean AI knows why every design decision was made 25 years ago.

But it can give teams a better starting point.

For years, one of the barriers to modernization has been the time and effort required to understand an application well enough to change it confidently. Maybe some projects that once seemed too complicated, too expensive or too risky deserve another look.

Want to see IBM Bob and Understand in action? Check out my recent conversation with Rowe on The Incredible i Show, where he walks through the latest capabilities, demonstrates Understand, and shares what’s next for IBM Bob.

What Happens When John Retires?

Here’s another situation I hear about frequently. Let’s call him John. John has been with the company for 30 years. He knows the applications, the dependencies, the unusual business rules and the workarounds that have accumulated over time. He remembers why a particular program was changed 15 years ago. He knows which batch jobs are critical and which interfaces require special attention.

John is invaluable.

And John is retiring.

Now what?

Succession planning is one of the most important conversations organizations should be having about their IBM i environments. Yet it’s also one of the easiest to postpone when everyone is busy keeping the business running. How much institutional knowledge exists only in the heads of a handful of experienced employees? New tools, including AI-assisted application analysis and documentation, can help organizations capture more of the technical knowledge surrounding their applications. They won’t replace the business context, and experience John brings, but they can make the transition more manageable. They can also help the next generation of IBM i professionals become productive faster.

That’s a compelling reason to pay attention, especially when the cost of doing nothing may be changing.

Modernization Is About Choices

One thing I want to be clear about: I am not suggesting that everything old needs to be replaced. An RPG application that continues to meet the needs of the business isn’t automatically a modernization problem. A green-screen interface that allows an experienced employee to work efficiently may be exactly the right solution. An on-premises IBM Power environment may still be the best fit for a particular workload, just as managed cloud, IBM Power Virtual Server or a hybrid architecture may make sense for another.

The point is that we have choices, and those choices continue to evolve. We have modern development tools, APIs, SQL, Git, automation, cloud options and now AI-assisted capabilities that simply weren’t available when many of these applications were originally designed.

The question isn’t whether every organization should adopt every new technology. It’s whether we’re periodically reevaluating our decisions based on what’s possible today. There is a big difference between continuing to do something because you’ve evaluated the alternatives and determined it’s still the best approach, and continuing to do it because nobody has revisited the decision.

Curiosity Might Be Our Greatest Advantage

One of the things I love most about the IBM i community is the depth of experience. There are people who have spent entire careers developing, supporting and improving these systems. That knowledge is incredibly valuable. But I also believe experience and curiosity need to go together.

We should be asking what new capabilities mean for our organizations. Not just AI, but application modernization, cloud architecture, disaster recovery, development practices and the way we bring new talent into the ecosystem.

What problems can we solve today that were difficult or impractical five years ago?
What processes could be simplified?
What risks could be reduced?
What would we do differently if we were making the same decision for the first time today?
And my favorite question: Why should I care?

Sometimes the answer will be that the current approach is still the right one. That’s perfectly fine. But sometimes asking the question opens a door we didn’t even realize was there.

At Lightedge, we have these kinds of conversations with IBM Power customers every day. Whether it’s evaluating an existing environment, planning an application migration, exploring managed cloud or IBM PowerVS, or building a hybrid strategy, the starting point should be understanding what you have, what the business needs and where you want to go next.

Modernization doesn’t have to mean replacing everything. Sometimes it’s about making better use of what you already have, improving resiliency and determining the right next steps for your business.

If you’re thinking about what’s next for your IBM Power environment, let’s have that conversation. Visit lightedge.com/IBM to learn more.

IBM i has a remarkable history, and its ability to evolve while protecting decades of business investment is one of the reasons the platform remains so important. We should be proud of that history. But honoring the past doesn’t mean we have to keep doing everything the same way.

So, the next time someone says, “We’ve always done it that way,” maybe the best response isn’t to argue for change.

Maybe it’s simply to ask: Why?

And then be willing to listen to the answer.

Peg Tuttle is Director, IBM Power Community Evangelist at Lightedge, where she works with customers, partners and the IBM Power community to explore modernization, cloud and emerging technologies. With more than 30 years in the IBM i ecosystem, Peg is an IBM Champion, president of COMMON, and host of The Incredible i Show podcast. She’s passionate about connecting people, sharing ideas and helping organizations navigate what’s next for IBM i.

This content is sponsored by Lightedge.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search