Your IBM i Is Ready for AI. Is Your Development Pipeline?

The Pause That Changes Everything 

Last month, I was speaking with the IT director of a mid-sized IBM i shop who was genuinely excited about AI-assisted development. They’d seen the demos of using all the powerful tools accessible via VS Code. They’d read the case studies. They were ready to move. Then they paused. The pause was familiar. “The problem is that most of the tools we want to use require the code to be local on the developer’s PC and managed using Git. We’re still mostly on PDM using traditional IBM i change management. Our code is all in source members, source files, and libraries – the usual. How do we set ourselves up so we can take advantage of all this great technology?” 

The Foundation Problem Nobody Is Talking About 

AI coding tools, including IBM Bob, Anthropic’s Claude, Cline, and ChatGPT, are producing real results in the IBM i community right now. Developers are delivering new capabilities for their RPG applications faster than anyone thought possible a few years ago. Code analysis that used to take days, weeks, or months is happening in minutes. At the same time, the open source and vendor communities are delivering powerful new tools like code scanners, test case generators, developer shortcuts that dramatically increase developer productivity. I’ve seen it firsthand, and this can be a significant moment for our community. 

 But the uncomfortable truth is that to be most effective, AI coding systems and the other open source tools need your source code on the developer’s local machine to optimally function. The tools do not typically understand or support the library/source file/source member paradigm. 

Most IBM i developers are still using PDM, or the RDi Remote System Explorer, or the Code for IBM i plugin for VS Code to do their work. All of these are looking at code in libraries. The same is true for most traditional IBM i change management systems – they are oriented towards managing things in libraries. They might give you the ability to update a Git repository as you move code around but if you want to develop on your PC, you are mostly on your own.  

But the local copy problem is actually the smaller issue. There’s a deeper one hiding underneath it. 

The Git Checkbox Problem 

The change management challenge in the IBM i world is that most experienced IBM i developers are comfortable working in the traditional structure and they like using tools that use that familiar environment. So, most existing IBM i development tools reflect that preference. Developers continue to work in the traditional way but the tool will update a Git repository at the back end as code moves around. While that gets your code into a Git repository, it does not allow you to take advantage of all of the power of working natively with Git and the new tools. 

 Real Git support for IBM i – taking advantage of all of the power of the platform that over 100 million developers use to build modern software – requires a complete Git-oriented development ecosystem that puts no limitations on what you can do. Branching strategies that let your team work in parallel without stepping on each other. Pull requests and code reviews are baked into how work gets done. CI/CD pipelines that kick off builds, quality scans, and deployments the moment code is committed. Deep integration with the tools enterprises already rely on: GitHub Actions, Azure DevOps, Jira, ServiceNow, SonarQube. 

As one IBM i developer said to me recently: “I want all the power of Git, not a backup dressed up as Git.” 

That is why we built Eradani DevOps – to give IBM i developers true, native Git. Not a copy. Not a checkbox. The full ecosystem, working exactly the way 100 million developers expect it to work, on the platform they’ve built their careers on. With Eradani DevOps, you can use every Git function, every command option, every integration with other tools because Eradani DevOps is built around Git as the source of truth. At the same time, Eradani DevOps will keep your libraries, source files, objects, and source members up-to-date with the Git repository so you can continue using PDM, the RDi Remote System Explorer, and the Code for IBM i plugin to VS Code. 

Why This Matters Right Now 

When your developers work in real Git with Eradani DevOps, something else happens automatically: they already have a local clone of their repository on their machine. That’s just how Git works. You clone the repo, work locally, and push your changes. Every developer who has ever used Git knows this workflow. 

That local clone is exactly what AI coding tools need to function. 

Eradani DevOps customers aren’t blocked by the limitations frustrating other IBM i shops right now. Their developers are working locally, in VS Code, with full Git functionality. Adding an AI coding assistant to that workflow isn’t a project. Because its all native Git, it’s embedded in the solution. 

And the benefits don’t end there. It’s just the beginning. 

When AI produces modernized RPG, optimized SQL, COBOL, or even converted free-format code, that output needs to go somewhere. In shops without a real development pipeline, it is often left to the developer to decide if the code moves to production. Anyone who has worked with AI coding assistants knows that this is a recipe for disaster. Developers are generally overwhelmed with the backlog of work and are anxious to get onto the next task. However, anything the AI generates needs a review process. 

With Eradani DevOps, the AI-generated code enters the same pipeline as everything else. It gets committed to a real Git branch. It goes through a pull request and code review. It triggers automated quality checks through SonarQube. It flows through iDeploy to the IBM i with full traceability. Nothing reaches production without going through the same process as every other change. Auditors can examine IBM i code in exactly the same way as they look at any other code. 

The Question Most Shops Haven’t Asked Yet 

AI coding tools are going to help the IBM i community modernize faster than any of us expected. I genuinely believe that. But the shops that get the most out of these tools won’t just be the ones who adopt them earliest. They’ll be the ones who built the right foundation first. 

Before you invest in AI-assisted development for your IBM i shop, consider these questions honestly: 

• Are your developers working with a real local copy of your source code, or are they still pulling files down manually when they need them? 

• When you describe your “Git support,” can your developers actually branch, merge, and trigger CI/CD pipelines from IBM i source? Or does a copy just sit in a repository somewhere, untouched? 

• When AI generates new or modernized code, does your process ensure it goes through the same quality gates and approval workflows as everything else? 

• Do you have full traceability from a code change all the way to a production deployment on the IBM i? 

If any of those questions gave you pause, that’s the right place to start. 

At Eradani, we’ve spent years building the DevOps foundation that makes modern IBM i development possible, and now AI-assisted development too. If you want to talk through where your shop stands, we’d be glad to have that conversation. Find us at COMMON POWERUp 2026 in New Orleans, or reach out at eradani.com. 

The AI moment for IBM i is real. Make sure your pipeline is ready for it.