Something unusual happened in a 2026 IBM i Marketplace Survey. AI and machine learning jumped from 30% to 42% as a top five concern among IBM i professionals in a single year, the largest single-year move of any topic in the survey.
That is not a gradual drift. That is a platform’s worth of IT managers and CTOs waking up at roughly the same time to the idea that they might be behind.
And yet, worry has a strange relationship with action. In the prior year’s survey, IBM i CTO Steve Will summarized the usage numbers plainly: “I guess a little more than half of our clients still aren’t doing any AI at all.” 57% of respondents that year answered “none of the above” when asked how they were actually using AI.
The concern kept climbing into 2026. The starting line barely moved.
This is the gap worth naming directly, rising anxiety about AI, paired with a majority of shops that have not taken a single concrete step. If that describes your organization, you are not behind some AI curve that everyone else has already figured out. You are in the majority. The interesting question is not whether you should feel behind. It is what is actually causing the freeze, and what breaks it.
Why the Concern Is Rising So Fast
Some of this is simply the platform catching up to a conversation the rest of the industry has been having for a few years. But two specific developments in 2026 have made AI feel urgent in a way it did not before for the IBM i community.
The first is IBM Bob. IBM i customers got access to Bob 1.0 in March 2026 as a forked version of VS Code built to explain, refactor, generate, transform, and test code across RPG, CL, SQL, COBOL, Java, and Python. A month later, IBM announced Bob’s broader global availability as a full software-development-lifecycle platform with multi-model orchestration across providers including Anthropic’s Claude and Mistral, plus IBM’s own Granite models. When the platform vendor itself ships an AI coding tool, “wait and see” starts to feel like a harder position to defend in front of leadership.
The second is IBM’s own stated roadmap. IBM i Chief Architect Steve Will set a public goal of producing at least 500 Model Context Protocol (MCP) tools for the platform in 2026, the connective layer that lets AI agents actually interact with IBM i systems.
That is not a hypothetical future capability. It is an active build-out, and it signals that IBM expects AI on this platform to become infrastructure, not an experiment.
Put together, these developments tell IBM i leaders something they cannot easily unhear: this is happening whether or not their organization has started.
What Is Actually Freezing Most Shops
If the case for urgency is this strong, why does adoption still lag so far behind concern?
In our conversations with IBM i leaders, the freeze rarely comes down to a single blocker. It is usually a stack of smaller ones.
- The stakes feel too high for a first move. IBM i shops run the applications the business cannot afford to get wrong. Order processing, inventory, financials, the systems that would make the news if they went down. When every application feels mission-critical, there is no obvious low-risk place to experiment, so nothing gets tried.
- Nobody wants to bet on the wrong tool. The platform has watched AI-for-RPG promises evolve for two years, from early code-assist previews to Watsonx Code Assistant for i to Bob. Teams that watched that evolution unfold are reasonably cautious about investing time in whatever came first rather than whatever proves durable.
- Vendor lock-in is a real and specific worry here. An IBM i shop’s core logic represents decades of institutional knowledge. Committing that logic, or the workflows built around it, to a single AI vendor’s roadmap and pricing decisions is a bigger structural risk than trying a new tool on a greenfield project would be.
- There is no internal AI skill to lean on. Most IBM i teams do not have someone on staff who has run an agentic coding project before. Without that internal reference point, the first attempt feels like it has to be figured out from scratch, which raises the perceived cost of starting.
- The scope of “doing AI” feels undefined. Does it mean a chatbot for developers, an assistant that writes code, an agent that runs autonomously against production logic? Without a clear, bounded first use case, “get started with AI” is not actually a task anyone can put on a project plan.
None of these are irrational concerns. They are the correct instincts of people responsible for systems that cannot fail. The problem is that, left unaddressed, they do not resolve into a decision. They resolve into another year of no decision, while the concern keeps climbing in next year’s survey.
What Actually Breaks the Freeze
The organizations that get unstuck do not resolve every one of those concerns before acting. They pick a first step small enough that most of those concerns simply do not apply yet.
Start with something that cannot break production
The lowest-risk category of AI work on IBM i is understanding code, not changing it. Documentation, dependency mapping, and explaining what a program actually does are read-only tasks. There is no deployment risk, because nothing gets deployed. This is also the task most IBM i shops need most urgently regardless of AI, since so much business logic exists only in code and in the heads of a shrinking group of veterans.
Pick one contained, well-understood program
Not the core order engine on day one. A single program that a senior developer already knows well enough to evaluate the output against. The goal of the first attempt is not business value yet. It is building internal confidence that the output can be trusted, and building the muscle of reviewing AI-generated work.
Define what success looks like before you start
Even a simple bar, such as “does this documentation match what our senior developer would have written,” turns a vague initiative into something with a clear pass or fail. That clarity is what makes it possible to report back to leadership with a real answer instead of an impression.
Keep a human in the loop on everything, deliberately
This is not a permanent constraint. It is how the first project builds the trust that makes the second project bigger.
Treat model choice as a decision you can revisit, not one you have to get right forever
This is where the vendor lock-in concern actually gets resolved: pick a starting point that does not require committing your entire AI strategy to one company’s roadmap. More on this in an upcoming piece.
Where CoderFlow Fits as That First Step
This is precisely the shape of project CoderFlow is built for.
Rather than asking a team to hand over a mission-critical workflow on faith, CoderFlow agents can be pointed at a single RPG or COBOL program, asked to map its dependencies and document its business logic, and reviewed against exactly the kind of pass or fail bar described above, all without touching a production deployment.
Because CoderFlow is not tied to a single AI model, that first project also does not lock your organization into one vendor’s future pricing or roadmap. You can run the same task against Claude, Gemini, or other supported models, compare the results, and choose based on what actually performs well against your codebase rather than on a bet made once and never revisited.
For a shop that has been sitting in that gap between rising concern and no clear first step, this is designed to be exactly that first step: contained, reviewable, and built around a real IBM i workflow rather than a generic AI demo.
It is also worth being direct about one distinction as you weigh options like Bob against CoderFlow. Bob runs as a SaaS platform today, with on-premises deployment described as a future target for organizations with data residency requirements.
CoderFlow runs entirely inside your own infrastructure now, not on a future roadmap, which matters for shops that are protective of decades of business logic and are not ready to send it to a third-party cloud service as their first move.
If you want to talk through what a first, low-risk AI project could look like against your own application portfolio, reach out to our team at Futurization@ProfoundLogic.com.