There is a persistent stereotype about mainframe developers.
It usually involves an ageing COBOL programmer, a green-screen terminal and a technology environment disconnected from the rest of modern software engineering.
That stereotype was always simplistic.
In 2026, it is increasingly wrong.
Mainframe development still requires specialist knowledge. COBOL, JCL, CICS, Db2, IMS and z/OS remain important skills in many organisations.
But the development environment around those technologies has changed considerably.
A mainframe developer today may be working in Visual Studio Code, using Git, interacting with APIs, building CI/CD pipelines, writing Java alongside COBOL and using automation tools that would look familiar to any other enterprise software engineer.
IBM’s current Z Open Editor, for example, provides COBOL, PL/I, assembler, REXX and JCL support directly inside VS Code, with features including syntax checking, navigation, code completion and Git integration.
That does not make the mainframe ordinary.
But it does make the old distinction between “mainframe developers” and “modern developers” much less useful than it once was.
The green screen is no longer the whole story
Traditional mainframe development environments such as ISPF remain widely used and valuable.
But they are no longer the only option.
IBM now actively supports z/OS development through VS Code-based tooling. IBM Developer for z/OS on VS Code includes extensions such as Z Open Editor, Zowe Explorer, code coverage and debugging capabilities.
That means a developer can work with COBOL while using an editor and workflow that already feels familiar from JavaScript, Python, Java or cloud development.
This matters more than it might seem.
Tooling is part of how engineers form their expectations about a platform.
If joining a mainframe team means abandoning Git, modern editors, automated testing and familiar developer workflows, the platform immediately feels separate from the rest of engineering.
If the same engineer can open VS Code, clone a Git repository and work with familiar navigation, debugging and source-control patterns, the transition becomes much less intimidating.
The technology underneath is still different.
The developer experience does not have to be.
Git changes the development model
Source control is one of the clearest examples.
Historically, many mainframe environments developed their own workflows around platform-specific source management systems.
Modernisation increasingly means bringing mainframe application development into the same Git-centric engineering practices used elsewhere.
IBM’s own Z DevOps guidance explicitly describes the broad adoption of Git and promotes flexibility in IDE choice for z/OS developers.
The significance goes beyond where source code is stored.
Git-based workflows make practices such as these more natural:
- feature branches
- pull requests
- peer review
- automated builds
- automated testing
- release pipelines
- traceability
- integration with enterprise DevOps platforms
That makes mainframe software easier to include in a common enterprise delivery model.
Instead of having “the mainframe process” and “the modern application process,” organisations can increasingly apply similar engineering principles across both.
A mainframe developer may not primarily write COBOL
COBOL remains central to the mainframe ecosystem.
But it is increasingly misleading to treat COBOL programming and mainframe development as the same thing.
An IBM Z application environment can involve:
- COBOL
- Java
- PL/I
- assembler
- Python
- shell scripting
- APIs
- SQL
- JCL
- JavaScript or front-end technologies consuming mainframe services
The relevant developer may spend much of their time building services around an established COBOL application rather than modifying the core application itself.
A Java developer might create an API that exposes an existing CICS transaction.
A DevOps engineer may automate the build and deployment process.
A platform engineer may integrate z/OS tooling into enterprise CI/CD.
A security engineer may work on identity and access around the same applications.
The mainframe developer population therefore increasingly overlaps with the broader enterprise engineering organisation.
APIs changed the boundary
One of the biggest shifts in enterprise architecture has been the move toward exposing established systems through APIs.
That allows mainframe applications to participate in modern architectures without necessarily being rewritten.
A decades-old transaction system can remain largely intact while new web, mobile, cloud and partner services access its capabilities through modern interfaces.
This changes the skills required around the platform.
Developers need to understand not only the underlying application but also:
- API design
- service integration
- authentication
- data formats
- observability
- distributed failure modes
- performance across system boundaries
That is a very different profile from the stereotype of someone maintaining an isolated COBOL program.
It also means mainframe knowledge becomes valuable to teams that may not consider themselves mainframe teams at all.
DevOps increasingly includes z/OS
The phrase “mainframe DevOps” would once have sounded contradictory to some development teams.
It now describes a serious and established area of enterprise engineering.
Modern z/OS development can include automated build processes, unit testing, code quality checks, deployment pipelines and Git-driven workflows.
IBM’s current DevOps guidance for Z explicitly supports both Eclipse-based and VS Code-based environments and describes Git as part of modern source-management workflows.
This does not mean every enterprise has fully modernised its software-delivery process.
Many have not.
Legacy build processes and manually operated release workflows still exist.
But that is increasingly an organisational choice rather than an unavoidable property of the mainframe.
The platform is capable of participating in a modern development lifecycle.
Younger developers are entering the ecosystem
The other part of the stereotype is demographic.
There is a real concern about experienced mainframe professionals retiring, and enterprises continue to report difficulty finding certain combinations of skills.
But that does not mean the platform is populated only by people nearing retirement.
Research commissioned by IBM, Broadcom and 21CS in 2024 found substantial hiring demand for both experienced and early-career mainframe professionals. Among surveyed employers, 51% were recruiting for entry-level positions and 79% for mid-career roles, while 91% expected to recruit for new mainframe positions over the following one to two years.
The same research found that 75% of surveyed university leaders said their institution offered curricula through which students could learn mainframe skills.
That does not eliminate the skills gap.
But it does challenge the idea that nobody new is entering the field.
The mainframe workforce is changing rather than simply disappearing.
The barrier is often perception
For younger developers, the word “mainframe” can carry assumptions before they have seen the technology.
They may imagine:
- obsolete languages
- poor tooling
- little career mobility
- maintenance-only work
- systems waiting to be retired
Those assumptions influence recruitment.
Yet many mainframe teams work on precisely the problems that attract experienced engineers elsewhere:
- high-scale transaction processing
- distributed integration
- performance optimisation
- security
- reliability
- data architecture
- automation
- mission-critical systems
The difference is that the systems may have a much longer history and considerably less tolerance for failure.
For some engineers, that makes the work more interesting rather than less.
Modern tools do not remove the need for specialist knowledge
There is a danger in taking the opposite argument too far.
Mainframe development has not become “just like everything else.”
It has not.
A developer using VS Code to edit COBOL still needs to understand COBOL.
Git does not explain how CICS works.
An API does not remove the need to understand the transaction behind it.
A CI/CD pipeline does not automatically reveal the operational assumptions built into a system over thirty years.
Modern tooling reduces friction.
It does not eliminate platform knowledge.
This distinction matters because organisations sometimes assume that changing the development interface solves the skills problem.
It helps, but the deeper challenge is knowledge.
The valuable developer is increasingly hybrid
The most useful mainframe engineers are increasingly people who can operate across boundaries.
That might mean someone who understands COBOL and Java.
Or mainframe application logic and APIs.
Or z/OS operations and DevOps automation.
Or legacy systems and cloud integration.
The combination matters because modernisation projects rarely remain contained entirely within one platform.
An application may stay on IBM Z while exposing services to cloud applications.
Its data may be consumed by analytics platforms.
Its development workflow may be managed through GitHub or another enterprise DevOps platform.
Its security model may need to integrate with organisation-wide identity systems.
The developer who understands both sides of those boundaries becomes extremely valuable.
Deep business knowledge still matters
There is also another dimension that is easy to overlook.
Experienced mainframe developers often understand far more than the technology.
They understand the business.
A developer who has maintained an insurance system for fifteen years may know why specific policy rules exist.
A banking engineer may understand transaction-processing behaviour that was never completely documented.
That knowledge does not appear automatically when a new developer learns COBOL syntax.
This is why workforce transition has to involve mentoring rather than simple replacement.
The goal is not merely to teach younger developers how to compile a program.
It is to transfer enough technical and business context that they can safely change systems the organisation depends on.
AI will change the job again
AI-assisted development is likely to make the boundary even less clear.
Tools that explain unfamiliar code, generate documentation, help identify dependencies and assist with testing could make large legacy codebases easier for new engineers to approach.
That is especially relevant to COBOL environments where application knowledge may be concentrated among a relatively small number of specialists.
But AI does not eliminate the need for experienced developers.
A model may explain what a section of code appears to do.
It cannot necessarily know why the organisation decided that behaviour was required or what obscure downstream process depends on it.
The practical opportunity is therefore to use AI to reduce the cost of learning.
That could help a Java or cloud engineer become productive in a mainframe environment more quickly.
It should not be confused with removing the need for mainframe expertise.
What employers should change
If organisations want to attract a new generation of mainframe developers, recruitment messaging needs to catch up with reality.
A job description focused entirely on decades of platform-specific experience will naturally produce a narrow candidate pool.
Instead, employers can look for transferable engineering skills.
A strong Java developer may become a strong IBM Z developer.
A DevOps engineer can learn z/OS deployment practices.
A cloud engineer who understands APIs and distributed systems may bring useful skills to hybrid modernisation.
Organisations should therefore ask:
Which knowledge genuinely needs to exist on day one?
and:
Which knowledge can we teach?
That is a much healthier workforce strategy than trying to replace every retiring expert with an identical younger version.
Modernise the developer experience as well as the application
Many organisations talk about application modernisation while leaving the development experience untouched.
That is a mistake.
If a company wants engineers to maintain critical systems for another twenty years, the environment in which those engineers work matters.
That means investing in:
- modern editors
- Git-based source control
- automated testing
- CI/CD
- usable development environments
- good documentation
- code search and navigation
- accessible training
- mentoring
IBM’s Z Open Editor illustrates how far this has already moved. It provides modern language-server capabilities for enterprise languages inside VS Code, including navigation, code completion, reference searching and refactoring support.
Those capabilities are not cosmetic.
They affect how quickly engineers can understand unfamiliar applications.
The stereotype creates its own skills problem
Perhaps the most damaging thing about the old mainframe-developer stereotype is that it can become self-fulfilling.
If organisations present the platform as a technological museum, fewer young developers will want to work with it.
If they fail to modernise development workflows because “mainframe developers are used to doing it this way,” they reinforce the perception that the platform is disconnected from modern engineering.
And if they recruit only people who already possess highly specific legacy skills, they continually shrink the potential talent pool.
The alternative is to treat mainframe engineering as part of the wider software-engineering profession.
Specialist knowledge still matters.
But the platform does not need to be isolated culturally or operationally from the rest of technology.
The modern mainframe developer is still a developer
The biggest mistake may be thinking of mainframe developers as a separate species.
They are software engineers working on a particular class of systems.
Those systems happen to be unusually durable, unusually important and often unusually complex.
Some developers will specialise deeply in COBOL, CICS or z/OS.
Others will arrive through Java, DevOps, APIs, cloud integration, security or automation.
Increasingly, successful teams will contain both.
The green screen has not disappeared.
Neither has COBOL.
But neither defines the whole profession anymore.
The mainframe developer stereotype is out of date because mainframe development itself has changed.
And for enterprises trying to solve the skills problem, recognising that may be one of the most useful changes they can make.
