Ask HN: COBOL devs, how are AI coding affecting your work?

[zkid18]

Curious to hear from anyone actively working with COBOL/mainframes. Do you see LLMs as a threat to your job security, or the opposite?

I feel that the mass of code that actually runs the economy is remarkably untouched by AI coding agents.

[alexpham14]

Compliance is usually the hard stop before we even get to capability. We can’t send code out, and local models are too heavy to run on the restricted VDI instances we’re usually stuck with. Even when I’ve tried it on isolated sandbox code, it struggles with the strict formatting. It tends to drift past column 72 or mess up period termination in nested IFs. You end up spending more time linting the output than it takes to just type it. It’s decent for generating test data, but it doesn't know the forty years of undocumented business logic quirks that actually make the job difficult.

[apaprocki]

To be fair, I would not expect a model to output perfectly formatted C++. I’d let it output whatever it wants and then run it through clang-format, similar to a human. Even the best humans that have the formatting rules in their head will miss a few things here or there.

If there are 40 years of undocumented business quirks, document them and then re-evaluate. A human new to the codebase would fail under the same conditions.

[akhil08agrawal]

Nuances of a codebase are the key. But I guess we are accelerating towards solving that. Let's see how much time will this take.

[OGWhales]

I've not found it that great at programming in cobol, at least in comparison to its ability with other languages it seems to be noticeably worse, though we aren't using any models that were specifically trained on cobol. It is still useful for doing simple and tedious tasks, for example constructing a file layout based on info I fed it can be a time saver, otherwise I feel it's pretty limited by the necessary system specifics and really large context window needed to understand what is actually going on in these systems. I do really like being able to feed it a whole manual and let it act as a sort of advanced find. Working in a mainframe environment often requires looking for some obscure info, typically in a large PDF that's not always easy to find what you need, so this is pretty nice.

[deaddodo]

AI isn’t particularly great with C, Zig, or Rust either in my experience. It can certainly help with snippets of code and elucidate complex bitwise mathematics, and I’ll use it for those tedious tasks. And it’s a great research assistant, helping with referencing documentation. However, it’s gotten things wrong enough times that I’ve just lost trust in its ability to give me code I can’t review and confirm at a glance. Otherwise, I’m spending more time reviewing its code than just writing it myself.

[soco]

There's such a huge and old talk about the death of COBOL coding/coders that I find it very surprising that nobody trained a model to help with exactly that.

[brightball]

Heard an excellent COBOL talk this summer that really helped me to understand it. The speaker was fairly confident that COBOL wasn't going away anytime soon.

https://www.youtube.com/watch?v=RM7Q7u0pZyQ&list=PLxeenGqMmm...

[rramadass]

Both Fortran and COBOL will be here long after many of the current languages have disappeared. They are unique to their domains viz. Fortran for Scientific Computing and COBOL for Business Data Processing with a huge amount of installed code-base much of it for critical systems.

[TacticalCoder]

There are many in-house tools (say at banks) where Java code generates... COBOL. It's wild: in the video you linked it's explained COBOL was meant for machines that don't exist anymore so COBOL is running inside emulators.

So you have Java code, generating COBOL code, that's then run on an emulator emulating an old IBM system that was meant to run COBOL. It's just wild.

Some of the tools are even front-facing users (bank employees): at times you can still see at some banks an employee running an app in a monochrome green-on-black text terminal emulator that is basically COBOL.

It's weird, just weird. But legacy code is legacy code. And if you think COBOL's legacy is bad, Java is going to dwarf COBOL's legacy big times (for Java is typically used at the kind of places that still use COBOL and it's used way more than COBOL).

So in the future, heck, we may have a new language, generating, inside an emulator emulating current machines/OSes, Java code that is going to be code generating COBOL code (!), that's then going to be run in an emulator.

[christophilus]

First of all, that conference is right down the road from me, and I never knew about it. So, thanks for sharing!

My first job was working at a credit union software company. I designed and built the front-end (windows applications, a telephone banking system, and a home-banking web thing) and middle-tier systems (VB.NET-based services). The real back-end, though, was an old COBOL system.

I remember helping the COBOL programmers debug some stuff, and it was just so wildly foreign. My degree is in theoretical comp sci, and I'd seen a lot of different languages, including Prolog, various lisps and schemes, SQL, ADA, C++, C, Pascal, various assembly variants, but COBOL was simply unique. I've often wondered what ideas COBOL got right that we could learn from and leverage today in a new language.

I do remember our COBOL mainframes were really fast compared to the SQL Server layers my middle-tier services used, but I also remember looking at it and thinking it would be a giant pain to write (the numbers at the front of every line seemed like tedium that I would probably often get wrong).

[pixl97]

In my experience working with large financial institutions and banks, there is plenty of running COBOL code that is around the average age of HN posters. Where as a lot of different languages code is replaced over time with something better/faster COBOL seems to have a staying power in financial that will ensure it's around a very very long time.

[edarchis]

Not COBOL but I sometimes have to maintain a large ColdFusion app. The early LLMs were pretty bad at it but these days, I can let AI write code and I "just" review it.

