Is Your IBM i DevOps Pipeline Ready for AI Coding Agents?

With the adoption of AI coding agents, every developer on your team is writing more code than they did a year ago. GitHub Copilot, ChatGPT, Cline, Claude Code, IBM Bob, take your pick. The tools are different, but the effect is the same: AI is compressing the time it takes to go from idea to working code. On most modern platforms, that shift already shows up in release velocity.

On IBM i, your DevOps pipeline too often doesn’t keep up. And that gap is worth paying attention to right now.

Change Velocity Mismatches

Here’s the thing nobody’s saying out loud: If everyone else is using AI coding agents and the RPG/COBOL developers are not, the change velocity mismatch will rapidly become obvious. You end up with a constantly modernizing front end bolted onto a slow-moving back end. The mismatch gets more painful every quarter. If the core RPG/COBOL applications become the bottleneck to rapid advancement, companies will start looking for alternatives. 

I’ve talked to a lot of IBM i shops this year, and the pattern is consistent. The existing tooling they have for their IBM i development does not support the technology infrastructure that the AI agents need to be maximally effective. Often, development teams are experimenting with AI assistants on their own, without getting executive buy-in. Meanwhile, the actual path from “code written” to “code in production” hasn’t changed since 2015. That’s the real bottleneck. Not developer output. Development and Deployment infrastructure.

Why This Is the Window

Three things are converging right now, and they won’t stay lined up forever.

First, AI-assisted coding is no longer optional. 

Your competitors’ developers are already using it, whether IT sanctioned it or not. The productivity gap between teams that harness it well and teams that don’t is going to widen fast.

Second, the IBM i talent pipeline isn’t getting any younger. 

Every senior RPG developer who retires takes tribal knowledge with them. Git-based version control and standard DevOps tooling capture that knowledge in a way source member libraries never could. You’re not just buying speed. You’re buying institutional memory that survives a retirement party.

Third, the tools have finally caught up to the platform. 

For years, DevOps on IBM i meant using a proprietary IBM i only solution that “locked us in.” That’s no longer true. You can run true Git, the same Git 180 million developers already know, against your IBM i source, and connect it to GitHub, GitLab, Azure DevOps, or Bitbucket. No translation layer. No proprietary format holding your code hostage.

Put those three together, and you get a short window where modernizing your DevOps process gives you real separation from competitors who wait, a head start while everyone else tries to catch up.

What IBM i DevOps Readiness Actually Looks Like

It’s not complicated, and it doesn’t require ripping out what already works. It comes down to a few things:

• Real Git, not a Git-flavored wrapper. Your developers should be able to branch, merge, and review IBM i code the same way they do everything else. This matters more than it used to: an AI assistant working against a real Git repo can see how a change touches the rest of the application. One working against isolated source members is just guessing.
• CI/CD that includes IBM i in the pipeline, not next to it. If your RPG changes still get deployed by hand while everything else runs through automation, you haven’t modernized. You’ve just added a dashboard.
• AI code generation tools are plugged into the same workflow, so the productivity gain actually reaches production instead of stalling in a code review queue nobody has time for.
• Quality gates that scale with volume. More code moving faster means you need SonarQube or an equivalent doing the checking your team doesn’t have hours to do manually.

None of this requires abandoning IBM i or the team that’s kept it running for twenty years. It requires giving that team modern tools built specifically with support for the platform they know, backed by people who’ve spent 200-plus combined years solving IBM i problems.

Reach out to me [email protected] or check out our website, eradani.com, to talk more about it. We’d love to hear from you!