Nearly six years ago at the beginning of the covid-19 pandemic, CNN reported, that there is a shortage of Cobol programmers. As a result the required changes in the New Jersey software responsible for unemployment payouts would take longer then expected. The suggestion was, that Cobol programming can be a very lucrative and “high demand” profession and that young programmers or software engineers, should pick it up.

Ever since we hear a few times a year stories like these: how banks, insurance companies, or legacy manufacturing is still locked into old, unmaintainable software systems, written in Cobol. I remember that even in the 2010s, I would read a few times per year stories like these.

With now coding agents becoming a standard tool for software engineers and contractors, it should actually be pretty easy to work with a codebase written in Cobol, right?

Multiple Cobol dialects

These days, it is pretty common, that a programming language like python or php has basically “one” implementation/dialect, that is open source and maintained by a community. But back in the 1960s and 1970s, this was not the case. Typically, a consortium would publish a specification, and vendors like IBM would release implementations. These implementations however could radically differ from one another, as they would often be extended with additional functionality or features.

Once you have chosen a vendor, you would basically stick with them forever (and I really mean forever, if you would use an IBM dialect in the 1970s, your system today would still be developed in IBM Cobol, as migrating away could mean a major rewrite of your application).

The problem here is: learning the features and the syntax can actually be a challenge, for humans and for coding agents. Nearly all commercially available Cobol compilers cost money, oftentimes multiple thousand of dollars/euros per year. The documentation is not publicly available, unless you purchase the compiler. And on top of that: a specific application, used at a bank or an insurance company, might have been written in an old version of a vendors compiler, that is not even available for sale today. This make “learning Cobol” actually hard, like very hard.

Some people will mention the open source, publicly available GNU Cobol Compiler. The problem here is, the GNU Cobol Compiler is not used in the industry. And it lacks many proprietary features that commercially available compilers have.

The Mainframe Computer

The next big elephant in the room: the mainframe computer. Software systems written in Cobol, do not run on normal servers like the type of software applications that we know. Instead, they run on mainframe computers. Years ago someone on HackerNews, rightfully described the mainframe basically as “alien technology” for your average software engineer. And this person is right. Mainframe computers and their operating systems are nothing, really nothing like Windows, macOS, Linux or BSD.

Your typical vendors here are once again IBM, Fujitsu, Unisys or Hitachi. The operating system running here varies, and while nearly all modern mainframe computers do support Linux or even Windows, they all have their own, proprietary operating system like z/os, AS400 or OS2200.

So writing or maintaining software for mainframe computers not only means that you have to learn the mainframe itself, but also the vendor specific operating system and all of their functions. Imaging wanting to write native running software in C++ or Rust on Linux, without knowing Linux. Good luck with that.

Proprietary Libraries

So you have selected (and learned) your Cobol dialect of choice, got your books on your preferred mainframe operating system at hand. So you are ready to go, you can now start maintaining and writing Cobol apps, right?

Wrong.

Like every software application (be it web, mobile apps or desktop apps), applications written in Cobol also use frameworks and/or libraries. Libraries used here, are like libraries used in any other app: database abstraction, handling auth, providing http functionality, string manipulation etc. However the majority of these libraries are going to be old (as it is common with legacy projects), proprietary (not available to the public), closed source and with bad luck even undocumented, because some were internally created at the organisation (something that back in the day was basically the norm).

Legacy Hell

Any experienced software engineer who has worked with real legacy systems knows, that it requires a lot of experience working in such systems, even with the use of AI and coding agents like Claude Code. You have to be experienced in the technologies you use, be confident in changes (on parts that are really old and undocumented) and you have to be able to navigate the code base.

Like any legacy project, code will be undocumented, code will be badly/confusingly written, there will be a lack of tests and multiple programming paradigms will be present (modern Cobol does support oop). While in 2026 some of these issues can be solved with the help of AI, large code bases, that rely on a language/dialect that are not represented in the AI models training data en mass, are still a challenge for coding agents. And as these type of applications are mission-critical, the human engineer should definitely have a good understanding of the code base and project.

And it does not stop here: the knowledge one needs to have is not only technical. At the end of the day, Cobol applications are business applications, trying to solve business problems. In case of banking or insurance software this means, a lot of laws, regulations, rules etc.

How to actually get started

If you really want to work on Cobol projects, you have to become an expert in the technologies involved around Cobol itself. This will also require you, to specialize (at least for the beginning) in one of the vendors dialect of Cobol.

The best option, in my opinion, is to join a consulting/contracting company and start working from there. While you can teach yourself a lot of things in regard to computer science and software engineering, the nature of mainframe computing, its oddness and general unfamiliarity and most likely the lack of the required hardware and software, will make it either impossible or expensive to do on your own.

Keep in mind, that at this point, we are talking about you specializing in this niche. So pivoting into another area of software engineering later in your career might be hard. But of course there are plenty of interesting and lucrative problems to solve in this niche.