Integrating AI into your IBM i DevOps pipeline without losing control

When people talk about applying AI to DevOps, the image that comes to mind is a developer who codes faster. That isn’t the story that really matters on IBM i.

The real story begins when you move from the developer to the team, and then to the enterprise platform: that is where delivery holds or breaks. On an IBM i estate running hundreds of interconnected applications, across several countries and/or teams, the constraint has never been compute capacity. It is change capacity: how many changes can you push into production without breaking anything?

Many organizations have already taken a first step with coding assistants. It’s a good starting point: they cut the time to a first draft, explain existing code and speed up documentation. But while they optimize an individual developer’s productivity, what really slows down a production delivery stays the same: impact analysis, testing, building evidence for audit. In other words, everything that, in a regulated or high-availability environment, happens after the first draft of code.

IBM i is not a playground for black-box automation. It is a shared, highly context-dependent environment where RPG, COBOL and CL programs and DB2 components are linked by dependencies that only a handful of experts still fully master. And that handful shrinks with every generation.

In this context, “losing control” has a very concrete meaning: an agent that modifies code with no traceable justification; a change that lands in a test environment without anyone being able to say why; overly broad access granted for convenience; a segregation of duties that disappears because the same agent both proposes and executes.

None of this is inevitable with AI itself. It is a direct consequence of the way AI is brought into the pipeline.

The good news is that this problem isn’t new: it’s the problem of any high-privilege automation. The answer isn’t to remove controls to go faster, but to make them repeatable, visible and quick to run. In practice, for an IBM i change request, the flow looks like this:

The agent builds the case (analysis, proposal, evidence) but never goes through the gate alone. Human review remains the mandatory checkpoint before any promotion to a higher environment.

The key point is not to remove controls, but to make them systematic: every step the agent produces is logged, every pull request carries its rationale and its risks, and promotion remains a human decision, backed by evidence that has already been gathered rather than reconstructed in a rush.

Because the IBM i environment is shared, adoption can’t be a gamble. It moves forward in stages, each one validated before moving on to the next.

Scope expansion always comes with stricter release gates, never the other way around. This progression delivers value early, without betting on the operational discipline that protects production.

Once the path is set, governance itself must be designed like that of any high-privilege automation, not as a box to tick after the fact.

1. Identities and least privilege. Each agent, whether it acts on behalf of a human or autonomously, has its own identity and only the rights its task requires.
2. Human in the loop. Approvals and reviews remain mandatory, and this requirement is technically enforced in the pipeline: branch protections, control gates that cannot be bypassed.
3. Whitelist of MCP servers and tools. The Model Context Protocol connects agents to tools: it must be governed like any interface, by defining precisely what an agent can access, nothing more.
4. Systematic logging. Every tool or agent invocation is recorded, for audit as well as incident response.
5. A formalized AI governance model. Beyond technical controls, the organization must have settled who decides, who approves, and how far the authorized scope extends.

This is the principle that structures the ARCAD agentic platform: the agent reasons and plans, but a workflow engine, deterministic and logged, does the executing. No model improvisation on a sensitive action.

The architecture rests on three pillars. Knowledge (RAG) grounds the agent’s answers in more than thirty years of ARCAD methodology rather than in the model’s probabilities alone. Tools (MCP) expose the ARCAD DevOps stack (DROPS, the Metadata Repository, Builder) in a standardized form: around 80 DROPS REST endpoints are exposed as MCP tools, available to any MCP client, whether it’s the ARCAD agent, Copilot or Claude. Action (the workflow engine) runs ARCAD’s standard processes in a repeatable, auditable way, with sensitive steps still subject to human validation, exactly as today.

This choice has a deliberate corollary: AI is the assistant, not the engine. Results remain deterministic, not a probabilistic estimate. The source of truth remains the ARCAD repository rather than a model’s answer, and there is no runaway correction loop where the AI would endlessly try to fix its own output. Each organization chooses the steps where AI steps in; the product keeps working without it, and the cost, in tokens as well as in risk, remains predictable.

This kind of discipline holds up at scale. At Leumit Health Services, ARCAD Transformer Field automated a field expansion project across the entire IBM i application estate, as part of an end-to-end DevOps process.

The adoption that works follows a simple principle: start small, govern from day one, scale what works.

One or two strictly read-only pilots, chosen for the pain points they remove right away: impact analysis, documentation, evidence gathering.

Guardrails go in place in parallel: identities, control gates, evidence archiving, a tool whitelist with detailed logging.

Forming mixed squads of IBM i and non-IBM i engineers, to widen the scope without concentrating risk on a handful of experts.

Blameless post-mortems and shared playbooks, so that every incident avoided benefits the next team.

ARCAD Software – Content based on real-world experience and technical sessions from the ARCAD Summit.