I've also used AI to convert a really old legacy app to something more modern. It works surprisingly well.

[hmaxwell]

I feel like people who can't get AI to write production ready code are really bad at describing what they want done. The problem is that people want an LLM to one shot GTA6. When the average software developer prompts an LLM they expect 1) absolutely safe code 2) optimized/performant code 3) production ready code without even putting the requirements on credential/session handling.

You need to prompt it like it's an idiot, you need to be the architect and the person to lead the LLM into writing performant and safe code. You can't expect it to turn key one shot everything. LLMs are not at the point yet.

[0xCE0]

I really wouldn't want any vibe-coded COBOL in my bank db/app logic...

[egorfine]

vibecoding != AI.

For example: I'm a senior dev, I use AI extensively but I fully understand and vet every single line of code I push. No exceptions. Not even in tests.

[null_deref]

Does the use AI always implies slope and vibe coding? I’m really not sure

[shevy-java]

How many banks really use COBOL? Here in central Europe it seems to be Java, Java, Java for the most part. Since many years actually.

[ironbound]

Management loves trying to save money, a bunch of grads with AI have differently had a project to try to write COBOL!

[randomsc]

I am working as a Software engineer in a European bank. There is a huge multi year program to remove COBOL as much as possible with cloud based Java Spring application.

The main reason is maintainability. There is no more cobol developers coming. Existing ones close to retirement or already retired.

[sai18]

You’re describing the pattern we’re seeing across most companies who are still on COBOL.

The shortage of COBOL engineers is real but the harder problem is enterprise scale system understanding. Most modernization efforts stall not because COBOL is inherently a difficult language, but because of the sheer scale and volume of these enterprise codebases. It's tens of thousands of files, if not millions, spanning 40+ years with a handful of engineers left or no one at all.

We're exploring some of this work at Hypercubic (https://www.hypercubic.ai/, YC-backed) if you're curious to learn more.

With the current reasoning models, we now have the capability to build large scale agentic AI for mainframe system understanding. This is going beyond line-by-line code understanding to reason across end-to-end system behavior and capturing institutional knowledge that’s otherwise lost as SMEs retire.

[BoredPositron]

Found the atruvia employee ;D

[BoredPositron]

I am in banking and it's fine we have some finetuned models to work with our code base. I think COBOL is a good language for LLM use. It's verbose and English like syntax aligns naturally with the way language models process text. Can't complain.

[repelsteeltje]

Can you elaborate? See questions about what kind of use in sibling thread.

And in addition to the type of development you are doing in COBOL, I'm wondering if you also have used LLMs to port existing code to (say) Java, C# or whatever is current in (presumably) banking?

[zkid18]

What these models are doing - migrations, new feature releases, etc? What does your setup look like?

[andy99]

There was a COBOL LLM eval benchmark published a few years ago, looks like it hasn’t been maintained: https://github.com/zorse-project/COBOLEval

At least I think that’s the repo, there was an HN discussion at the time but the link is broken now: https://news.ycombinator.com/item?id=39873793

[Waffle2180]

I’m not a full-time COBOL dev, but I’ve worked adjacent to mainframe systems (bank integrations, legacy batch jobs, and data pipelines).

From what I’ve seen, LLMs aren’t really a threat to COBOL roles right now. They can help explain unfamiliar code, summarize programs, or assist with documentation, but they struggle with the things that actually matter most: institution-specific conventions, decades of undocumented business logic, and the operational context around jobs, datasets, and JCL.

In practice, the hardest part isn’t writing COBOL syntax, it’s understanding why a program exists, what assumptions it encodes, and what will break if you change it. That knowledge tends to live in people, not in code comments.

So AI feels more like a force multiplier for experienced engineers rather than a replacement. If anything, it might reduce the barrier for newer engineers to approach these systems, which could be a net positive given how thin the talent pool already is.

[m3h_hax0r]

I wonder if the OP's question is motivated by there being less public examples of COBOL code to train LLM's on compared to newer languages (so a different experience is expected), or something else. If the prior, it'd be interesting to see if having a language spec and a few examples leads to even better results from an LLM, since less examples could also mean less bad examples that deviate from the spec :) if there are any dev's that use AI with COBOL and other more common languages, please share your comparative experience

[pixl97]

Most COBOL I know of won't ever see the light of day.

Also COBOL seems to have a lot of flavors that are used by a few financial institutions. Since these are highly proprietary it seems very unlikely LLMs would be trained on them, and therefore the LLM would not be any use to the bank.

[cmrdporcupine]

Given the mass of code out there, it strikes me it's only a matter of time before someone fine tunes one of the larger more competent coding models on COBOL. If they haven't already.

Personally I've had a lot of luck Opus etc with "odd" languages just making sure that the prompt is heavily tuned to describe best practices and reinforce descriptions of differences with "similar" languages. A few months ago with Sonnet 4, etc. this was dicey. Now I can run Opus 4.5 on my own rather bespoke language and get mostly excellent output. Especially when it has good tooling for verification, and reference documentation available.

The downside is you use quite a bit of tokens doing this. Which is where I think fine tuning could help.

