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.

No humans understand COBOL, no AI understand COBOL.

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.

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...

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

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.

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

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...

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.

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.

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

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.

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

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)