Live data from Hacker News

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

news.ycombinator.com

121–130 of 190 posts

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

#121

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 take…

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.

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.

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

#122

Earlier quoted context omitted.

The good news here is that their code is of such a poor quality it doesn't properly work anyway. I have recently tried to blindly create a small .dylib consolidation tool in JS using Claude Code, Opus 4.5 and AskUserTool to create a detailed spec. My god how awful and broken the code was. Unusable. But it faked* working just good enough to pass someone who's got no clue.

> The good news here is that their code is of such a poor quality it doesn't properly work anyway. This is just wishful thinking. In reality it works just well enough to be dangerous. Just look at the latest RCE in OpenCode. The AI it was vibe-coded with allowed any website with origin * to execute code, and the Prompt Engineer™ didn't understand the implications.

> it works just well enough to be dangerous

Excellent. I for one fully welcome Prompt Engineers™ into the world of software development.

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

#123

Earlier quoted context omitted.

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 glanc…

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…

> AI is pretty bad at Python and Go as well.

It great in Golang IF its one shot tasks. LLMs seem to degrade a lot when they are forced to work on existing code bases (even their own). What seems to be more a issue with context sizes growing out of control way too fast (and this is what degrades LLMs the most).

So far Opus 4.5 has been the one LLM that keeps mostly coding in a, how to say, predictable way even with a existing code base. It requires scaffolding and being very clear with your coding requests. But not like the older models where they go off script way too much or rewrite code in their own style.

For me Opus 4.5 has reached that sweet spot of productivity and not just playing around with LLMs and undoing mistakes.

The problem with LLMs is a lot of times a mix of LLM issues, people giving different requests, context overload, different models doing better with different languages, the amount of data it needs to alter etc... This makes the results very mixed from one person to another, and harder to quantify.

Even the different in a task makes the difference between a person one day glorifying a LLM and a few weeks later complaining it was nerfed, when it was not. Just people doing different work / different prompts and ...

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

#124
post #104

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

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.

What do you assume the average age of HN posters to be?

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

#125

Earlier quoted context omitted.

> The good news here is that their code is of such a poor quality it doesn't properly work anyway. This is just wishful thinking. In reality it works just well enough to be dangerous. Just look at the latest RCE in OpenCode. The AI it was vibe-coded with allowed any website with origin * to execute code, and the Prompt Engineer™ didn't understand the implications.

> it works just well enough to be dangerous Excellent. I for one fully welcome Prompt Engineers™ into the world of software development.

I assume you don't understand some of the words in the rest of my comment. Or you're a nihilist and enjoy watching everything burn to the ground.

It's all fun and games until actual lives are at stake.

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

#126

Earlier quoted context omitted.

> it works just well enough to be dangerous Excellent. I for one fully welcome Prompt Engineers™ into the world of software development.

I assume you don't understand some of the words in the rest of my comment. Or you're a nihilist and enjoy watching everything burn to the ground. It's all fun and games until actual lives are at stake.

I'm watching the voters around the world electing charismatic leaders and then cheering the consequences.

Thus companies electing to replace software developers with AI slop are not of a much surprise to me.

It doesn't matter whether people will die because of AI slop. What matters is keeping Microsoft shareholders happy and they are only happy when there is a growing demand for slop.

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

#127
post #124
post #104

Earlier quoted context omitted.

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.

What do you assume the average age of HN posters to be?

35-40, though it could be just a bit older as there is no official metric on this.

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

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

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

#129

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 take…

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.

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

#130
post #121

Earlier quoted context omitted.

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.

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.

Post reply on HN