I bet one of the larger airlines or banks could dump some cash over to Anthropic etc to produce a custom trained model using a corpus of banking etc software, along with tools around the backend systems and so on. Worthwhile investment.

In any case I can't see how this would be a threat to people who work in those domains. They'd be absolutely invaluable to understand and apply and review and improve the output. I can imagine it making their jobs 10x more pleasant though.

[pixl97]

> competent coding models on COBOL

Which COBOL... This is a particular issue in COBOL is it's a much more fragmented language than most people outside the industry would expect. While a model would be useful for the company that supplied the data, the amount of transference may be more limited than one would expect.

[anticensor]

COBOL migration is one of Devin's advertised capabilities:

https://docs.devin.ai/use-cases/examples/cobol-modernization https://cognition.ai/blog/infosys-cognition

[DANmode]

Wait - whoever is downvoting this, could you please also explain why?

I’m looking at a signal with no way to validate it (that this person may be biased?, exaggerating?, or lying?).

Stop downvoting without replying - it’s really unhelpful.

[petercooper]

I'm not in the COBOL world at all, but when I saw IBM putting out models for a while, I had to wonder if it was a byproduct of internal efforts to see if LLMs could help with the supposedly dwindling number of legacy mainframe developers. I don't know COBOL enough to be able to see if their Granite models are particularly strong in this area, though.

[kajolshah_bt]

I’ve seen AI help with COBOL only after the system is well understood. When specs are fuzzy or tribal knowledge isn’t written down, AI just produces confident but risky code. It speeds things up only once the basics are already clear.

[fortran77]

I'm in an adjacent business (FORTRAN) and it hasn't hurt me at all.

[rramadass]

Do you mean you are using LLMs for your Fortran work?

[thevinter]

Not a COBOL dev, but I work on migrating projects from COBOL mainframes to Java.

Generally speaking any kind of AI is relatively hit or miss. We have a statically generated knowledge base of the migrated sourcecode that can be used as context for LLMs to work with, but even that is often not enough to do anything meaningful.

At times Opus 4.5 is able to debug small errors in COBOL modules given a stacktrace and enough hand-holding. Other models are decent at explaining semi-obscure COBOL patterns or at guessing what a module could be doing just given the name and location -- but more often than not they end up just being confidently wrong.

I think the best use-case we have so far is business rule extraction - aka understanding what a module is trying to achieve without getting too much into details.

The TLDR, at least in our case, is that without any supporting RAGs/finetuning/etc all kind of AI works "just ok" and isn't such a big deal (yet)

[mkw5053]

If I were using something like Claude Code to build a COBOL project, I'd structure the scaffolding to break problems into two phases: first, reason through the design from a purely theoretical perspective, weighing implementation tradeoffs; second, reference COBOL documentation and discuss how to make the solution as idiomatic as possible.

Disclaimer: I've never written a single line of COBOL. That said, I'm a programming language enthusiast who has shipped production code in FORTRAN, C, C++, Java, Scala, Clojure, JavaScript, TypeScript, Python, and probably others I'm forgetting.

[mickeywhite]

You may want to give free opensource GnuCOBOL a try. Works on Mac/Linux/Windows. As far as AI and Cobol, I do think Claude Opus 4.5 is getting pretty good. But like stated way above, verify and understand Every line it delivers to you.

[raw_anon_1111]

Funny enough, I found ChatGPT to be pretty good at AppleSoft BASIC

[soami]

s

[Wuiserous]

I see it as a complete opposite for sure, I will tell you why.

it could have been a threat if it was something you cannot control, but you can control it, you can learn to control it, and controlling it in the right direction would enable anyone to actually secure your position or even advance it.

And, about the COBOL, well i dont know what the heck this is.

[krupan]

This is amazing! Thank you for confirming what I've been suspecting for a while now. People that actually know very little about software development now believe they don't need to know anything about it, and they are commenting very confidently here on hn.

[nativeit]

Dunning-Kruger is gonna need a bigger boat.

[roschdal]

No humans understand COBOL, no AI understand COBOL.

[Ygg2]

Damn, then Rust is safe from AI :D

No one understands it either.

[ndr]

Does anyone understand anything?

[iberator]

Total BS. Cobol is well documented and actively developed. I bet you didn't even TRY to write single program for it... Stop spreading FUD

[pjmlp]

I would assert this is affecting all programming languages, this is like the transition from Assembly to high level languages.

Who thinks otherwise, even if LLMs are still a bit dumb today, is fooling themselves.

[krupan]

Compiling high level languages to assembly is a deterministic procedure. You write a program using a small well defined language (relative to natural language every programming language is tiny and extremely well defined). The same input to the same compiler will get you the same output every time. LLMs are nothing like a compiler.

[zmfmfmddl]

The point about the mass of code running the economy being untouched by AI agents is so real. During my years as a developer, I've often faced the skepticism surrounding automation technologies, especially when it comes to legacy languages like COBOL. There’s a perception that as AI becomes more capable, it might threaten specialized roles. However, I believe that the intricacies and context of legacy systems often require human insight that AI has yet to master fully.

I logged my fix for this here: https://thethinkdrop.blogspot.com/2026/01/agentic-automation...