With deadlines looming and customers pressuring your team, your manager is yelling at you to roll out that piece of code everyone is waiting for. What no one seems to appreciate, however, is the amount of time it takes to write, test, and deploy code. The stress and expectations are real, but so is the assumption that your code will work reliably and if it doesn’t, that you can debug and fix it in a short amount of time.
Enter AI, that silent assistant lurking in the corner, just begging to be used. It promises to be faster, more efficient, and easier than writing every line yourself. It’s an easy trap to fall into. Before you know it, you’re testing a program you had little input into and you’re debugging logic you didn’t structure or develop.
It may sound extreme, but the reality is that AI-generated code introduces risks every mainframe developer should understand before relying on it.
The Accuracy Factor: Research vs. Reality
Industry reports show the accuracy rate of AI-generated, deployable code on the mainframe is less than 50% overall. Some studies report accuracy rates of up to 95% for specific coding tasks, but that figure falls to 17% when AI is asked to handle enterprise-wide architectural changes or translate highly complex business rules. Even a 95% success rate isn’t enough when you’re writing code for systems that support global financial institutions, healthcare organizations, and other mission-critical operations. In many industries, faulty code that breaks in production can also expose organizations to significant regulatory penalties.
Mainframe coding problems usually aren’t about AI misunderstanding what a program is supposed to do. They’re about missing the production-grade details that make code work end-to-end in a tightly controlled legacy environment. Mainframe environments are highly specific. Compilers, build and deploy pipelines, system interfaces, naming/calling/JCL conventions, link edits, COBOL copybooks, Assembler macros, record layouts, and security controls all interact in ways that many AI models do not fully understand. Coding conventions are also highly customized. They can differ from one organization to another and may even vary greatly from location to location within the same company, so what works at one site may not necessarily work at another.
Hidden Risks and Costs that Come with Debugging
Have you ever tried to debug code you didn’t write? If a team or developer doesn’t fully understand the AI-generated code, every future change or bug fix requires them to re-learn the code. That slows development, increases costs over time, and makes the next debugging cycle slower and even more error-prone. When code is produced without meaningful human involvement, less understanding transfers to the team. That contributes to an overall loss of critical knowledge.
Beyond the loss of institutional knowledge, AI can also affect developer productivity. A recent study found that developers spend a significant amount of time checking and fixing AI code mistakes. According to the study, 77% of users say they audit AI work with the same or more rigor than human work. The study also found that finding and fixing AI mistakes can consume up to 40% of the time AI is expected to save.
The direct cost of reviewing and correcting AI-generated code is only part of the problem. Hidden costs emerge when AI-generated code looks correct but breaks when integrated with real environment settings, turning debugging into chasing symptoms across multiple systems rather than fixing a single line of code.
Sometimes failures appear only under certain inputs, boundary conditions, or time windows, making them expensive to reproduce. AI also tends to infer or substitute assumptions (such as formats, encodings, null/empty handling, or invariants) that don’t match production reality. Those mismatches may not be obvious during code review, adding even more time to the debugging process.
When those issues aren’t identified until late in the development cycle, they can force emergency releases, hotfixes, rollbacks, or extended outages. Those disruptions often cost far more than the time required to develop the code correctly in the first place.
Legalities vs. Logistics
Let’s leave the first two cautionary tales behind and consider a scenario where AI has delivered on its promise and you have a brand-new piece of code that works in production. The next question is who owns the code.
Code ownership sits at the center of business operations because it affects both risk and control. Organizations need to know who can legally change, maintain, and redeploy their code. If AI code output is only partly eligible for copyright or Intellectual Property ownership is unclear, there can be uncertainty about who has the legal right to modify and distribute the software that contains the code, particularly across teams, vendors, or client environments. Mainframe applications often live for decades, so organizations want ownership arrangements that remain stable as systems evolve, staffing changes, and vendors come and go. If code, or even just the workflow around it, is derived from a third-party AI source, organizations may hesitate to use it without clarity on IP rights, because the cost of a later dispute is huge when systems are down.
Auditability and compliance are also important, especially in highly regulated environments such as financial services or healthcare. Mainframe changes, including change management, approvals, and evidence of testing, are often subject to close scrutiny. Questions about code ownership can become part of defensible documentation: who contributed, what was used, what was reviewed, and what rights the organization has.
The legal landscape is still evolving. At the time of this writing, ownership of AI-generated mainframe code in the United States depends largely on the type of ownership at issue. For copyright, the U.S. Copyright Office has stated that outputs of generative AI can be protected by copyright only when a human author contributes sufficient expressive elements. Works created entirely by AI are not eligible for copyright protection.
If a developer meaningfully writes, edits, arranges, or modifies the AI-generated code, those human-authored portions may be protected. If the code is produced entirely by AI with no significant human input, then there may be no copyright ownership to assign. The exact answer varies by jurisdiction, contract structure, and other legal considerations. AI is being developed and interjected into scenarios involving creative content and IP ownership at a much faster pace than the laws and governance surrounding it.
Assist Rather than Replace
So, after all the doom and gloom, the basic question remains: Does AI have a place in developing reliable and deployable mainframe code? The answer is a guarded yes. The most reliable outcomes are produced when AI is used to assist a developer, not replace them.
Treat AI as the productivity tool it was meant to be, accelerating work while leaving the parts that require judgment, verification, and deep knowledge of your mainframe environment in human hands. AI can increase coding speed and output, but reliability still depends on people defining requirements, applying constraints, selecting the right approach, and validating the final result.
Accountability and ownership should also be clear. If something fails, your team should know which decisions were made by people and which were generated by AI, making remediation, reporting, and process improvement easier and less costly.
Most importantly, don’t assume that AI is smarter than you. Use it as a collaborator, not the “smart kid” you’re cheating off of. At the end of the day, AI is still a variable that’s largely unknown, impressionable, and constantly changing, and none of these are qualities you want in your mainframe computer code.
