The Evolution of COBOL Development: From Green Screens to AI
Pat Stanard, Distinguished Engineer and Chief Mainframe Architect for Kyndryl US, looks at how the COBOL developer experience has changed, from punched cards and batch jobs to VS Code and AI assistants
COBOL has been around for a long time … in fact, a really long time. I’ve gone from long hair to white hair, to no hair. In technology years, COBOL is less like a programming language and more like a geological formation. Yet while countless “next big things” have appeared, disappeared and been replaced by another next big thing, COBOL is still quietly processing important business transactions every day. It continues to exist in the background, just doing its thing. In fact, most people don’t even know it’s there.
That is because COBOL, or Common Business-Oriented Language, was designed to do something businesses desperately needed: process lots of information accurately and reliably. Banks, insurance companies, retailers, airlines and governments built enormous systems around it. Many of those systems worked so well that organizations are still running them today. The problem is that most people who originally learned to code in COBOL have long retired and the skill has dwindled.
Even if you don’t work on the core mission-critical systems where COBOL is the norm, there’s a pretty good chance the language has been involved somewhere in your daily life. Withdraw cash from an ATM, make a banking transaction, file a government form, submit an insurance claim or receive a healthcare bill, and a COBOL application may be somewhere behind the scenes. The funny part is that you never see it.
The mobile app might have beautiful graphics, facial recognition and an AI chatbot, while somewhere deep in the company a COBOL program written decades ago is quietly doing the important work. COBOL is a little like the plumbing in a skyscraper: Nobody talks about it when everything works, but everybody notices when it doesn’t.
What has changed dramatically isn’t necessarily COBOL itself, but rather the world around us.
The Old Days: Code, Submit, Wait
In the traditional mainframe world, programming COBOL required more than knowing the language. You needed to understand the entire neighborhood.
A programmer might write a COBOL program, compile it, create the necessary JCL, submit a batch job and then patiently wait to see what happened. If the job failed, it was time to examine the output, find the return code, study the dump and figure out what went wrong. This took time. Then you fixed it and did it all over again. And this took time. Additionally, I started my COBOL programming experience using the famous Herman Hollerith 80-column punched cards. That is now a museum exhibit.
Believe me, there was no friendly AI assistant popping up and saying, “It looks like you forgot something on line 347.”
Instead, the mainframe essentially said: “ABEND.” Good luck …
Experienced COBOL programmers therefore became experts in much more than COBOL. They understood technologies such as JCL, CICS, DB2, VSAM and z/OS. They also developed an impressive ability to look at pages of output and somehow know exactly what went wrong. When you spent a long time with COBOL development, it became an extension of your brain.
It was practically a superpower.
The Other Challenge: ‘Who Wrote This?’
Many COBOL applications also grew over decades. One programmer wrote the original system. Another added something five years later. Someone else changed it 10 years after that. Eventually, you could encounter code containing business logic that everyone knew was important, but nobody could explain exactly why it was there. The programmer who originally wrote it is probably retired. The documentation … hopefully somewhere if you are lucky. I also knew it was important to utilize comments to make sure your application was internally documented. This allowed future developers to understand what you were doing.
One of the most important rules of maintaining older applications became: Don’t touch anything unless you understand what it does. That wasn’t resistance to modernization. It was survival. When the code was developed, the logic was in the mind of the developer.
Today: COBOL Meets Modern Development
Modern COBOL development can look very different.
Developers can work in graphical development environments instead of relying entirely on traditional terminal interfaces. Source code can be managed through Git-based repositories. Teams can perform code reviews, track changes and integrate COBOL development into DevOps processes.
Automated pipelines can help compile, test and deploy applications. Modern debugging tools can make finding problems easier. APIs can expose functions running on the mainframe to applications running elsewhere.
Instead of developing COBOL primarily through a traditional green-screen environment, a developer today can use tools such as IBM Developer for z/OS on Visual Studio Code. The experience looks much more like modern software development, with intelligent editing, source navigation, debugging, Git-based workflows and integration with the mainframe. Many of our universities use Visual Studio Code as a framework for modern language development. I have taught university mainframe classes using VS Code for years.
In other words, the COBOL developer doesn’t necessarily have to live permanently behind a green screen anymore. It is now a “point and click” environment. After all, that is what we have been teaching our students for a long time now. As a university professor, I saw students initially have issues using ISPF and TSO until they understood it.
And Then AI Showed Up
Perhaps the most interesting change is AI. AI-assisted development tools can help developers understand unfamiliar programs, explain sections of code, create documentation and identify relationships between applications.
Consider what that means for a COBOL application that has been running for 30 or 40 years. Instead of a new developer staring at thousands of lines of unfamiliar code and wondering, “What the heck does this program do?” AI can help accelerate the process of understanding it. That doesn’t mean AI should automatically rewrite decades of business logic while everyone goes to lunch. Human knowledge, testing and governance remain essential, but AI can become an extremely useful assistant. It is a huge time saver today.
A good example is IBM watsonx Code Assistant for Z (or IBM Bob). A COBOL developer can use generative AI to help understand existing programs, generate or modify COBOL code, refactor and assist with modernization. Instead of spending hours trying to figure out what a 30-year-old program is doing, AI can give the developer a head start. Think of it as adding a new COBOL programmer to the team who reads very fast and never complains about the old code. That new COBOL programmer understands the logic immediately.
Modernization Doesn’t Mean ‘Delete COBOL’
One of today’s biggest differences is how companies think about modernization. Years ago, modernization discussions sometimes started with: “How do we get off this mainframe?”
Today, a smarter question is: “What should we modernize, and why?” Sometimes the best answer is to leave a proven COBOL application exactly where it is. If it processes millions of transactions reliably and economically, replacing it simply because it is old may introduce more risk than value. Other applications might benefit from APIs, better user interfaces, cloud integration, automation or AI capabilities. Still others may make sense to refactor or rewrite. Modernization should therefore be a business decision, not a birthday party for the application.
Old doesn’t automatically mean bad. I was talking to an old friend of mine last year and he had come across a COBOL application that I had written for a major corporation over 30 years ago that was still running just fine. I am sure it had since been recompiled a few times but still running like clockwork.
Some Things Haven’t Changed
Despite all these new tools, the fundamental expectations haven’t changed much. If a system moves money between bank accounts, calculates an insurance payment or processes a business transaction, it still needs to be correct. Customers don’t care whether the application was written using COBOL, Java, Python or something invented last Tuesday. The customer just wants it to work.
Reliability, security, performance and data integrity mattered decades ago, and they still matter today. The difference is that the work may be done by AI instead of a human, but there should always be a human in the loop as a guardrail.
From Green Screens to AI
The real evolution of COBOL isn’t simply old COBOL versus new COBOL. It is about everything surrounding the language. Yesterday’s COBOL programmer relied heavily on specialized mainframe knowledge, terminal-based tools and years of experience. Today’s programmer can combine that same mainframe knowledge with modern IDEs, Git, DevOps, automation, APIs and AI-assisted development. For today’s programmer this is a pure gamechanger and a necessity for modern code development.
And perhaps there is a lesson in COBOL’s longevity. Technology constantly tells us that something new is about to replace everything that came before it. COBOL has quietly watched many of those technologies arrive with enormous excitement and disappear just as quickly. Meanwhile, COBOL keeps processing transactions, and my 30-year-old COBOL application continues to execute.
So, the next time someone says COBOL is dead, somewhere a mainframe programmer will probably smile, submit a job and get back to running a sizeable portion of the world’s business. Hopefully without an ABEND.