Live data from Hacker News

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

news.ycombinator.com

71–80 of 190 posts

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

#71
post #6

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.

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…

This sounds like my first job with a big consulting firm many years ago (COBOL as it happens) where programming tasks that were close to pseudocode were handed to the programmers by the analysts. The programmer (in theory) would have very few questions about what he was supposed to write, and was essentially just translating from the firm's internal spec language into COBOL.

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

#73

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…

I’ve found claide code to be amazing at go. This is all nuts because experiences it’s so different from person to another.

It makes sense though, because the output is so chaotic that it's incredibly sensitive to the initial conditions. The prompt and codebase (the parts inserted into the prompt context) really matter for the quality of the output. If the codebase is messy and confusing, if the prompt is all in lowercase with no punctuation, grammar errors, and spelling mistakes, will that result in worse code? It seems extremely likely to me that the answer is yes. That's just how these things work. If there's bad code already, it biases it to complete more bad code.

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

#74
post #60
post #34

Earlier quoted context omitted.

If we ignore optimizing compilers and UB. "Project the need 30 years out and imagine what might be possible in the context of the exponential curves" -- Alan Kay

Is there any compiler that "rolls the dice" when it comes to optimizations? Like, if you compile the exact same code with the exact same compiler multiple times you'll get different assembly? And th Alan Kay quote is great but does not apply here at all? I'm pointing out how silly it is to compare LLMs to compilers. That's all.

> how silly it is to compare LLMs to compilers.

You are quite right; the former is probabilistic while the latter is not.

To paraphrase Babbage;

"I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a [comparison]."

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

#75
post #54

Earlier quoted context omitted.

In my experience AI and Rust is a mixed bag. The strong compile-time checks mean an agent can verify its work to a much larger extent than many other languages, but the understanding of lifetimes is somewhat weak (although better in Opus 4.5 than earlier models!), and the ecosystem moves fast and fairly often makes breaking changes, meaning that a lot of the training data is obsolete.

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.

Luckily that's the compiler's job.

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

#76

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.

The computers themselves were also so expensive that most businesses did not buy them, they leased them.

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

#77
post #13

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

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.

Unfortunately, the people who are "pro-AI" are so often because it lets them skip the understanding part with less scrutiny

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

#78

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…

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 good at following existing patterns in a codebase. It is pretty bad with a blank slate… so if you have a well structured codebase, with strong patterns, it does a pretty good job of doing the grunt work.

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

#79

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…

with all those languages listed in this thread,it explains why I don't trust or use AI when I code.

That's basically all the languages that I am using...

For the AI fans in here, what languages are you using? Typescript only would be my guess?

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

#80
post #6

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.

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 find that at the granularity you need to work with current LLMs to get a good enough output, while verifying its correctness is more effort than writing code directly. The usefulness of LLMs to me is to point me in a direction that I can then manually verify and implement.
Post reply on HN