An honest assessment from someone who has been working with COBOL since 1990 and watching AI tools applied to it since 2023.
There is a lot of noise about AI and COBOL right now. Some of it is vendors overpromising what their tools can do. Some of it is sceptics dismissing AI entirely for legacy code. The truth is more useful than either position.
AI tools can genuinely help with COBOL – in specific, well-defined ways. They also produce confidently wrong answers in specific, well-defined ways. Knowing which is which is the practical skill that matters.
I have been working with COBOL since 1990 and have been evaluating AI tools applied to it since they became capable enough to be worth evaluating. Here is my honest assessment.
Explaining unfamiliar code. If you open a COBOL program you have never seen before, AI assistants are genuinely useful for getting oriented. Paste a paragraph and ask what it does – you will usually get a clear, accurate explanation of the logic. For developers who can read COBOL but are not fluent, this accelerates comprehension significantly.
Identifying dead code. AI tools can help identify code paths that appear unreachable – conditions that are never true given the data structures, PERFORM statements to paragraphs that are never called, code after unconditional STOP RUN statements. Important caveat: dead code identification from static analysis alone is unreliable. Code that looks unreachable may be called from a different program via CALL.
Generating documentation stubs. AI is reasonably good at generating initial documentation from COBOL source – describing what a program appears to do, listing its inputs and outputs, summarising its main processing steps. The generated documentation will be accurate at the code level. It will miss the business context – why the program does what it does, what business rule it implements, what regulatory requirement it satisfies.
Explaining COBOL syntax. For developers learning COBOL, AI assistants are excellent at explaining syntax, verb usage, and language constructs. They have absorbed enough COBOL documentation to give accurate, helpful explanations of most language features.
Refactoring suggestions. AI can suggest refactoring opportunities – consolidating duplicated logic, simplifying nested EVALUATE structures. These suggestions are often technically correct. Whether to apply them in production requires human judgment about risk tolerance and testing coverage.
Understanding data without copybooks. COBOL programs define their data structures in the DATA DIVISION, but most production COBOL uses COPY statements to include external copybooks – shared data structure definitions that live in separate libraries. A program that says COPY CUSTACCT does not contain the definition of the customer account record – it references it. Any AI analysis of COBOL that does not resolve copybooks is working with incomplete information.
Resolving inter-program dependencies. A COBOL CALL statement invokes another program. In a large mainframe application with hundreds of programs, this dependency graph is complex. A tool that analyses one program at a time cannot tell you what the called program does or whether the data being passed to it is correct.
Inferring business rules from code alone. The most dangerous failure mode. An AI tool reads a specific calculation in a COBOL program and infers what business rule it implements. The inference may be technically correct – the calculation is accurately described. But the business context – why this specific formula, what regulatory requirement mandated it, what exception applies in specific circumstances – is not in the code.
Handling system-specific behaviour. COBOL programs interact with z/OS services in ways that are specific to the mainframe environment – EXEC CICS commands, DB2 EXEC SQL statements, z/OS system calls, SMF record writing. AI tools have varying levels of understanding of these interfaces. Some handle EXEC SQL well. Most have limited understanding of EXEC CICS beyond basic transaction management.
Consider a COBOL program with this data definition:
01 WS-CUSTOMER-RECORD.
COPY CUSTACCT.
The program uses fields from CUSTACCT throughout its logic. An AI tool that only sees the program source sees references to fields it has no definition for. It will make inferences about what those fields probably contain based on their names and how they are used. Those inferences will often be wrong. A field named WS-CUST-BAL might be a balance in dollars, in cents, in basis points, or in some internal coded representation. The copybook definition does tell you. The name alone does not.
Before applying AI analysis to any COBOL program, ensure the tool has access to all copybooks the program uses. Without them, the analysis is built on guesswork dressed up as insight.
Verify AI explanations against runtime behaviour. When an AI tool explains what a COBOL program does, treat it as a hypothesis, not a fact. Verify against runtime evidence – what the program actually produces when it runs, what the SMF records show, what the output datasets contain. Discrepancies between what AI says a program does and what it actually does are usually where the important undocumented business logic lives.
Always provide copybooks. When submitting COBOL for AI analysis, provide the full copybook library, not just the program source. Any tool that does not ask for copybooks is either handling them internally (check how) or ignoring them (treat its output with caution).
Use AI for first pass, human for verification. AI is good for getting oriented in unfamiliar code. It is not reliable enough for making production decisions on its own. Use AI to accelerate the human analysis, not to replace it.
Treat business rule inferences as hypotheses. When AI infers a business rule from COBOL code, write it down as a hypothesis and validate it with someone who knows the business context. This is most urgent for programs that have not been touched in years and whose original authors are no longer available.
Also in this series: Why Generic AI Tools Fail on Mainframe · The Hidden Risk in Every COBOL Migration Project · Why Mainframe is Different