Across manufacturing IT and cybersecurity circles, the debate rages over whether AI is the fix for legacy system risk or proof that legacy systems like IBM i are the problem. This debate makes sense now, given that 27.7% of all attacks tracked by IBM X-Force in 2025 impacted manufacturing, making it the most-targeted industry for five years running.
The trouble is that both options frame the programming language as the most important variable, creating a false binary. These dueling assumptions ignore what’s changing: not the code, but the speed at which everything now moves.
It doesn’t help that the manufacturing technology press usually frames legacy COBOL and RPG systems as inherently insecure. Modernize-or-die and rip-and-replace op-eds fly thick and fast, and everyone hyperventilates about their “outdated” systems. Organizations spend big, upend their infrastructure, implement new systems, create institutional stress and take on new learning curves, only to find out too late that there is no correlation between age and insecurity.
Newer isn’t always better. Engineering and reliability matter, as does institutional knowledge about established systems. A well-governed 30-year-old system and a poorly governed one built just last year both carry very different risk profiles, no matter what language they use. The codebase isn’t what makes industrial technology vulnerable to malware. Instead, security and malware systems alike are benefiting from the same fast-moving AI technology.
What AI really changes
AI- and LLM-assisted code generation is now directly impacting RPG and COBOL systems, as developers adopt AI tools to draft, refactor, and explain legacy code they didn’t originally write. While extremely useful for letting new users get right to work on any system, this creates a dangerous expertise and comprehension gap, as users let LLMs generate code for systems they may not fully understand.
Not only that, but users who once relied on static, rule-based alerts are now layering AI-driven monitoring tools onto IBM i to track behavioral anomalies. AI is more adaptable than static systems, but only if the people using it have fully mastered the platforms the AI watches over.
It really doesn’t help that attackers and bad actors are using the very same AI models IT professionals rely on to keep their systems safe. Reconnaissance and credential-based intrusion techniques that used to require manual effort and brain power are now set-it-and-forget-it tasks.
One might think that if both sides use the same AI tools, escalation is equal and nothing has really changed—the sheriff and the outlaws have the same guns. The problem is that the new guns surely fire much faster. AI makes the security process much quicker on both ends, interacting at breakneck speeds with established security risks.
The threats remain the same
These established security risks long predate AI, and include undocumented customizations, access control gaps, and legacy integrations with unclear ownership. None of these problems are due to the code's age. They’re just what happens when institutional memory erodes faster than documentation and governance can keep up.
Likewise, weaknesses in human processes (including tribal knowledge, inconsistent review practices, and informal change management) have always existed on IBM i systems. But the very same problems will exist in any system where humans are involved, no matter how heavily their employers leverage AI,
Whether defending or attacking a system, AI doesn’t fix or worsen these conditions on its own. An LLM can only interact with whatever state the system is in when the AI is implemented. So what organizations are facing isn’t a technology problem but a governance problem that existed before AI was a factor, and will continue to exist whether on legacy or bleeding-edge platforms.
So the debate isn’t really about whether AI can fix legacy systems or if the systems themselves are the problem. The debate is really about what’s changing and what isn’t, and where AI actually makes a difference.
Amplification both ways
Let’s start with the bad news: AI can definitely amplify (and help bad actors exploit) the existing weaknesses in systems of any vintage. The most obvious example is an AI tool generating code within a poorly documented system. Any code it creates will inherit the same blind spots as the original developer introduced, all while the AI works faster and on a larger scale.
If an environment lacked clear access controls before AI arrived, it won’t magically become less vulnerable. Because AI works so fast, any vulnerabilities it creates will spread far and wide before anyone notices. While not a threat vector on its own, AI sure is a force multiplier on existing problems in any system, no matter how venerable.
The good news, however, is that if AI’s real threat lies in amplifying problems, an IT team can shift its focus from distrusting AI or legacy systems to reexamining and addressing the conditions AI amplifies. Rather than planning costly and risky rip-and-replace campaigns, manufacturers should update how they think about IBM i risk. Documentation, review, and access control processes must evolve to keep pace with faster-moving development and AI-enabled attacks.
A change in perspective
This approach offers a new audit lens. By shifting focus and evaluating against new criteria, manufacturers can better adapt to the rapidly shifting governance landscape. Because AI can exacerbate existing governance gaps, IT professionals need to close those same gaps now. The cost of leaving these gaps open has gone up, but those same flaws will exist in poorly governed systems of any age.
When technology changes rapidly, it's easy to assume established systems and languages are the problem. But that change only highlights issues that would plague any system and, in doing so, emphasizes the need to address those gaps in whatever systems a company uses. Manufacturers that understand the need to address existing governance flaws will be better positioned to both leverage the benefits of AI and resist AI-driven malware, no matter what programming language they prefer.
