Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 190 posts

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

#171

Post by halJordan »

ufmace wrote: post #88
hmaxwell wrote: post #50

Earlier quoted context omitted.

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…

That's just the thing though - it seems like, to get really good code out of an LLM, a lot of the time, you have to describe everything you want done and the full context in such excruciating detail and go through so many rounds of review and correction that it would be faster and easier to just write the code yourself.

Welcome to the waterfall development model. This is what companies did before enshitiffixation

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

#172

Post by antonvs »

jmalicki wrote: post #169
antonvs wrote: post #54

Earlier quoted context omitted.

The weakness goes beyond lifetimes. In Rust programs with non-trivial type schemas, it can really struggle to get the types right. You see something similar with Haskell. Basically, proving non-trivial correctness properties globally is more difficult than just making a program work.

How is this an issue specifically with Rust and Haskell? Do you find that LLMs have an easier time proving global correctness with C, Python, or Typescript?

Yes, because those other languages all have much weaker type systems.

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

#173

Post by jamesfinlayson »

rramadass wrote: post #63
elzbardico wrote: post #46

Earlier quoted context omitted.

Don't know about COBOL, but FORTRAN and Ada definitely would survive an Extinction Level Event on earth. Plenty of space based stuff running Ada and maybe some FORTRAN.

The key to understanding their longevity lies in the fact that they were the earliest high-level languages invented at a time when all software was built for serious long-lived stuff viz. Banking, Insurance, Finance, Simulations, Numerical Analysis, Embedded etc. Computing was strictly Science/Mathematics/Business and so a lot of very smart domain experts and programmers built systems to last from the ground up.

> a time when all software was built for serious long-lived stuff

I sometimes lament that most of the code I've written for work will probably be retired before me.

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

#174

Post by jamesfinlayson »

dmux wrote: post #68
hmaxwell wrote: post #50

Earlier quoted context omitted.

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…

I’ve found LLMs to be severely underwhelming. A week or two ago I tried having both Gemini3 and GPT Codex refactor a simple Ruby class hierarchy and neither could even identify the classes that inherited from the class I wanted removed. Severely underwhelming. Describing what was wanted here boils down to minima language and they both failed.

I tried getting AI to update some JUnit 4 to Junit 5 - it replaced the JUnit 4 assertions with Java's built-in assert keyword. Very underwhelming.

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

#175

Post by rerdavies »

kelvinjps10 wrote: post #84
Quothling wrote: post #45

Earlier quoted context omitted.

AI is pretty bad at Python and Go as well. It depends a lot on who uses it though. We have a lot of non-developers who make things work with Python. A lot of it will never need a developer because it being bad doesn't matter for what it does. Some of it needs to be basically rewritten from scratch. Over all I think it's fine. I do love AI for writing yaml and bicep. I mean, it's completely terrible unless you prompt…

If it's bad at python the most popular language what language it's good at? If you see the other comments they're basically mentioning most programming languages

Pretty darned good at C++ and typescript too.

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

#176

Post by jamesfinlayson »

shevy-java wrote: post #72
0xCE0 wrote: post #13

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

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.

I'm in Australia and a friend of a friend had a COBOL job working at a mid-sized bank (the COBOL had lots of Java on top). Australia's big banks are older than this bank so if they're not using COBOL at the bottom layer, they'll be using something similarly old for sure.

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

#177

Post by rsynnott »

DANmode wrote: post #162
anticensor wrote: post #142

COBOL migration is one of Devin's advertised capabilities: https://docs.devin.ai/use-cases/examples/cobol-modernization https://cognition.ai/blog/infosys-cognition

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.

While I didn’t downvote it (and very rarely downvote things at all here), “some random tool advertises something vaguely related”, with no context, is not IMO a particularly interesting contribution.

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

#178

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

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

#179

Post by layer8 »

Muromec wrote: post #130
layer8 wrote: post #121

Earlier quoted context omitted.

The critical “why” knowledge often cannot be derived from the code base. The prohibitions on other companies (LLM providers) being able to see your code also won’t be going away soon.

Other companies can see the code, that isn’t a problem. The problem with LLM is the idea that the code leaks out to companies other than LLM provider. That’s something that can be either solved for real or be promised to not happen.

> Other companies can see the code, that isn’t a problem.

It actually is a restriction in many industries.

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

#180

Post by christophilus »

tomcam wrote: post #150
christophilus wrote: post #131

Earlier quoted context omitted.

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…

How did you call COBOL from VB.NET? Was it just a matter of shelling to COBOL and writing out text files that VB.NET consumed, or COM interprocess calls, or what?

The COBOL layer had a TCP server somewhere in it (don’t know the details of that). We simply made TCP calls directly, sending and receiving fixed-sized records.
Post reply on HN