COBOL Vibe Coding – Really??
Introduction
It all started with a message in a friends’ WhatsApp group.
I have a group chat with old friends and ex‑colleagues. We all worked together years ago, and while everyone else moved on to other companies in the industry, I’m the only one still deep in COBOL code modernization. Naturally, whenever someone sees a post about COBOL or the mainframe, they send it to the group to taunt me.
This time it was this post on LinkedIn, by Ibon Urrutia
It was interesting timing, because I had just finished reading this viral article from Matt Shumer , warning that rapidly accelerating AI advances are already reshaping technical work and will soon disrupt many more professions.
As I was thinking about what this means for my life, my kids’ education, my career and even my investments, a question popped into my mind:
Could it be that with all the advancements in AI, especially in coding, COBOL and mainframe systems will somehow remain unaffected?
Rather than dive into philosophical or technical discussions, I decided to try it myself and document the experience: COBOL Vibe Coding.
I’m actually a good test case. My development background isn’t in COBOL. During my B.Sc. in Computer Science, I used C, C++, C# and Java, which were also the languages I worked with professionally. I can read COBOL and understand it, I can write COBOL, but I’ve never written COBOL “in anger” nor maintained a mainframe application. I do understand software architecture, design patterns, and enterprise software maintenance. In other words: a typical developer but not an expert COBOL developer.
The Software Stack
I used a modern development environment based on the latest Rocket Enterprise Developer product, working with both Visual Studio and VS Code. Enterprise Developer also includes Rocket Enterprise Server which allowed me to run, test, and debug my CICS application.
Visual Studio was easier for compiling, building, deploying, and debugging the BANKDEMO application, possibly just because I used to be part of the team that developed Enterprise Developer for Visual Studio back in the day. I’ve been using Visual Studio since Visual C++ 6.0, so there’s definitely some personal convenience involved.
I used VS Code for the actual “Vibe Coding”, leveraging GitHub Copilot’s native integration and the Claude Sonnet 4.5 model in Agent mode.
The application itself is the BANKDEMO sample, found here: https://github.com/RocketSoftwareCOBOLandMainframe/BankDemo
I forked the repository and included my changes here: https://github.com/GuySo1/BankDemo
TL;DR
I’ll get into the technical details shortly, but here’s the bottom line:
I was genuinely surprised by the quality of the output. Not perfect, but what would have taken me all day, took less than an hour.
I tried three tasks:
All three were completed without writing a single line of code myself.
So before diving in, keep this question in mind:
If AI coding assistants can already do this with minimal human intervention, how relevant will the “COBOL skills challenge” be in 2–3 years?
Refactoring a utility program for date conversion
I started with something simple. BANKDEMO contains a utility program for date conversion: UDATECNV.cbl .
Looking at the code, I immediately saw opportunities for refactoring, including replacing custom logic with intrinsic functions for better safety, maintainability, and efficiency.
I simply asked Claude to modernize the program. No tricks, no special instructions.
It responded with a fully refactored program in about three minutes.
I was skeptical, so I hit F5 in Visual Studio, which compiled, deployed, and started debugging against my running region.
No compilation errors.
The application worked exactly as before.
Dates were correct.
I even stepped through the new code to confirm it was actually running.
That was surprisingly smooth. Next task!
Adding a brand new 3270 screen to the application, including navigation logic
For the next experiment, I wanted brand-new code, both COBOL and BMS.
The prompt:
Recommended by LinkedIn
“I would like to add another option to the main menu: General Information. It'll navigate to a new screen which outlines some general information about the bank: Year of establishment, number of employees, CEO name, etc.”
Claude generated the BMS, updated the business logic layer, and wired most things up.
But it missed something important.
BANKDEMO’s architecture has three layers: presentation, business logic, and data. Claude created the business logic and BMS but did not create the presentation layer program.
BANKDEMO technical architecture – Taken from Rocket Enterprise Analyzer
Humans: 1 Machines: 0
Trying to navigate to the new screen resulted in the expected ABEND.
Debugging confirmed the missing piece: an EXEC CICS LINK to a non‑existent SBANK95P program.
I pointed this out:
“Don't we also need sbank95p screen logic program created?”
Claude generated it. I built again, connected via TN3270 and…
A new General bank information option in the main menu:
And a new screen:
Some minor layout snags, but functionally correct.
Adding new functionality and UI to an existing screen
Finally, this was just a static new screen and copying of common patterns from other examples in the repository. I wanted to see how well it handles modifying existing UI and logic.
This is a loan calculation screen:
I will ask Claude to add another line which will display the total cost of the loan over the term.
The prompt:
“Now I want to add the total loan cost as an additional field in the loan calculator screen”
I didn’t say anything about where the loan calculator screen is and where its logic is and sent it to figure it out and implement.
Not bad! It did everything right. I only needed to fix a small compilation error as it didn’t respect the margins in one of the data item redefinitions:
After fixing that, I built, tested and everything worked exactly as expected:
Conclusion
After a few hours of “COBOL Vibe Coding”, one thing is clear: AI is no longer just helping with modern languages, it’s already boosting productivity in places many thought were untouchable. The models aren’t perfect, but they’re fast, reliable enough and getting better at an incredible pace. If they can refactor utilities, add screens and implement logic today with minimal help, imagine what’s coming next.
It might not eliminate the COBOL skills gap today but perhaps make it far less important in the coming years.
Agree? Disagree? I’d love to hear where you stand, drop your take in the comments
I repeat: it was a joke!! https://www.garudax.id/posts/ibonurrutia_shay-boloor-stocksavvyshay-on-x-share-7431805014521692162-ZTV4?utm_source=share&utm_medium=member_android&rcm=ACoAAADpe4cBCLVMZamg4L8V5tBzAeaQZj0QRFg
Diego Fraiese ni siquiera lo han intentado 😁 a ver, tú puedes entrenar máquinas para hacer lo que tú sabes hacer. Lo harán mejor que tú, pero nada más. Deep Blue jugaba tan bien como kasparov pero no fue usada para crear nuevas aperturas, juego medio o finales en ajedrez. Nada nuevo. Pero Kasparov no perdió su trabajo. Tú no puedes entrenar una máquina para curar el cáncer si tu no sabes como se cura el cáncer. Así de simple. No creo que es hype. Creo que nunca pretendieron AI o la cura del cáncer. Esto es un ataque de fuerza bruta a cualquier trabajo en una empresa. Reducir costes, despidiendo trabajadores. No va a crear puestos de trabajo porque esos LLM entrenados no está creando nada NUEVO ni en software, video, música o cualquier otra cosa en las que lo entrenes. Van a crear el mayor desempleo desde 1929 y cuatrillonarios fascistas. Cual crees que será el siguiente paso? El problema no es que sea hype. Es que creo que no lo es, aunque sea una mentira.
Great article, thanks for sharing. I recently worked on a modernization effort involving CA-Proterm, which the customer used to perform CICS screen-scraping from batch jobs. Proterm scripts were submitted as control cards with rich syntax — including file open/read/write/close — in addition to driving CICS BMS screens. A typical workflow: read a file of SKU numbers and update multiple CICS screens in batch. To modernize this, we leveraged the open-source x3270 project to interact with CICS: - The s3270 library was exposed through a C wrapper - The wrapper was invoked from COBOL - Proterm control cards were converted into COBOL programs calling s3270 APIs - The behavior mirrored the original Proterm screen-scraping The compelling part: ~150 Proterm control cards were converted into COBOL programs in about a week, largely accelerated using GitHub Copilot, with only minor refinements needed. A key enabler was feeding the model the CA-Proterm coding manual, helping it understand the proprietary scripting syntax and translate it into COBOL logic. This reinforced that foundational models are strong in COBOL patterns — and when augmented with domain documentation, they can significantly accelerate structured legacy transformations.
I will always be here to "taunt".. 😎
Never in my life I thought that my joke was going to make anyone run a experiment 😂😂😂 So yeah the LLMs also have been trained in COBOL. Good bye to my salvation plan in the software engineering apocalypse. I have another hypothesis that I can stop sharing and thinking on it. What if what we are calling intelligence is in reality Montecarlo simulations of LLMs trained in code repositories that sometimes converge without human intervention to solution (compilation pass and does what asked), sometimes do not converge to solution and we need to run it again with some new input parameter or modifying the prompt and sometimes do not converge at all and returns BS? But I do not know how to prove it. But I'm pretty sure that this agents do not understand COBOL.